Re: [GRASS-user] raster attribute table problems
On Sat, Jan 17, 2015 at 5:45 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi, When importing National Landcover Dataset (http://www.mrlc.gov/nlcd2011.php), I would like to get the classes imported as raster labels. Gdalinfo reports existing attribute table where one of the columns is FieldDefn index=6 NameLand Cover Class/Name Type2/Type Usage0/Usage /FieldDefn r.in.gdal should be able to recognize it and use it as a label. The problem is that the field Usage reports 0, which represents GFU_Generic (General purpose field) instead of GFU_Name (Class name) and as a result r.in.gdal doesn't take it into account. The attributes are supposed to be stored in some vat.dbf file in the NLCD dataset (I was not able to open it on Ubuntu with LibreOffice due to some encoding problems to see what's exactly there). I don't understand how GDAL decides which column is generic or represents class name and I don't know if the problem is on GDAL's side or on the side of the data provider. Would it make sense to have an option in r.in.gdal to specify the name of the column which should be used for labels? You can use the table option of r.in.gdal to dump the raster attribute table in plain text, then modify the table such that it can be used as rules option for r.category. Markus M Thanks, Anna ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about GRASS raster temporal data
Stefan, Thank you for your response -- it looks like I'll have to do a bit of scripting, which is OK... I just did not want to needlessly re-invent the wheel. Having such a capability built into the tools is a great idea, however. Best, Tom On Sat, Jan 17, 2015 at 11:44 AM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi Thomas, The out of the box- option would be to use t.vect.observe.strds However, r.what is significantly faster, but requires with 400 maps a little bit of scripting. My approach is this one (there you can find a little shell-script: https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg38802.html (the transpose command i the script is nothing but a little awk-command, like e.g. here: http://stackoverflow.com/questions/13634816/using-awk-to-transpose-column-to-row ) Hopefully there will e some development in that direction soon... Cheers Stefan -- *Von:* grass-user-boun...@lists.osgeo.org grass-user-boun...@lists.osgeo.org im Auftrag von Thomas Adams tea...@gmail.com *Gesendet:* Samstag, 17. Januar 2015 17:06 *An:* grass-user@lists.osgeo.org *Betreff:* [GRASS-user] Question about GRASS raster temporal data All: I am just getting started using GRASS raster temporal data analysis capabilities (both GRASS 7.0 and 7.1svn as of this AM) -- pretty cool, with some nice features. I have looked through the wiki: http://grasswiki.osgeo.org/wiki/Temporal_data_processing and saw the use of g.gui.tplot http://grass.osgeo.org/grass71/manuals/g.gui.tplot.html which worked for my small data set (see t.info output below) -- what I need, however, are the values and dates extracted by g.gui.tplot exported to a text file. How do I get these? I have looked through all the modules and can not find what I need. Best, Tom GRASS 7.0.0beta3 (newster):~/grass/data t.info type=strds input=ann_max_flow + Space Time Raster Dataset -+ | | + Basic information -+ | Id: ann_max_flow@adams | Name: .. ann_max_flow | Mapset: adams | Creator: ... teaiii | Temporal type: . absolute | Creation time: . 2015-01-17 05:28:15.023686 | Modification time:.. 2015-01-17 05:38:10.846286 | Semantic type:.. mean + Absolute time -+ | Start time:. 1997-01-01 00:00:00 | End time:... 2014-01-01 00:00:00 | Granularity: 1 year | Temporal type of maps:.. interval + Spatial extent + | North:.. -4895850.0 | South:.. -5224462.5 | East:.. 2695575.0 | West:... 2424112.5 | Top: 0.0 | Bottom:. 0.0 + Metadata information --+ | Raster register table:.. raster_map_register_9d88390c739741bbb43e68759f90c4c9 | North-South resolution min:. 4762.499512 | North-South resolution max:. 4762.5 | East-west resolution min:... 4762.499512 | East-west resolution max:... 4762.5 | Minimum value min:.. 0.209504 | Minimum value max:.. 2.55081 | Maximum value min:.. 856.120972 | Maximum value max:.. 5188.450195 | Aggregation type:... None | Number of registered maps:.. 17 | | Title: | Potomac annual maximum flows | Description: | Potomac annual maximum flows derived from NOAA/NWS RDHM DHMTF analysis 1996-2013 | Command history: | # 2015-01-17 05:28:15 | t.create type=strds temporaltype=absolute | output=ann_max_flow title=Potomac annual maximum flows | description=Potomac annual maximum flows derived from NOAA/NWS RDHM DHMTF analysis 1996-2013 | # 2015-01-17 05:38:10 | t.register -i type=rast input=ann_max_flow | file=potomac_max_flow_list.txt start=1997-01-01 increment=1 year | ++ -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.select error: point array must contain 0 or 1 elements
I have two shapefiles that I imported into GRASS 6.4.5 using v.in.ogr. One is a polygon file of building footprints. The second is a polyline of the pavement edges of urban streets. I am trying to convert this into street area. I used v.clean, v.type (to switch from line to boundaries), and v.centroids. This conversion process gives me street areas but also creates doughnut holes corresponding to the area inside of a city block outlined by the streets. For the most part the doughnut holes contain buildings, so I am trying to use v.select to select the areas that do not contain buildings. I have not been able to get anything besides overlap to work. Overlap is not good enough though because many of the buildings have shared nodes with the streets, for example where a driveway runs along one side of a house. I checked and my version of GRASS was compiled with the following GEOS details: --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config Below is an example of an error that I am getting when I try anything besides overlap: v.select --overwrite ainput=EdgePav_cent@PERMANENT binput=Bldg@PERMANENT output=Pav_sel operator=containsWARNING: Vector map Pav_sel already exists and will be overwrittenBuilding spatial index...Processing features...ERROR: IllegalArgumentException: point array must contain 0 or 1 elements A similar question appears to have previously gone unanswered:grass-development-gis - [GRASS-dev] v.select - ERROR: IllegalArgumentException: point array must contain 0 or 1 elements - msg#00289 - Recent Discussion OSDir.com | | | | | | | | | grass-development-gis - [GRASS-dev] v.select - ERROR: IllegalArgumentException: point array mus...hi, I've tried v.select of a line vector by an area vector: GEOS-based selection v.select ainput=geav150@rstreamanalysis binput=mgoutlet@rstreamanalysis output=test operator=overlaps | | | | View on osdir.com | Preview by Yahoo | | | | | Thanks for any advice you can provide. -Thayer___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] raster attribute table problems
On Sat, Jan 17, 2015 at 2:44 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Jan 17, 2015 at 5:45 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi, When importing National Landcover Dataset (http://www.mrlc.gov/nlcd2011.php), I would like to get the classes imported as raster labels. Gdalinfo reports existing attribute table where one of the columns is FieldDefn index=6 NameLand Cover Class/Name Type2/Type Usage0/Usage /FieldDefn r.in.gdal should be able to recognize it and use it as a label. The problem is that the field Usage reports 0, which represents GFU_Generic (General purpose field) instead of GFU_Name (Class name) and as a result r.in.gdal doesn't take it into account. The attributes are supposed to be stored in some vat.dbf file in the NLCD dataset (I was not able to open it on Ubuntu with LibreOffice due to some encoding problems to see what's exactly there). I don't understand how GDAL decides which column is generic or represents class name and I don't know if the problem is on GDAL's side or on the side of the data provider. Would it make sense to have an option in r.in.gdal to specify the name of the column which should be used for labels? You can use the table option of r.in.gdal to dump the raster attribute table in plain text, then modify the table such that it can be used as rules option for r.category. Thanks, I didn't quite get what the option is doing. So, I was trying to import the exported csv file as a standard vector attribute table with db.in.ogr (which uses v.in.ogr), however, ogr refused it probably because of the separator (pipe). Once I changed the separator to comma, it worked. Shouldn't r.in.gdal output a csv file with common separator like comma? I understand that you don't always need to import it as attribute table, but anyway comma seems more reasonable to me. Thanks, Anna Markus M Thanks, Anna ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] raster attribute table problems
On Sat, Jan 17, 2015 at 5:15 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Jan 17, 2015 at 10:50 PM, Anna Petrášová kratocha...@gmail.com wrote: On Sat, Jan 17, 2015 at 2:44 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Jan 17, 2015 at 5:45 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi, When importing National Landcover Dataset (http://www.mrlc.gov/nlcd2011.php), I would like to get the classes imported as raster labels. Gdalinfo reports existing attribute table where one of the columns is FieldDefn index=6 NameLand Cover Class/Name Type2/Type Usage0/Usage /FieldDefn r.in.gdal should be able to recognize it and use it as a label. The problem is that the field Usage reports 0, which represents GFU_Generic (General purpose field) instead of GFU_Name (Class name) and as a result r.in.gdal doesn't take it into account. The attributes are supposed to be stored in some vat.dbf file in the NLCD dataset (I was not able to open it on Ubuntu with LibreOffice due to some encoding problems to see what's exactly there). I don't understand how GDAL decides which column is generic or represents class name and I don't know if the problem is on GDAL's side or on the side of the data provider. Would it make sense to have an option in r.in.gdal to specify the name of the column which should be used for labels? You can use the table option of r.in.gdal to dump the raster attribute table in plain text, then modify the table such that it can be used as rules option for r.category. Thanks, I didn't quite get what the option is doing. So, I was trying to import the exported csv file as a standard vector attribute table with db.in.ogr (which uses v.in.ogr), however, ogr refused it probably because of the separator (pipe). Once I changed the separator to comma, it worked. Why did you try to import raster category labels as a vector attribute table? The purpose of the RAT dump is to give you a chance to modify the dumped raster attribute table with your preferred text processing tools (a combination of cat, cut, tr, sed could help) in order to create input for either r.category or r.colors. I was trying to find a way using only GRASS commands (e.g. for Windows users). But I must admit, even if the db.in.ogr worked, still it's not very straightforward (db.in.ogr - db.select - r.category). The landcover dataset is used a lot so I hoped there will be some easier way to get it into GRASS (which not experienced students with Windows would be able to do). Shouldn't r.in.gdal output a csv file with common separator like comma? I understand that you don't always need to import it as attribute table, but anyway comma seems more reasonable to me. Comma is too commonly used in text entries. True From a GRASS perspective, a raster attribute table is a GDAL-specific thing that has nothing in common with a vector attribute table. There are no raster attribute tables in GRASS. r.in.gdal tries to extract information from GDAL raster attribute tables that can be used as category labels (see r.category) or color rules (see r.colors). Sure. My initial suggestion was to specify which column should be used for labels. In case of multiband raster it could be problematic (but maybe this case would not come up often), so I understand the exported table is a more general solution but also less convenient. It seems this type of data are being used quite often (at least in the US) so we might get more feedback on the current solution. Best, Anna Markus M Thanks, Anna Markus M Thanks, Anna ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about GRASS raster temporal data
Hi Thomas, The out of the box- option would be to use t.vect.observe.strds However, r.what is significantly faster, but requires with 400 maps a little bit of scripting. My approach is this one (there you can find a little shell-script: https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg38802.html (the transpose command i the script is nothing but a little awk-command, like e.g. here: http://stackoverflow.com/questions/13634816/using-awk-to-transpose-column-to-row) Hopefully there will e some development in that direction soon... Cheers Stefan Von: grass-user-boun...@lists.osgeo.org grass-user-boun...@lists.osgeo.org im Auftrag von Thomas Adams tea...@gmail.com Gesendet: Samstag, 17. Januar 2015 17:06 An: grass-user@lists.osgeo.org Betreff: [GRASS-user] Question about GRASS raster temporal data All: I am just getting started using GRASS raster temporal data analysis capabilities (both GRASS 7.0 and 7.1svn as of this AM) -- pretty cool, with some nice features. I have looked through the wiki: http://grasswiki.osgeo.org/wiki/Temporal_data_processing and saw the use of g.gui.tplothttp://grass.osgeo.org/grass71/manuals/g.gui.tplot.html which worked for my small data set (see t.infohttp://t.info/ output below) -- what I need, however, are the values and dates extracted by g.gui.tplot exported to a text file. How do I get these? I have looked through all the modules and can not find what I need. Best, Tom GRASS 7.0.0beta3 (newster):~/grass/data t.infohttp://t.info/ type=strds input=ann_max_flow + Space Time Raster Dataset -+ || + Basic information -+ | Id: ann_max_flow@adams | Name: .. ann_max_flow | Mapset: adams | Creator: ... teaiii | Temporal type: . absolute | Creation time: . 2015-01-17 05:28:15.023686 | Modification time:.. 2015-01-17 05:38:10.846286 | Semantic type:.. mean + Absolute time -+ | Start time:. 1997-01-01 00:00:00 | End time:... 2014-01-01 00:00:00 | Granularity: 1 year | Temporal type of maps:.. interval + Spatial extent + | North:.. -4895850.0 | South:.. -5224462.5 | East:.. 2695575.0 | West:... 2424112.5 | Top: 0.0 | Bottom:. 0.0 + Metadata information --+ | Raster register table:.. raster_map_register_9d88390c739741bbb43e68759f90c4c9 | North-South resolution min:. 4762.499512 | North-South resolution max:. 4762.5 | East-west resolution min:... 4762.499512 | East-west resolution max:... 4762.5 | Minimum value min:.. 0.209504 | Minimum value max:.. 2.55081 | Maximum value min:.. 856.120972 | Maximum value max:.. 5188.450195 | Aggregation type:... None | Number of registered maps:.. 17 | | Title: | Potomac annual maximum flows | Description: | Potomac annual maximum flows derived from NOAA/NWS RDHM DHMTF analysis 1996-2013 | Command history: | # 2015-01-17 05:28:15 | t.create type=strds temporaltype=absolute | output=ann_max_flow title=Potomac annual maximum flows | description=Potomac annual maximum flows derived from NOAA/NWS RDHM DHMTF analysis 1996-2013 | # 2015-01-17 05:38:10 | t.register -i type=rast input=ann_max_flow | file=potomac_max_flow_list.txt start=1997-01-01 increment=1 year | ++ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Large Grass Raster Notes
Greetings, In the event my experience working with rather large GRASS rasters may be useful, I thought I would share it. The following notes were compiled running the GRASS 7.0.0beta4-141230 package on Mac OS X 10.10.1. The system is a 6-core Xeon with 32GB of RAM, running in full 64-bit mode. 1. Using an r.external virtual mosaic as the input proved impossible trying to run r.resample on it on trying to produce a nearly teracell raster (I ended up breaking sub-tiles). I closely followed the instructions on the Wiki. 2. On smaller sub-tiles of said image, r.resample was insanely slow even with the external imagery. At first I thought it was a limitation of being overwhelmed with small sector requests and purchased a terabyte SSD, copied the external imagery to the SSD, but that didn’t noticeably help. Throughput was way less than 1mb/sec. 3. g.remove is unusable for long lists. Actually applies to I think any utility that takes a list for input. I wish I could just put it to a file so it could parse it line by line (As I understand the issue it is a limitation of the insanely long shell arguments). If anyone wants me to elaborate on anything, or has pointers how to do things better - please let me know! Cheers, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Large Grass Raster Notes
Hi, On Sat, Jan 17, 2015 at 7:00 PM, Jeshua Lacock jes...@3dtopo.com wrote: Greetings, In the event my experience working with rather large GRASS rasters may be useful, I thought I would share it. The following notes were compiled running the GRASS 7.0.0beta4-141230 package on Mac OS X 10.10.1. The system is a 6-core Xeon with 32GB of RAM, running in full 64-bit mode. 1. Using an r.external virtual mosaic as the input proved impossible trying to run r.resample on it on trying to produce a nearly teracell raster (I ended up breaking sub-tiles). I closely followed the instructions on the Wiki. 2. On smaller sub-tiles of said image, r.resample was insanely slow even with the external imagery. At first I thought it was a limitation of being overwhelmed with small sector requests and purchased a terabyte SSD, copied the external imagery to the SSD, but that didn’t noticeably help. Throughput was way less than 1mb/sec. 3. g.remove is unusable for long lists. Actually applies to I think any utility that takes a list for input. I wish I could just put it to a file so it could parse it line by line (As I understand the issue it is a limitation of the insanely long shell arguments). maybe silly question regarding g.remove, have you used the pattern option instead of the name option? Best, Anna If anyone wants me to elaborate on anything, or has pointers how to do things better - please let me know! Cheers, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Make Error: -7.1svn [RESOLVED]
On Sat, 17 Jan 2015, Rich Shepard wrote: --with-freetype-libs=/usr/include/freetype2 \ Duh! That needs to be --with-freetype-includes=. Sigh, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Large Grass Raster Notes
On Jan 17, 2015, at 8:00 PM, Anna Petrášová kratocha...@gmail.com wrote: maybe silly question regarding g.remove, have you used the pattern option instead of the name option? Hi, Thank you for your suggestion Anna! Well I didn’t want to use wildcards because one little mistake and — The list was verified first by eye. Besides that, this same potential issue applies to many modules that may not have pattern matching that I might be more comfortable with then essentially rm -R. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Make Error: -7.1svn
Downloaded the latest changed files from the subversion repository this morning but did not record the build number. Make failed, and the first error is in ../lib/driver/: gcc -g -O2 -fPIC -I/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/include -I/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPACKAGE=\grasslibs\ -I/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/include -I/home/rshepard/GIS/GRASS/grass-7.0svn/dist.i686-pc-linux-gnu/include -DRELDIR=\lib/driver\ -o OBJ.i686-pc-linux-gnu/text3.o -c text3.c text3.c:16:23: fatal error: freetype.h: No such file or directory #include FT_FREETYPE_H ^ compilation terminated. Prior to this, I upgraded freetype2. The configuration file includes these two lines: --with-freetype \ --with-freetype-libs=/usr/include/freetype2 \ but that does not remove the error. A cluestick is needed. TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Question about GRASS raster temporal data
All: I am just getting started using GRASS raster temporal data analysis capabilities (both GRASS 7.0 and 7.1svn as of this AM) -- pretty cool, with some nice features. I have looked through the wiki: http://grasswiki.osgeo.org/wiki/Temporal_data_processing and saw the use of g.gui.tplot http://grass.osgeo.org/grass71/manuals/g.gui.tplot.html which worked for my small data set (see t.info output below) -- what I need, however, are the values and dates extracted by g.gui.tplot exported to a text file. How do I get these? I have looked through all the modules and can not find what I need. Best, Tom GRASS 7.0.0beta3 (newster):~/grass/data t.info type=strds input=ann_max_flow + Space Time Raster Dataset -+ | | + Basic information -+ | Id: ann_max_flow@adams | Name: .. ann_max_flow | Mapset: adams | Creator: ... teaiii | Temporal type: . absolute | Creation time: . 2015-01-17 05:28:15.023686 | Modification time:.. 2015-01-17 05:38:10.846286 | Semantic type:.. mean + Absolute time -+ | Start time:. 1997-01-01 00:00:00 | End time:... 2014-01-01 00:00:00 | Granularity: 1 year | Temporal type of maps:.. interval + Spatial extent + | North:.. -4895850.0 | South:.. -5224462.5 | East:.. 2695575.0 | West:... 2424112.5 | Top: 0.0 | Bottom:. 0.0 + Metadata information --+ | Raster register table:.. raster_map_register_9d88390c739741bbb43e68759f90c4c9 | North-South resolution min:. 4762.499512 | North-South resolution max:. 4762.5 | East-west resolution min:... 4762.499512 | East-west resolution max:... 4762.5 | Minimum value min:.. 0.209504 | Minimum value max:.. 2.55081 | Maximum value min:.. 856.120972 | Maximum value max:.. 5188.450195 | Aggregation type:... None | Number of registered maps:.. 17 | | Title: | Potomac annual maximum flows | Description: | Potomac annual maximum flows derived from NOAA/NWS RDHM DHMTF analysis 1996-2013 | Command history: | # 2015-01-17 05:28:15 | t.create type=strds temporaltype=absolute | output=ann_max_flow title=Potomac annual maximum flows | description=Potomac annual maximum flows derived from NOAA/NWS RDHM DHMTF analysis 1996-2013 | # 2015-01-17 05:38:10 | t.register -i type=rast input=ann_max_flow | file=potomac_max_flow_list.txt start=1997-01-01 increment=1 year | ++ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] raster attribute table problems
Hi, When importing National Landcover Dataset (http://www.mrlc.gov/nlcd2011.php), I would like to get the classes imported as raster labels. Gdalinfo reports existing attribute table where one of the columns is FieldDefn index=6 NameLand Cover Class/Name Type2/Type Usage0/Usage /FieldDefn r.in.gdal should be able to recognize it and use it as a label. The problem is that the field Usage reports 0, which represents GFU_Generic (General purpose field) instead of GFU_Name (Class name) and as a result r.in.gdal doesn't take it into account. The attributes are supposed to be stored in some vat.dbf file in the NLCD dataset (I was not able to open it on Ubuntu with LibreOffice due to some encoding problems to see what's exactly there). I don't understand how GDAL decides which column is generic or represents class name and I don't know if the problem is on GDAL's side or on the side of the data provider. Would it make sense to have an option in r.in.gdal to specify the name of the column which should be used for labels? Thanks, Anna ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
