[GRASS GIS] #1570: In GRASS6.4.2RC3 with wxpython GUI the option Add raster cell numbers doesn't work

#1570: In GRASS6.4.2RC3 with wxpython GUI the option Add raster cell numbers
doesn't work
---------------------+------------------------------------------------------
 Reporter:  clerici  |       Owner:  grass-dev@…              
     Type:  defect   |      Status:  new                      
 Priority:  normal   |   Milestone:  6.4.2                    
Component:  wxGUI    |     Version:  6.4.2 RCs                
 Keywords:           |    Platform:  Linux                    
      Cpu:  x86-64   |  
---------------------+------------------------------------------------------
 In GRASS6.4.2RC3 with wxpython GUI the option Add raster cell numbers
 seems not to work. Clicking Apply (or OK) in the d.rast.num command panel,
 nothing is displayed in the Map Display, and in the Command console
 appears the message: 'd.rast.num' failed. Details:  !!!
 The command runs fine in tcltk GUI and in Command line mode.

 A. Clerici
 Parma University

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1570>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

wingrass compilation simplifed

Hi,

recently I have updated `msys` package in osgeo4w framework (including
fix for 64bit OS) and introduced new package `msys-dev` [1] which
contains all tools needed for GRASS compilation on Windows. See [2].

Martin

PS for Helmut: I would suggest to start with clean OSGeo4W when
building winGRASS packages. Yeap, unfortunately again. Anyway I hope
that the new `msys-dev` package makes our winGRASS packaging more
simple.

[1] http://trac.osgeo.org/osgeo4w/wiki/pkg-msys
[2] http://trac.osgeo.org/grass/wiki/CompileOnWindows#DependenciesrequiredforbuildingwithMinGW

--

-- 
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

RE: Re: [GRASS-user] how to import NetCDF data??

By the way, I've been wanting to import some tsunami models into GRASS, but it is a pain to extract 100's of
time slices with gdal_translate and then import them into GRASS.  So, an easy way to import NetCDF files
into GRASS would make my job easier.  Looking forward to giving Soren's new temporal GIS framework a try!

Bob Moskovitz
Seismic Hazards Mapping Program
California Geological Survey

-----Original Message-----
From: grass-dev-bounces <at> lists.osgeo.org on behalf of Michael Barton
Sent: Wed 2/8/2012 9:57 AM
To: Jennifer Boehnert
Cc: Helena Mitasova; Kirk Wythers; developers grass-developers; Kyngesburye William; GRASS <at> lists.osgeo.org
Subject: [GRASS-dev] Re: [GRASS-user] how to import NetCDF data??

This will be even more important with Soren's new temporal GIS framework. Many netcdf climate files are the
equivalent of 'time-cubes'. Being able to read/write these easily would provide a very rich source of
data to use in temporal GIS analyses.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Re: [GRASS-user] how to import NetCDF data??

This will be even more important with Soren's new temporal GIS framework. Many netcdf climate files are the
equivalent of 'time-cubes'. Being able to read/write these easily would provide a very rich source of
data to use in temporal GIS analyses.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 8, 2012, at 10:14 AM, Jennifer Boehnert wrote:

> Thank you everyone for all the support, suggestions and feedback.  I am 
> trying to create a course using GRASS which I would teach in Latin 
> America and eventually hopefully in Africa working on vulnerability 
> assessements using climate change model output from NCAR.  My netCDF 
> data is from the CCSM which was in by the IPCC AR4, it is netCDF3 and 
> using the CF-convention.  It is a pretty typical netCDF file and it 
> would be great if we could read it into GRASS directly without having to 
> convert it to a geotiff or any other format, if possible.
> Thanks Jennifer
> 
> 
> On 2/8/2012 10:05 AM, Michael Barton wrote:
>> Lack of NetCDF support would be a problem for sure. We wondered about

[GRASS GIS] #1569: i.pr.features error

#1569: i.pr.features error
---------------------+------------------------------------------------------
 Reporter:  gab      |       Owner:  grass-dev@…              
     Type:  defect   |      Status:  new                      
 Priority:  normal   |   Milestone:  6.5.0                    
Component:  Default  |     Version:  svn-develbranch6         
 Keywords:  i.pr     |    Platform:  Linux                    
      Cpu:  x86-64   |  
---------------------+------------------------------------------------------
 I.pr modules seem to work but I found a problem: i.pr.features

  I saw some posts because I have the same problem..example:
  i.pr.features -s training=TL_ipr_training_TL_ASTER_2006_02_01_RGB.52
 features=aasasssas
  ERROR: read_training-> Can't open file
 TL_ipr_training_TL_ASTER_2006_02_01_RGB.52 for reading

 Thank you very much

 Gabriele

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1569>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org

Re: [GRASS-user] how to import NetCDF data??

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS GIS] #1568: 'make install' results in an installation dependent upon temporary build directories

#1568: 'make install' results in an installation dependent upon temporary build
directories
--------------------------+-------------------------------------------------
 Reporter:  helsene       |       Owner:  grass-dev@…              
     Type:  defect        |      Status:  new                      
 Priority:  normal        |   Milestone:  7.0.0                    
Component:  Installation  |     Version:  svn-trunk                
 Keywords:                |    Platform:  Linux                    
      Cpu:  x86-64        |  
--------------------------+-------------------------------------------------
 I did a compilation of GRASS from the SVN repo on 2.7.12 using Debian
 Squeeze and the instructions given at
 http://grass.osgeo.org/wiki/Compile_and_Install#GRASS_7_on_Debian_Squeeze.


 After using 'sudo make install' and having the installation placed in
 /usr/local/grass7.0.svn, the resulting installation still seems to require
 libs in /<checkoutdir>/dist.x86_64-unknown-linux-gnu/lib/. Specifically,
 launching the program causes it to look for libgrass_raster.7.0.svn.so in
 the build directory and subsequently throw a 'permission denied' error
 when using GRASS with a user other than the one who did the build.

 This causes issues loading libraries for other users, who get 'permission
 denied' errors when attempting to access the /<checkoutdir>/dist.x86_64
 -unknown-linux-gnu/lib/ directory.

 The workaround is to make the build dirs globally readable, but I'm pretty
 sure this isn't intended behavior. I imagine building and deploying a deb
 package would fail as the checkout directory wouldn't be present on a
 system where the build did not occur.

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1568>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS GIS] #1567: Map display: saving image with scale and legend

#1567: Map display: saving image with scale and legend
-----------------------+----------------------------------------------------
 Reporter:  helena     |       Owner:  grass-dev@…              
     Type:  defect     |      Status:  new                      
 Priority:  normal     |   Milestone:  6.4.3                    
Component:  wxGUI      |     Version:  6.4.2 RCs                
 Keywords:             |    Platform:  All                      
      Cpu:  OSX/Intel  |  
-----------------------+----------------------------------------------------
 when saving image from map display that includes scale and legend,
 everything is saved correctly when the default setting is used,
 but when a template (pre-set image size) is used scale and legend either
 is not included
 http://skagit.meas.ncsu.edu/~helena/grasswork/saveimg_test4.png

 http://skagit.meas.ncsu.edu/~helena/grasswork/saveimg_test5.png

 or it is not scaled properly.
 See also
 http://lists.osgeo.org/pipermail/grass-user/2011-November/062601.html


 Helena

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1567>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

how to import NetCDF data??

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS GIS] #1562: Introduction of spatial and temporal vertical units for raster3d maps and r3.support

#1562: Introduction of spatial and temporal vertical units for raster3d maps and
r3.support
--------------------------+-------------------------------------------------
  Reporter:  huhabla      |       Owner:  huhabla    
      Type:  enhancement  |      Status:  closed     
  Priority:  major        |   Milestone:  7.0.0      
 Component:  Raster3D     |     Version:  svn-trunk  
Resolution:  fixed        |    Keywords:  r3.support 
  Platform:  Unspecified  |         Cpu:  Unspecified
--------------------------+-------------------------------------------------

Comment(by huhabla):

 Replying to [comment:11 cmbarton]:
 [snip]
 >
 > This example seems to do what I would need a temporal GIS to do. It
 suggests that handling negative numbers is not a problem. So perhaps we
 are talking past each other somewhat.
 >
 > A calendar date (e.g., 6 February 2012) is in fact a relative date
 calculated from an arbitrary moment in the past. However, I suppose that
 program date functions treat this differently than what you are calling
 "relative dates". For most prehistoric/deep time analyses--archaeological
 and paleoenvironmental--the kind of relative date that you show above
 should serve fine.


 I use the absolute and relative time definition of the GRASS datetime
 library which is a common concept in temporal GIS:
 1) Absolute DateTimes express a single time or date referenced to the
 Gregorian calendar (e.g. 14 Feb 1995) [1]
 2) Relative DateTimes express a difference or length of time (e.g., 201
 days 6 hours) [1]

 [1] http://skagit.meas.ncsu.edu/~helena/gmslab/htdoc/time/index.html



 >
 > In fact, while these are written as a text string (e.g., AD 1235 or 3150
 +/- 200 cal BC), using them in a temporal GIS would be much easier if they
 were just transformed into numbers (e.g., +1235 and -3150).
 >
 > This example brings up another issue that may be worth thinking about at
 some point. Many age estimates in the deep past are expressed with some
 kind of error range (often a mean +/- 1SD or 2SD). Often readers
 (including archaeologists) just focus on the mean. But actually, a
 calibrated radiocarbon date of  3150 +/- 200 cal BC means that the dated
 material has a 65% chance of falling between 3350-2950 BC. This can be
 very important when comparing different events. It would be worth thinking
 about how to express such uncertainty or at least date ranges rather than
 a single date in a temporal GIS so that comparisons between events with
 overlapping ranges would be considered as contemporaneous (or even better
 contemporaneous within some probability).

 The temporal GIS framework allows the use of interval time. You can add
 relative or absolute time intervals to raster, raster3d and vector maps
 and register them in space time datasets. Hence maps with overlapping time
 intervals are supported in space time datasets. These intervals may
 represent the uncertainty?
 The temporal relations between the registered maps can be computed using
 t.topology[1]. It is possible to sample space time datasets with each
 other[2].

 [1]
 https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.topology/test.t.topology.reltime.sh


 [2]
 https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.sample/test.t.sample.sh



 > The thing is, the concept of actually implementing a production-level
 temporal GIS is very exciting and offers a the potential for new kinds of
 analyses that have never before been possible.

 I hope that the temporal GIS framework will be very useful indeed.

 Sorry for undocumented modules and tests, but i need first to get the
 temporal GIS paper ready before adding to much information ... .

 Soeren

--

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1562#comment:13>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS GIS] #1562: Introduction of spatial and temporal vertical units for raster3d maps and r3.support

#1562: Introduction of spatial and temporal vertical units for raster3d maps and
r3.support
--------------------------+-------------------------------------------------
  Reporter:  huhabla      |       Owner:  huhabla    
      Type:  enhancement  |      Status:  closed     
  Priority:  major        |   Milestone:  7.0.0      
 Component:  Raster3D     |     Version:  svn-trunk  
Resolution:  fixed        |    Keywords:  r3.support 
  Platform:  Unspecified  |         Cpu:  Unspecified
--------------------------+-------------------------------------------------

Comment(by huhabla):

 Hi Hamish,

 Replying to [comment:10 hamish]:
 > Replying to comment [comment:9]:
 >
 > Hi,
 >
 > if you take ownership of a ticket you have to manually add the grass-dev
 mailing list the cc field, or else no one gets to see this long discussion
 is happening at all.

 Thanks for the info Hamish, this always confuses me a lot and i think i
 will never get it right ... .

 >
 >
 > I've some minor comments/changes to request which I'll post in the
 coming days. First and shortest is that we should break the long held two-
 dot rule (for these modules) and name them like t.r3.*.*.
 > That is much less-bad than introducing many new top level abbreviations
 for module which essentially have a common root.

 That's an interesting approach.

 If you want i can send you the current state of the promised tutorial
 (inclusive all errors, misspelled words, uncertainties, ...), so you can
 get an idea of how the temporal GIS framework will work and what modules
 are implemented and planed.

 I think i need 2 - 3 weeks to finish the tutorial to reflect all recent
 changes i made in the temporal framework. When its finished i will
 distribute it to interested developers.

 Soeren



 >
 >
 > thanks,
 > Hamish

--

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1562#comment:12>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev