Re: [GRASS-user] d.mon start=cairo multi-layer PDF, PS, SVG output
Dear list,
I am replying to myself just to say that I hit the same issues as shown at:
https://trac.osgeo.org/grass/ticket/3033
My apologies for not checking that first.
As I keep running into this problem, but there is not a lot of discussion
on it, probably people have found other ways to deal with it (e.g., ps.map,
which what I will try next).
Also, I noticed that the Python way was also explored:
https://discuss.wxpython.org/t/wx-image-postscript/25813
which I was actually about to ask…
Kind regards,
Luigi
On Thu, Oct 28, 2021 at 12:34 PM Luigi Ponti wrote:
> Dear all,
>
> I am trying to get output image files in various formats using the Cairo
> driver, following some very useful Python scripting examples:
> https://baharmon.github.io/python-in-grass
>
> When I try to map vector layers (e.g., point data) on top of raster layers
> (say a digital elevation model);
>
> if I use PNG output file extension, both vector and raster layers show up
> with points having transparent background,
>
> if I use PDF, PS, or SVG output file extension, only the vector layer
> (drawn last) is shown in the output image with white background.
>
> Maybe the PS driver is a better option?
>
> Yet, I was reading this old grass-dev post that may be relevant:
> https://marc.info/?l=grass-dev=146346954429631=2
>
> Kind regards,
>
> Luigi
>
>
> Sample test function I am using follows:
>
> def make_map(outfile_name,
> fig_width,
> fig_height,
> bg_color: Optional[str] = None,
> file_types: Optional[list] = None):
> """ Test ouput map figure.
> PLEASE CHECK as PDF and PS output does not get vectors displayed on
> top of rasters. """
> background_color = bg_color or [NO_BG_COLOR]
> extensions = [PNG] if file_types is None else file_types
> for extension in extensions:
> outfile = pathlib.Path(OUT_DIR).joinpath(f"{outfile_name}.{extension}")
> grass.run_command("d.mon", overwrite=True,
> start="cairo",
> width=fig_width,
> height=fig_height,
> bgcolor=background_color,
> output=outfile)
> grass.run_command("d.rast",
> map="raster_layer")
> grass.run_command("d.vect",
> map="point_vector_layer",
> type="point",
> color="150:0:0",
> size=20)
> # all other display commands
> grass.run_command("d.mon", stop="cairo")
>
>
> Bundled GRASS app for Mac from here:
> http://grassmac.wikidot.com/downloads
>
> System Info:
>
> GRASS version: 8.0.dev
>
> Code revision: 32930185c
>
> Build date: 2021-07-01
>
> Build platform: x86_64-apple-darwin20.5.0
>
> GDAL: 3.1.4
>
> PROJ: 7.1.1
>
> GEOS: 3.8.1
>
> SQLite: 3.35.4
>
> Python: 3.8.8
>
> wxPython: 4.1.1
>
> Platform: macOS-10.16-x86_64-i386-64bit
>
>
> g.version -b
> GRASS 8.0.dev (2021)
>
> ./configure
> --with-macosx-sdk=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
> --enable-64bit --with-macosx-archs=x86_64 --with-opengl=aqua --with-openmp
> --prefix=/Applications/GRASS-8.0.app/Contents/Resources --with-freetype
> --with-freetype-includes=/Applications/GRASS-8.0.app/Contents/Resources/include/freetype2
> --with-freetype-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
> --with-gdal=/Applications/GRASS-8.0.app/Contents/Resources/bin/gdal-config
> --with-gdal-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
> --with-proj=/Applications/GRASS-8.0.app/Contents/Resources/bin/proj
> --with-proj-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
> --with-proj-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
> --with-proj-share=/Applications/GRASS-8.0.app/Contents/Resources/share/proj
> --with-geos=/Applications/GRASS-8.0.app/Contents/Resources/bin/geos-config
> --with-jpeg-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
> --with-jpeg-libs=//Applications/GRASS-8.0.app/Contents/Resources/lib
> --with-png-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
> --with-png-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
> --with-tiff-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
> --with-tiff-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
> --with-postgres=yes
> --with-postgres-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
> --with-postgres-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
> --without-mysql --with-sqlite
> --with-sqlite-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
> --with-sqlite-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
> --with-fftw-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
> --with-fftw-libs=/Applications/GRASS-8.0.app
[GRASS-user] d.mon start=cairo multi-layer PDF, PS, SVG output
8.0.app/Contents/Resources/include --with-pdal=/Applications/GRASS-8.0.app/Contents/Resources/bin/pdal-config --with-pdal-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib --with-readline --with-readline-includes=/Applications/GRASS-8.0.app/Contents/Resources/include/readline --with-readline-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib --with-liblas=/Applications/GRASS-8.0.app/Contents/Resources/bin/liblas-config -- Luigi Ponti ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.diversity (r.li) options on windows
Dear Markus, That's great! Thanks! Will give it a try right away. Enjoy Vienna, Luigi On 26/03/2014 15:47, Markus Neteler wrote: Hi Luigi, On Sun, Feb 23, 2014 at 11:51 PM, Markus Neteler nete...@osgeo.org wrote: Hi Luigi, over the past few weeks Markus Metz has submitted a major rewrite of r.li.* to GRASS GIS 7.svn. I have backported it all to GRASS 6.4.svn and 6.5.svn. Greetings from the Vienna Code Sprint, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.diversity (r.li) options on windows
Dear Anna,Just compiled from source r59347 and the error triggered by menu commandHelp About GRASS GIS no longer shows up, i.e., we get the regular gui window showing info (even though Code Revision and Build Date are not available and a question mark is shown instead).Your suggested test command shows the following ouput:GRASS 7.0.svn (valdagri):/usr g.version -rgeversion=7.0.svndate=2014revision=build_date=2014-03-26build_platform=i686-pc-linux-gnuSegmentation fault (core dumped)with revision number still not available.Our original target, g.extension (see email subject), still returns the Fetch Install extension from GRASS Addons gui windows with error saying "Unable to load extensions".Displaying GIS layers seems to work fine. Basic things like g.region, r.info, etc. also appear to be OK.We would be grateful if someone can drop a line pointing us to a way to run r.diversity and/or any other comment you might thing useful.Kind regards,Luigi-Original Message-From: lpo...@inbox.comSent: Fri, 7 Mar 2014 07:13:40 -0800To: kratocha...@gmail.comSubject: Re: [GRASS-user] r.diversity (r.li) options on windows
Hi Anna,-Original Message-From: kratocha...@gmail.comSent: Fri, 7 Mar 2014 08:42:21 -0500To: lpo...@inbox.comSubject: Re: [GRASS-user] r.diversity (r.li) options on windows[...]This part of error is not related and I fixed it in r59209.Then I will have to try compilation from source a bit harder. I have failed so far -- interesting that I was able to compile GRASS from source on windows 7 some time ago using OSGeo4W, likely because there are fewer degrees of freedom compared to Linux.
Traceback (most recent call last):
File "/usr/lib/grass70/etc/gui/wxpython/lmgr/frame.py",
line 1003, in OnAboutGRASS
win = AboutWindow(self)
File
"/usr/lib/grass70/etc/gui/wxpython/gui_core/ghelp.py", line
57, in __init__
for title, win in ((_("Info"), self._pageInfo()),
File
"/usr/lib/grass70/etc/gui/wxpython/gui_core/ghelp.py", line
112, in _pageInfo
label = 'GRASS GIS ' + vInfo['version'] + '\n')
KeyError
:
'version'
This looks like g.version segfaults. What happens when you run:g.version -rgeHere is what happens (in GRASS prompt): g.version -rgeversion=7.0.svndate=2014revision=build_date=2014-03-04Segmentation fault (core dumped)That's it. Kind regards and thank you,Luigi
Free Online Photosharing - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
Free Online Photosharing - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.diversity (r.li) options on windows
Hi Markus, I have installed grass70 on a virtualBox with OSGeo Live 7.0 GRASS precompiled version from: https://launchpad.net/~grass/+archive/grass-devel ppa:grass/grass-devel Installed precompiled version: 7.0.0+0ubuntu3~develppa~2~svn-30128~ubuntu12.04.1 which the repository says is 9 hrs hold, and hence I assume includes r.li.* updates by Markus Metz. Start GRASS from terminal with grass70 is fine. If I go menuwise in wxpython gui: Settings Addons extenstions install extensions from Addons g.extension gui reports the following error: Unable to load extensions and when trying to fecth extensions, the same occurs. Other things appear not to work properly. For example, again in the gui: Help About GRASS GIS Nothing happens and commmand console reports the following: Traceback (most recent call last): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 6469, in OnKeyDown id = self.FindItem(self._current, self._findPrefix + ch) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4151, in FindItem id = self.GetNext(id) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4036, in GetNext children = i.GetChildren() AttributeError : 'NoneType' object has no attribute 'GetChildren' Traceback (most recent call last): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 6469, in OnKeyDown id = self.FindItem(self._current, self._findPrefix + ch) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4151, in FindItem id = self.GetNext(id) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4036, in GetNext children = i.GetChildren() AttributeError : 'NoneType' object has no attribute 'GetChildren' Traceback (most recent call last): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 6469, in OnKeyDown id = self.FindItem(self._current, self._findPrefix + ch) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4151, in FindItem id = self.GetNext(id) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4036, in GetNext children = i.GetChildren() AttributeError : 'NoneType' object has no attribute 'GetChildren' Traceback (most recent call last): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 6300, in OnKeyDown if not self.IsItemEnabled(self._current): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 2661, in IsItemEnabled return item.IsEnabled() AttributeError : 'NoneType' object has no attribute 'IsEnabled' Traceback (most recent call last): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 6469, in OnKeyDown id = self.FindItem(self._current, self._findPrefix + ch) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4151, in FindItem id = self.GetNext(id) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4036, in GetNext children = i.GetChildren() AttributeError : 'NoneType' object has no attribute 'GetChildren' Traceback (most recent call last): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 6469, in OnKeyDown id = self.FindItem(self._current, self._findPrefix + ch) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4151, in FindItem id = self.GetNext(id) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4036, in GetNext children = i.GetChildren() AttributeError : 'NoneType' object has no attribute 'GetChildren' Traceback (most recent call last): File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 6469, in OnKeyDown id = self.FindItem(self._current, self._findPrefix + ch) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4151, in FindItem id = self.GetNext(id) File /usr/lib/python2.7/dist- packages/wx-2.8-gtk2-unicode/wx/lib/agw/customtreectrl.py, line 4036, in GetNext children = i.GetChildren() AttributeError : 'NoneType' object has no attribute 'GetChildren' Traceback (most recent call last): File /usr/lib/grass70/etc/gui/wxpython/lmgr/frame.py, line 1003, in OnAboutGRASS win = AboutWindow(self) File /usr/lib/grass70/etc/gui/wxpython/gui_core/ghelp.py, line 57, in __init__ for title, win in ((_(Info), self._pageInfo()), File /usr/lib/grass70/etc/gui/wxpython/gui_core/ghelp.py, line 112, in _pageInfo label = 'GRASS GIS ' + vInfo['version'] + '\n') KeyError : 'version' Sounds like a Python problem but I am not sure how to deal with
Re: [GRASS-user] r.diversity (r.li) options on windows
Hi Anna,-Original Message-From: kratocha...@gmail.comSent: Fri, 7 Mar 2014 08:42:21 -0500To: lpo...@inbox.comSubject: Re: [GRASS-user] r.diversity (r.li) options on windows[...]This part of error is not related and I fixed it in r59209.Then I will have to try compilation from source a bit harder. I have failed so far -- interesting that I was able to compile GRASS from source on windows 7 some time ago using OSGeo4W, likely because there are fewer degrees of freedom compared to Linux.
Traceback (most recent call last):
File "/usr/lib/grass70/etc/gui/wxpython/lmgr/frame.py",
line 1003, in OnAboutGRASS
win = AboutWindow(self)
File
"/usr/lib/grass70/etc/gui/wxpython/gui_core/ghelp.py", line
57, in __init__
for title, win in ((_("Info"), self._pageInfo()),
File
"/usr/lib/grass70/etc/gui/wxpython/gui_core/ghelp.py", line
112, in _pageInfo
label = 'GRASS GIS ' + vInfo['version'] + '\n')
KeyError
:
'version'
This looks like g.version segfaults. What happens when you run:g.version -rgeHere is what happens (in GRASS prompt): g.version -rgeversion=7.0.svndate=2014revision=build_date=2014-03-04Segmentation fault (core dumped)That's it. Kind regards and thank you,Luigi
Free Online Photosharing - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.diversity (r.li) options on windows
Hi Markus, Thanks to you and Markus Metz! We will immediately go after your suggestion and report back ASAP. Kind regards, Luigi -Original Message- From: nete...@osgeo.org Sent: Sun, 23 Feb 2014 23:51:38 +0100 To: lpo...@inbox.com Subject: Re: [GRASS-user] r.diversity (r.li) options on windows Hi Luigi, over the past few weeks Markus Metz has submitted a major rewrite of r.li.* to GRASS GIS 7.svn. We tested the older version a lot which is containing a lot of errors. Suggestion: get a fresh GRASS 7 from SVN (or precompiled, see http://grass.osgeo.org/grass7/ ) and use the r.diversity Addon for GRASS 7. Backporting the r.li.* rewrite is quite some effort, not sure how to deal with that. Best Markus FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.diversity (r.li) options on windows
Hello, replying to myself to report an attempt at running r.diversity using the virtual machine option, i.e. osgeo-live-vm-7.0 on windows 7 installed as shown at http://live.osgeo.org/en/quickstart/virtualization_quickstart.html In GRASS 6.4.3, settings - Addons estensions - Install extension from addons [g.extension]; fetched repository (http://svn.osgeo.org/grass/grass-addons/grass6) via Fetch button; selected raster - r.diversity, and pressed Install butto; received the following output message at GUI command console: g.extension.py extension=r.diversity svnurl=http://svn.osgeo.org/grass/grass-addons/grass6 Fetching r.diversity from GRASS-Addons SVN (be patient)... svn: Can't move 'r.diversity/.svn/tmp/entries' to 'r.diversity/.svn/entries': File exists ERROR: GRASS Addons r.diversity not found (Fri Feb 21 15:51:11 2014) Command finished (15 sec) Is there a way to do a GUI install or, as suggested in the g.extension help page, one should just copy the r.diversity.py script to the grass addons directory (e.g., /grassdata/addons/scripts/)? Thanks for any pointer, Luigi -Original Message- From: lpo...@inbox.com Sent: Tue, 28 Jan 2014 12:58:59 +0100 To: grass-user@lists.osgeo.org Subject: [GRASS-user] r.diversity (r.li) options on windows Hi there, As part of a master's thesis, we would like to use r.diversity to process aerial multi-spectral imagery using a Windows 7 machine. (The most recent piece of info is apparently this grass-devel thread: http://article.gmane.org/gmane.comp.gis.grass.devel/56124 Putting Luca and Alessandro in copy because of this related thread: http://article.gmane.org/gmane.comp.gis.gfoss.italian/12245 ) As the r.li suite appears still broken on Windows, http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Known_Issues we were wondering whether it would be wiser to go the g.gui.rlisetup way http://grass.osgeo.org/grass70/manuals/g.gui.rlisetup.html or to opt for a virtual machine installation, e.g. http://live.osgeo.org/en/quickstart/virtualization_quickstart.html In general, is there any advantage in using grass 7 vs. 6 in our case? Kind regards and thanks for any pointer, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user Receive Notifications of Incoming Messages Easily monitor multiple email accounts access them with a click. Visit http://www.inbox.com/notifier and check it out! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.diversity (r.li) options on windows
Hi there, As part of a master's thesis, we would like to use r.diversity to process aerial multi-spectral imagery using a Windows 7 machine. (The most recent piece of info is apparently this grass-devel thread: http://article.gmane.org/gmane.comp.gis.grass.devel/56124 Putting Luca and Alessandro in copy because of this related thread: http://article.gmane.org/gmane.comp.gis.gfoss.italian/12245 ) As the r.li suite appears still broken on Windows, http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Known_Issues we were wondering whether it would be wiser to go the g.gui.rlisetup way http://grass.osgeo.org/grass70/manuals/g.gui.rlisetup.html or to opt for a virtual machine installation, e.g. http://live.osgeo.org/en/quickstart/virtualization_quickstart.html In general, is there any advantage in using grass 7 vs. 6 in our case? Kind regards and thanks for any pointer, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Request for GRASS GIS case studies
On 25/11/2012 00:16, Markus Neteler wrote: Hi Luigi, [...] PS: I took liberty to add the DOIs and PDF links Thanks Markus: I need to improve my Wiki editing skills. Ciao, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Request for GRASS GIS case studies
Hi Markus, I made a first attempt at a GRASS case study based on two open access papers, see http://grasswiki.osgeo.org/wiki/Case_studies/GlobalChangeBiology Would you or any other list member let me know if that is any close to what was expected -- or any other suggestion for that matter. Kind regards, Luigi -Original Message- From: nete...@osgeo.org Sent: Fri, 31 Aug 2012 23:29:09 +0200 To: lpo...@inbox.com Subject: Re: [GRASS-user] Request for GRASS GIS case studies Dear Luigi On Mon, Aug 20, 2012 at 7:54 PM, Luigi Ponti lpo...@inbox.com wrote: Dear Markus, On 02/08/2012 20:04, Markus Neteler wrote: Dear all, since outstanding things are done with GRASS GIS, we should better showcase the capabilities of this software. I would like to propose to write up case studies in the Wiki which would, at the same time, give visibility to you, your company or institution. Is there already a wiki place/page where to start? I have noticed an Applications page in the wiki: http://grass.osgeo.org/wiki/Applications would that be the place? I have started http://grass.osgeo.org/wiki/Case_studies and would suggest to then cross-link in http://grass.osgeo.org/wiki/Applications We have a couple of so-called open access papers with GIS analysis performed using GRASS from which it would be easy to draw material under CC-ShareAlike license (they are Creative Commons Attribution CC BY). Sounds very good :) Best Markus FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Send full script syntax from g.parser to log file
Dear list, I have been looking around for this info to no avail. When calling a script that has g.parser inside with no arguments, the auto-generated GUI pops up and includes an option (button) to copy to clipboard the full syntax used to launch the script. Would there be a way to send the same full syntax to for example a log file? You can of course rebuild the command line from the g.parser variables, and send that to a file. I was just wondering if the strings that g.parser collects to compose the command line on the GUI window were accessible somehow. Kind regards and thank you, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Request for GRASS GIS case studies
Dear Markus, On 02/08/2012 20:04, Markus Neteler wrote: Dear all, since outstanding things are done with GRASS GIS, we should better showcase the capabilities of this software. I would like to propose to write up case studies in the Wiki which would, at the same time, give visibility to you, your company or institution. Is there already a wiki place/page where to start? I have noticed an Applications page in the wiki: http://grass.osgeo.org/wiki/Applications would that be the place? We have a couple of so-called open access papers with GIS analysis performed using GRASS from which it would be easy to draw material under CC-ShareAlike license (they are Creative Commons Attribution CC BY). Kind regards, Luigi Examples: - PostGIS case studies: http://postgis.refractions.net/documentation/casestudies/ - QGIS case studies: http://qgis.org/en/community/qgis-case-studies.html Also non-english case studies are fine! If possible we may translate them to different languages - the Wiki supports multiple languages. Random ideas: - GRASS usage in public administration - massive data analysis - attractive visualization - ... unlimited further ideas :) They should have a CC-ShareAlike or similar license to make it easy to the press to pick it up and republish elsewhere. best Markus ___ 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] Copying a location subset to a new location
On 02/08/2012 01:26, Markus Neteler wrote:
On Mon, Jul 30, 2012 at 7:31 PM, Luigi Ponti lpo...@inbox.com wrote:
Hello list.
I have been making subset copies of GRASS locations using (the very useful)
g.laptop.sh add-on
...
Currently it is the only approach I could find.
I used r.pack/r.unpack and v.pack/v.unpack in the past which
packages maps individually. Using g.mlist or likewise you could
write a for loop to package a set of maps.
Thanks Markus:
I did not know about those grass7 addons. The vector versions are there
in the trac svn browser. However, I don't see the raster ones
(r.pack/r.unpack).
At any rate, I have modified g.laptop.sh to run using the g.parser
interface. Cleaned up indentation and comments a bit. I am not sure it
can be useful. Maybe it could function as a g.copy.location
kind-of-thing. It still has a problem with deleting tmp raster folder at
the end of the script. Other than that, it seems to work fine on my Win7
32-bit box under winGRASS 64svn. It is attached for review just in case.
Kind regards,
Luigi
#!/bin/sh
#
#
# MODULE: g.laptop_non_interactive.sh
#
# AUTHOR(S):Otto Dassau das...@gbd-consult.de
# Cleaned-up and edited by Luigi Ponti lponti inbox com
# to run in non interactive mode via the g.parser interface.
#
# PURPOSE: Script to extract raster and vector data from current
# location into a new one. Data can be copied or extracted
# in current or original resolution and region extent.
#
# COPYRIGHT:(C) 2002-2012 by the GRASS Development Team
#
# This program is free software under the GNU General Public
# License (=v2). Read the file COPYING that comes with GRASS
# for details.
#
# COMMENTS: Sometimes extracting vector maps at current region extent
# with v.extract doesn't work properly - use copy instead!!
#
#
#%module
#% description: Makes a copy of the current location
#%end
#%option
#% guisection: Main
#% key: newLocation
#% type: string
#% description: New (target) location name
#% required : yes
#%end
#%option
#% key: rasterList
#% type: string
#% answer: all
#% description: List of raster maps to copy (separated by space)
#%end
#%option
#% key: vectorList
#% type: string
#% description: List of vector maps to copy (separated by space)
#%end
#%flag
#% key: r
#% answer: 1
#% description: Export raster maps at original instead of current resolution
#%end
#%flag
#% key: v
#% description: Clip vector maps to current region extent
#%end
#%flag
#% key: t
#% description: Put new location in a compressed *.tar.gz archive
#%end
#%flag
#% key: d
#% description: Delete uncompressed location after *.tar.gz archive creation
#%end
if [ -z $GISBASE ] ; then
echo You must be in GRASS GIS to run this program. 12
exit 1
fi
if [ $1 != @ARGS_PARSED@ ] ; then
exec g.parser $0 $@
fi
# Get path for current location
eval `g.gisenv`
: ${GISBASE?} ${GISDBASE?} ${LOCATION_NAME?} ${MAPSET?}
LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET
### cleanup in case of ERROR
cleanup()
{
if test $LOCNAME
then
echo delete already build location $LOCNAME?
\rm -ir $GISDBASE/$LOCNAME/
\rm -rf $CURRWD/tmp/$LOCNAME/
g.remove vect=mxy999
fi
}
### restore .grassrc6 in case of ERROR
restore()
{
if test -f $CURRWD/tmp/$LOCNAME/$LOCNAME.grassrc6 ; then
mv $CURRWD/tmp/$LOCNAME/$LOCNAME.grassrc6 $HOME/.grassrc6
fi
}
### what to do in case of user break:
exitprocedure()
{
echo
echo User break!
cleanup
restore
echo cleanup temporary files and restore .grassrc6
exit 1
}
### shell check for user break (signal list: trap -l)
trap exitprocedure 2 3 9 15
# Set script parameters
if [ -n $GIS_OPT_NEWLOCATION ] ; then
LOCNAME=$GIS_OPT_NEWLOCATION
fi
if [ -n $GIS_OPT_RASTERLIST ] ; then
LISTR=$GIS_OPT_RASTERLIST
fi
if [ -n $GIS_OPT_VECTORLIST ] ; then
LISTV=$GIS_OPT_VECTORLIST
fi
# Create new location or exit if it exists already
if test -d $GISDBASE/$LOCNAME ; then
echo
echo Location $LOCNAME exists already
echo
echo choose another name
exit 1
else
mkdir -p $GISDBASE/$LOCNAME/PERMANENT/
fi
### manage linked grassdata files
CGISDBASE=$GISDBASE
CURRWD=$HOME
VECTLOC=$GISDBASE/$LOCNAME/PERMANENT
cd $GISDBASE/$LOCATION_NAME/PERMANENT
cp -f PROJ_INFO PROJ_UNITS DEFAULT_WIND $VECTLOC
cd $LOCATION
cp -f WIND $VECTLOC
#cp WIND $VECTLOC/DEFAULT_WIND
cd $CURRWD
### Copy rasters
mkdir -p $CURRWD/tmp/$LOCNAME/rast/
mkdir $VECTLOC/colr
### save current region and resolution for later restore
CEWRES=`g.region -p | awk
[GRASS-user] Copying a location subset to a new location
Hello list. I have been making subset copies of GRASS locations using (the very useful) g.laptop.sh add-on http://grass.osgeo.org/wiki/GRASS_AddOns#g.laptop.sh It can only be run interactively, and that becomes a bit tedious with more than a few maps. Hence I wonder if g.laptop.sh is the only approach to sub-setting GRASS locations (i.e., copying a location subset to a new location). Currently it is the only approach I could find. Kind regards and thank you in advance for any hints, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Natural breaks classification
On 18/05/2012 11:30, Roger Bivand wrote: Since all Spatial*DataFrame objects behave link data.frame objects, you can say: DTM- readRAST6(DTM@mapset, ignore.stderr=TRUE) DTM_class- classIntervals(DTM.df$varOfInterest, n=5, style=fisher) I apologize about my imprecise statement that a Spatial*DataFrame object would require to be treated as.data.frame in order to be fed to classIntervals(). I recalled that some R functions complained about SpatialGridDataFrame objects but it may just be my faulty memory. Thanks for a great post. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Natural breaks classification
Hi Salvatore, On 16/05/2012 17:38, Salvatore Mellino wrote: Hi, I have a DTM raster map and I want to classify it in 5 classes by means of natural break method (http://en.wikipedia.org/wiki/Jenks_natural_breaks_optimization). Is it possible with GRASS. I usually do that via the R package classInt http://cran.r-project.org/web/packages/classInt/index.html which requires using the GRASS-R interface. For a general overview of the integration, see http://grass.osgeo.org/wiki/R_statistics Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] High-resolution agricultural land cover from satellite imagery
Dear Markus On 16/05/2012 14:19, Markus Neteler wrote: ... You may use neural networks in R (using the GRASS-R interface). For a general overview of the integration, see http://grass.osgeo.org/wiki/R_statistics Right. Sometimes I forget the secret weapon... ... As my master thesis, I wrote these two modules: i.spec.sam: Spectral Angle mapping http://grass.osgeo.org/wiki/Addons#i.spec.sam i.spec.unmix: Spectral unmixing http://grass.osgeo.org/wiki/Addons#i.spec.unmix The latter needs proper update to GRASS 6 but that should not be too hard. I had a feeling I was missing something important. In the description of the two add-on modules, I found reference to two very interesting papers that triggered some more search. In particular, this conference paper by Stabile et al. (2009) on Fusion of High-resolution Aerial Orthophoto with LandSat TM Image for Improved Object-based Land-use Classification, uses the same data layers I may access (orthophoto + Landsat TM): http://www.a-a-r-s.org/acrs/proceeding/ACRS2009/Papers/Oral%20Presentation/TS12-05.pdf based on which, I wonder if it would make any sense to perform i.fusion e.g. i.fusion.brovey -l ms1=lsat7_2002_20 ms2=lsat7_2002_40 \ ms3=lsat7_2002_50 pan=ortho_photo_rgb_composite \ outputprefix=brovey and then use i.smap after i.gensigset (the use of group= and subgroup= parameters in both modules is a bit unclear to me) to classify the map using areas with known land cover class identified via the orthophoto itself or field survey. Kind regards and thank you (and pardon my ignorance), Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Natural breaks classification
On 16/05/2012 20:55, Salvatore Mellino wrote: I'm trying but I receive an error. 1. In R I started the libraries spgarass6 and classInt 2. I imported the DTM in R using DTM- readRAST6(DTM@mapset, ignore.stderr=TRUE) 3. I used the commandDTM_class- classIntervals(DTM, n=5, style=fisher) and I received the error Error in classIntervals(DTM, n = 5, style = fisher) : var is not numeric I do not recall exactly, but it may be that classIntervals does not have a method for spatial data frames (i.e. the output of readRAST6). One thing I would try to get the breaks anyway, is a regular R data.frame, for example: DTM.df - as.data.frame(DTM) DTM_class - classIntervals(DTM.df, n=5, style=fisher) Hope this helps, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Natural breaks classification
On 16/05/2012 21:10, Luigi Ponti wrote: On 16/05/2012 20:55, Salvatore Mellino wrote: I'm trying but I receive an error. 1. In R I started the libraries spgarass6 and classInt 2. I imported the DTM in R using DTM- readRAST6(DTM@mapset, ignore.stderr=TRUE) 3. I used the commandDTM_class- classIntervals(DTM, n=5, style=fisher) and I received the error Error in classIntervals(DTM, n = 5, style = fisher) : var is not numeric I do not recall exactly, but it may be that classIntervals does not have a method for spatial data frames (i.e. the output of readRAST6). One thing I would try to get the breaks anyway, is a regular R data.frame, for example: DTM.df - as.data.frame(DTM) DTM_class - classIntervals(DTM.df, n=5, style=fisher) I am replying to myself as I may have omitted part of the answer -- my apologies. Start the same way: DTM.df - as.data.frame(DTM) then get variable names: names(deltaYieldVector.df) then use the variable of interest (altitude, I guess): DTM_class - classIntervals(DTM.df$varOfInterest, n=5, style=fisher) This should work; we were feeding a data.frame as input to classIntervals, whereas a variable is needed (e.g. one of the variables in the data.frame). Let me know how it goes. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] High-resolution agricultural land cover from satellite imagery
Dear 山田 康晴, Thanks for your kind reply. On 15/05/2012 03:18, 山田 康晴 wrote: I wonder why you want to use the Landsat TM data for the analysis of the high resolusion agricultural land cover. The reason is that I found that paper I cited in my previous email (Tatem et al. 2003; http://eprints.soton.ac.uk/260104/1/tatem_tgis.pdf), which described a way to increase resolution of land cover. I thought higher resolution would be a good thing because of the highly fragmented agricultural landscape I was targeting (the paper by Tatem and colleagues also analyzes an area with small-scale agriculture in Greece). The Landsat TM, not ETM, has very long histry and is not the High-resolution data as for both spatial and frequential points of view. There are so many research papers for the analysis on agricultural land cover. I have accessed the grass-user mailing list seeking for a possible GRASS-based approach to the task. Hence, I would be very glad if you could point to a couple of the research papers you refer to. The esa or Italy scientists must have much information for your interest. Are you a scientist in Italy? Yes, I am based in Italy and my background is mostly in applied ecology. Of course people at ESA are expert in the field. My goal when accessing this mailing list was to see if more GRASS-related info on the topic would emerge that may benefit me and other GRASS users. Kind regards and thank you, Luigi We are targeting an agricultural area in southern Italy (several thousands hectares) for which we have full orthophoto coverage (0.5 meters resolution), and Landsat TM data can apparently be downloaded freely from http://glcf.umd.edu/data/landsat/. High-resolution agricultural land cover might seem overkill, but the area is highly fragmented and hence standard CORINE land cover data tend to classify most of the land as mixed types (not very helpful). I would like to ask a general recommendation on the best way to approach an agricultural land cover task such as the one outlined above, together with possible info on previous implementation of increasing spatial resolution of agricultural land cover maps in GRASS via neural networks or other approaches. Kind regards, thanks in advance and apologies for a long post, Luigi ___ 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
[GRASS-user] High-resolution agricultural land cover from satellite imagery
Dear GRASS users, (This is kind of new topic to me.) After reading this paper that addresses the mixed-pixel issue via neural networks using Landsat Thematic Mapper (TM) data: Tatem, A. J., Lewis, H. G., Nixon, M. S. and Atkinson, P. (2003) Increasing the spatial resolution of agricultural land cover maps using a Hopfield neural network. Int Journal of Geographic Information Sciences, 17, (7), 647-672. http://eprints.soton.ac.uk/260104/1/tatem_tgis.pdf I have searched for GRASS documentation on image classification, particularly on land cover. The starting point is the wiki page on image classification http://grass.osgeo.org/wiki/Image_classification as well as section 8.6 of the GRASS book (Thematic classification of satellite data). They both give good basic reference info, but additional pointers a welcome. Also found some neural network work on the topic done with GRASS http://www.ncgia.ucsb.edu/conf/SANTA_FE_CD-ROM/sf_papers/muttiah_ranjan/muttiah.html, which seems relevant but implemented in GRASS 4.1, and hence I am unsure it survived inside a GRASS module to date (at least, I could not find it). We are targeting an agricultural area in southern Italy (several thousands hectares) for which we have full orthophoto coverage (0.5 meters resolution), and Landsat TM data can apparently be downloaded freely from http://glcf.umd.edu/data/landsat/. High-resolution agricultural land cover might seem overkill, but the area is highly fragmented and hence standard CORINE land cover data tend to classify most of the land as mixed types (not very helpful). I would like to ask a general recommendation on the best way to approach an agricultural land cover task such as the one outlined above, together with possible info on previous implementation of increasing spatial resolution of agricultural land cover maps in GRASS via neural networks or other approaches. Kind regards, thanks in advance and apologies for a long post, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Managing the Harmonized World Soil Database in GRASS
On 25/03/2011 11:25, Luigi Ponti wrote: Dear Rich, The HWSD is composed of a raster image file and a linked attribute database stored in Microsoft Access 2003 format. It would be nice if the attributes were made available in a format using open standards. That would make it available to those of us who don't do windows. Rich You are right. [...] I have inquired the data provider about the issue, and will let the list know. Here is what the data provider replied: Thank you for your suggestion. The raster file is already available in an open format, since it is just a binary table. In the database file (HWSD.mdb), there is one main table in the database, the HWSD_Data table, that contains all the soil data. The other tables simply describe the codes and abbreviations. The simplest and most transferable option would be to export this HWSD_Data as a text file along with a document listing all the codes and abbreviations. At the moment, anyone with Access can do this for others. However, your point is well taken and we will consider making such a text file and perhaps other database formats available on our website with our next update. The viewer cannot so easily be transferred to other operating systems and we have no plan to do so. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Managing the Harmonized World Soil Database in GRASS
Dear Rich, The HWSD is composed of a raster image file and a linked attribute database stored in Microsoft Access 2003 format. It would be nice if the attributes were made available in a format using open standards. That would make it available to those of us who don't do windows. Rich You are right. There is a driver apparently more advanced than the OpenOffice.org one, which I haven't tried yet: http://www.kexi-project.org/wiki/wikiview/index@mdbdriver.html I have inquired the data provider about the issue, and will let the list know. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Managing the Harmonized World Soil Database in GRASS
On 25/03/2011 11:44, Sylvain Maillard wrote: Hi, some month ago I had to make some maps with the HWSD database. I used the mdbtool (http://mdbtools.sourceforge.net/) to extract all tables from the .mdb file to some sql files. Then I just imported all the table in a postgres database, and it is quite easy to access them in GRASS ... Regards, Sylvain Hi Sylvain, Thanks for your answer. I see your point. After exporting the .mdb to PostgreSQL you can db.connect to it from the GRASS mapset where the HWSD soil map is. However, I do not see how you can then get the data on the map, given that a database links to a vector whereas the HWSD map is a raster. How did you map the connected database? It would be nice if you could share a bit more of your experience with mapping HWSD data. Kind regards and thank you, Luigi 2011/3/24 Luigi Ponti lpo...@inbox.com mailto:lpo...@inbox.com Dear listers, I seem to have successfully imported the Harmonized World Soil Database (HWSD) in BIL format to GRASS 6.4.svn via r.in.gdal. The data is available at http://www.iiasa.ac.at/Research/LUC/luc07/External-World-soil-database/HTML/index.html The HWSD is composed of a raster image file and a linked attribute database stored in Microsoft Access 2003 format. According to the documentation (page 28) http://www.iiasa.ac.at/Research/LUC/External-World-soil-database/HWSD_Documentation.pdf using the HWSD database in a GIS should be straightforward. The MU_GLOBAL attribute column in the database is also stored in each raster cell, and may therefore be considered as the link to the raster. My goal would be to obtain more raster maps that show other (soil) attributes from the database or combination of different attributes based on computations. The documentation suggests the following work flow: - if necessary, realize the appropriate calculations (ex: after exporting from Access to Excel); - convert final attributes table to a compatible GIS format; - join the MU_GLOBAL attribute and the GRID value (dbf or txt formats); - convert the attribute to a new GRID (in the case it is needed). What comes to mind is value replacement using r.recode but maybe there is a better course of action. This is seemingly the best available soil GIS database with global coverage, so I thought my question may be useful to others. Kind regards and thanks in advance for any hint, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org mailto: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
[GRASS-user] Managing the Harmonized World Soil Database in GRASS
Dear listers, I seem to have successfully imported the Harmonized World Soil Database (HWSD) in BIL format to GRASS 6.4.svn via r.in.gdal. The data is available at http://www.iiasa.ac.at/Research/LUC/luc07/External-World-soil-database/HTML/index.html The HWSD is composed of a raster image file and a linked attribute database stored in Microsoft Access 2003 format. According to the documentation (page 28) http://www.iiasa.ac.at/Research/LUC/External-World-soil-database/HWSD_Documentation.pdf using the HWSD database in a GIS should be straightforward. The MU_GLOBAL attribute column in the database is also stored in each raster cell, and may therefore be considered as the link to the raster. My goal would be to obtain more raster maps that show other (soil) attributes from the database or combination of different attributes based on computations. The documentation suggests the following work flow: - if necessary, realize the appropriate calculations (ex: after exporting from Access to Excel); - convert final attributes table to a compatible GIS format; - join the MU_GLOBAL attribute and the GRID value (dbf or txt formats); - convert the attribute to a new GRID (in the case it is needed). What comes to mind is value replacement using r.recode but maybe there is a better course of action. This is seemingly the best available soil GIS database with global coverage, so I thought my question may be useful to others. Kind regards and thanks in advance for any hint, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.barscale draws bar up to right edge of map
Dear list, I have found problems with d.barscale mentioned in bug tracker only for grass 7. When trying to draw a scale bar using PNG driver in grass6.4.svn on windows7 (couple of months old -- it is the last version I have that does not need to delete vectors twice, see http://trac.osgeo.org/grass/ticket/1158), the scale bar starts ok at specified coordinates but then keeps going up to the right edge of the map -- see sample output: https://docs.google.com/leaf?id=0B0EpsfMZ-IZYMmY3YzdjMDQtNjA4Yy00YzU2LTgzZDktMGZhODcwODkzODRksort=namelayout=listnum=50 No text is drawn even if one tries to move it on top of the bar with -t. This happens with any kind of combination of flags. Is there a known way around this? Kind regards and thank you, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Location of g.remove source code
Hi list, Quick question: where in the source tree does g.remove live? I was not able to find it in the /general/ folder (or anywhere else, for that matter). Kind regards and thank you, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.grid fails with -g flag in winGRASS
Hi there, Working on Win7 with today's binary snapshot WinGRASS-6.4.SVN-r43880 in North Caroline location. Issuing the following command (either via Cmd text box or the button in the wxGUI): d.grid -g size=0.01 triggers an error pop up saying: Execution failed: 'd.grid -g size=0.01 --q' Details: Error: Unable to set up lat/long projection parameters While the following: d.grid -w size=0.01 works fine. Anybody experiencing the same error? Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Revision number of GRASS binary
Dear list, Is there a way to get the svn release number of a GRASS binary from the command line? Here, 'g.version -r' yields a number (43636) that is different from the number in the installer name (43880) WinGRASS-6.4.SVN-r43880-1-Setup.exe Or maybe they are simply two different things. Kind regards and thank you, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] MDOW relief shading in GRASS
Date: Thu, 30 Sep 2010 11:55:53 +0800 From: maning sambale emmanuel.samb...@gmail.com Subject: [GRASS-user] MDOW relief shading in GRASS To: grass list grass-user@lists.osgeo.org Message-ID: aanlktikf+ehap=rfycktqu_2c5zdyv1twc4qzvz7v...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hi, I am revisiting a previous script I made in producing Multidirectional, oblique-weighted, shaded-relief. ArcGis has this script: http://blogs.esri.com/Support/blogs/mappingcenter/archive/2008/10/07/updated-hillshade-toolbox.aspx [...] But I get not so good results, here's the output using nc_sp_08's elev_ned_30m (X0=MDOW, X1= default r.shaded.relief module) http://farm5.static.flickr.com/4148/5037622535_113924312b_b.jpg Anything wrong with my commands? Judging by eye, it looks like you are getting pretty much what one would expect. Reading the esri post, reminded me that there is a web page describing how to get the generalized hillshade that is described in the same post before MDOW: http://www.pdcarto.com/mtncarto02/GRASS.htm Maybe of help to someone. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.in.ascii fails with long text file in WinGRASS-6.4.0-1
On 21/09/2010 10:00, Glynn Clements wrote:
Luigi Ponti wrote:
Any ideas? A change introduced in 6.4.0-1 has rendered WinGRASS
unusable to me [...]
[...] is there a way to compile the code
in the state it was before the issue arose?
You can prevent the error with:
--- vector/v.in.ascii/in.c~ 2010-09-04 16:31:59.0 +0100
+++ vector/v.in.ascii/in.c 2010-09-21 08:57:12.0 +0100
@@ -519,8 +519,7 @@
if (driver) {
G_message(_(Populating table...));
db_commit_transaction(driver);
- if(db_close_database_shutdown_driver(driver) == DB_FAILED)
- G_fatal_error(_(Could not close attribute table. The DBMI driver
did not accept all attributes));
+ db_close_database_shutdown_driver(driver);
}
fclose(tmpascii);
}
db_close_database_shutdown_driver() is incorrectly reporting errors on
Windows. v.in.ascii is the only module which checks the return status,
so it's the only module which is affected.
Implemented your patch to changeset 4359 releasebranch_6_4, compiled
following instructions at
http://trac.osgeo.org/grass/wiki/CompileOnWindows, and it works for
the following simple test (see
http://trac.osgeo.org/grass/ticket/1159#comment:13):
GRASS 6.4 echo 10|10|abcd | v.in.ascii out=test
Scanning input for column types...
Maximum input row length: 11
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: double
Column: 2 type: double
Column: 3 type: string length: 4
Importando punti ...
100%
Populating table...
Building topology for vector map test...
Registering primitives...
1 primitives registered
1 vertices registered
Building areas...
100%
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
100%
Number of nodes: 1
Number of primitives: 1
Number of points: 1
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
v.in.ascii completo.
The point can be displayed, and the dbf table seems ok. Also works using
a longer sample text file I previously linked
https://docs.google.com/leaf?id=0B0EpsfMZ-IZYNGZlNWZkMWEtNzhiNS00OGRiLTgyNzctYzk4ODUxODk1NzI1sort=namelayout=listnum=50
GRASS 6.4 v.in.ascii --overwrite input=Bloomday_Olive_11set10_Avg
output=test_US_import fs=tab
ATTENZIONE: Vector map test_US_import already exists and will be
overwritten
Scanning input for column types...
Maximum input row length: 31
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: double
Column: 2 type: double
Column: 3 type: double
Importando punti ...
100%
Populating table...
Building topology for vector map test_US_import...
Registering primitives...
1157 primitives registered
1157 vertices registered
Building areas...
100%
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
100%
Number of nodes: 1154
Number of primitives: 1157
Number of points: 1157
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
v.in.ascii completo.
I am not sure as to whether this should be reported on
http://trac.osgeo.org/grass/ticket/1159.
Related ticket 1158 http://trac.osgeo.org/grass/ticket/1158 seems to
persist:
GRASS 6.4 v.in.ascii --overwrite
input=C:/cygwin/home/andy/models_temp/Bloomd
ay_Olive_11set10_Avg output=test_US_import fs=tab
ATTENZIONE: Vector map test_US_import already exists and will be
overwritten
ATTENZIONE: Unable to delete file
'C:\cygwin\home\andy/latlong/luigi/vector/test_US_import/hist'
ERRORE: Unable to delete vector map test_US_import
Still not entirely clear to me which variable I am supposed to set in
order to get full English messages.
Thanks and regards,
Luigi
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.in.ascii fails with long text file in WinGRASS-6.4.0-1
On 14/09/2010 17:34, Luigi Ponti wrote: Dear list, [...] Ticket created. Any ideas? A change introduced in 6.4.0-1 has rendered WinGRASS unusable to me [...] Thanks for the work on ticket #1159 http://trac.osgeo.org/grass/ticket/1159 I am wondering if there is a way by which I can restore v.in.ascii functionality in 6.4.0 until a fix is found for the problem. I am probably asking an unsound question: is there a way to compile the code in the state it was before the issue arose? During the first half of this year, Windows installers based on 6.4.svn snapshots have run smoothly for critical job tasks, and I have started to rely on them. Kind regards and thank you, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] g.mremove fails when used with wildcard in WinGRASS-6.4.0-1 on windows 7
Dear list, WinGRASS-6.4.0-1 on Windows 7; wxgui g.mremove called on vector with * wildcard does not work: (Tue Sep 14 15:24:09 2010) g.mremove -f vect=map* Removing vector mapBloomday_Olive_11set10_Avg Unable to delete file 'C:\cygwin\home\andy/latlong/luigi/vector/mapBloomday_Olive_11set10_Avg/hist' couldn't be removed mapBloomday_Olive_11set10_Avg nothing removed (Tue Sep 14 15:24:10 2010) Command finished (0 sec) wxgui g.mremove called with full vector name works fine: (Tue Sep 14 15:27:01 2010) g.mremove -f vect=mapBloomday_Olive_11set10_Avg Removing vector mapBloomday_Olive_11set10_Avg (Tue Sep 14 15:27:01 2010) Command finished (0 sec) There was only that vector map starting with map* in current location. Deleting rasters with g.mremove works fine both ways. Trying same test with an old (May 29) WinGRASS-6.4.svn installed on the same machine; Wildcards work: (Tue Sep 14 15:49:46 2010) g.mremove -f vect=map* Removing vector mapBloomday_Olive_11set10_Avg (Tue Sep 14 15:49:47 2010) Command finished (1 sec) I have created a ticket for this. Kind regards and thanks for any pointer, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.ascii fails with long text file in WinGRASS-6.4.0-1
Dear list, My settings: WinGRASS-6.4.0-1 on Windows 7. Performing example v.in.ascii task showed in manual: v.in.ascii input=coords.txt output=mymap works fine in Spearfish location. Using this text file: https://docs.google.com/leaf?id=0B0EpsfMZ-IZYNGZlNWZkMWEtNzhiNS00OGRiLTgyNzctYzk4ODUxODk1NzI1sort=namelayout=listnum=50 in a latlong location with the following command: v.in.ascii input=C:\cygwin\home\andy\models_temp\Bloomday_Olive_11set10_Avg output=test_US_import fs=\t yields an error: v.in.ascii input=C:\cygwin\home\andy\models_temp\Bloomday_Olive_11set10_Avg output=test_US_import fs=\t Scanning input for column types... Maximum input row length: 31 Maximum number of columns: 3 Minimum number of columns: 3 Column: 1 type: double Column: 2 type: double Column: 3 type: double Importando punti ... Populating table... ERROR: Could not close attribute table. The DBMI driver did not accept all attributes Trying same test with an old (May 29) WinGRASS-6.4.svn installed on the same machine (same command), everything seems ok: v.in.ascii --overwrite input=C:\cygwin\home\andy\models_temp\Bloomday_Olive_11set10_Avg output=test_US_import fs=\t Scanning input for column types... Maximum input row length: 31 Maximum number of columns: 3 Minimum number of columns: 3 Column: 1 type: double Column: 2 type: double Column: 3 type: double Importando punti ... Populating table... Building topology for vector map test_US_import... Registering primitives... 10001157 primitives registered 1157 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 1154 Number of primitives: 1157 Number of points: 1157 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.in.ascii completo. Ticket created. Any ideas? A change introduced in 6.4.0-1 has rendered WinGRASS unusable to me -- or am I doing something wrong? Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] lots of The application failed to initialize properly in 6.4.0 on Windows
Hi there, Not sure this is related -- sorry if I should have started a new thread. I have a WinGRASS-6.4.SVN daily build of last May 29 installed in C:/Program Files on Windows 7, and have been running a set of GRASS shell scripts no problem under this setup. Now I have installed also WinGRASS-6.4.0-1, and running the same scripts brings up some issues. In particular, it seems that 6.4.0-1 has trouble deleting vectors via g.mremove, which also Maciek reported as problematic and that is why I replied to the present thread. For example, a cleanup subroutine in a script includes the following command: g.mremove -f vect=map* that in 6.4.SVN works fine: ... Removing vector mapBloomday_Olive_11set10_Avg ... while in 6.4.0-1 doesn't: ... Removing vector mapBloomday_Olive_11set10_Avg ATTENZIONE: Unable to delete file 'C:\cygwin\home\andy/latlong/luigi/vector/mapBloomday_Olive_11set10_Avg/hist' ATTENZIONE: couldn't be removed ATTENZIONE: mapBloomday_Olive_11set10_Avg nothing removed ... and it fails to delete three more vectors the same way. However, rasters do get deleted. In my %PATH%, I see no sign of GDAL. I do have two versions of winGRASS around, but for that matter also a Cygwin version and an OSGeo4W one. (Unrelated: is there a way to get GRASS messages 100% in English while working in an Italian locale?) Regards, Luigi -- Message: 2 Date: Sat, 11 Sep 2010 20:38:41 +0100 From: Glynn Clements gl...@gclements.plus.com Subject: Re: [GRASS-user] lots of The application failed to initialize properly in 6.4.0 on Windows To: Maciej Sieczka msiec...@sieczka.org Cc: grass-user grass-user@lists.osgeo.org, GRASS developers list grass-...@lists.osgeo.org Message-ID: 19595.56001.390451.709...@cerise.gclements.plus.com Content-Type: text/plain; charset=us-ascii Maciej Sieczka wrote: Lots of commands (e.g. g.proj, g.region, g.remove) That list looks suspiciously like programs which use GDAL. You might want to check whether there are other versions of GDAL on your system, particularly if they are in %PATH%. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Wingrass 6.4 with MSYS does not work
Dear Daniel, On 06/07/2010 14:03, Daniel Victoria wrote: Another thing I just noticed looking at grass64svn script ArcGIS has set the variable PYTHONPATH=C:\Program Files (x86)\ArcGIS\bin I don't know, but there seem to be no PYTHONPATH string in the my GRASS installation folder. Could that be related? On Tue, Jul 6, 2010 at 8:54 AM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi all, I don't see any leftover cygwin instalation in my path. I even tried removing python(xy) to see if that was the culprit. Here are some of the environmental variables set in the msys shell that I believe influences grass: PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/OpenSSH/bin:/c/Windows/System32 There is a mingw thing that may be where bash.exe comes from. Why do you need mingw in GRASS MSys? Wingrass has its own copy of MSys, and should not need to point to /mingw/bin or anything else related to unix shell. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: grass-user Digest, Vol 51, Issue 6
Dear Daniel, I have a one-month-old (apologize) wingrass 6.4.svn installed from http://josef.fsv.cvut.cz/wingrass/ on windows7. Date: Mon, 5 Jul 2010 17:11:39 -0300 From: Daniel Victoria daniel.victo...@gmail.com [...] Opening a separate MSys console and executing /grass/bin/grass64svn will start the Select location window and after I click on Start, Grass crashes with the following error: $ grass64svn Cleaning up temporary files ... Starting GRASS ... ATENÇÃO: Attention! ATENÇÃO: Locking is not supported on Windows! __ ___ _____ / / __ \/ | / ___/ ___/ / / _/ ___/ / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ / /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / \/_/ |_/_/ |_/// \/___/// Welcome to GRASS 6.4.0svn (2010) GRASS homepage: http://grass.osgeo.org/ This version running thru: GNU Bash (Cygwin) (/usr/bin/bash.exe) sounds like you are running through Cygwin (GNU Bash (Cygwin) (/usr/bin/bash.exe)) -- on my machine the MSys desktop link triggers a welcome screen that at the same line says Bourne Shell (/bin/sh) (and everything works as expected including the wxpython GUI): Cleaning up temporary files ... Starting GRASS ... ATTENZIONE: Attention! ATTENZIONE: Locking is not supported on Windows! __ ___ _____ / / __ \/ | / ___/ ___/ / / _/ ___/ / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ / /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / \/_/ |_/_/ |_/// \/___/// Welcome to GRASS 6.4.0svn (2010) GRASS homepage: http://grass.osgeo.org/ This version running thru: Bourne Shell (/bin/sh) Help is available with the command: g.manual -i See the licence terms with: g.version -c If required, restart the GUI with: g.gui wxpython When ready to quit enter:exit GRASS 6.4 Do you by any chance have Cygwin bash.exe on your %PATH% environmental variable? As for the Python errors you mention, I am not sure but it may again be a problem related to %PATH% settings. It is indeed possible to have heritage Cygwin/GRASS and the new native Wingrass running on the same machine, but care must be taken to avoid messing with the global %PATH%. As for running R from GRASS, an approach I have found useful is to follow the advice by Glynn Clements, i.e. not running GRASS from MSys but instead use a simple DOS box started via a batch file that sets required environmental variables to run GRASS, and then call the shell executable sh.exe (shell scripts designed for Cygwin/GRASS run with minimal adjustments -- mostly to cope with MSys path conventions issues). Glynn has taken on this topic in a growing (thanks for your patience, Glynn!) number of posts -- see for example: http://osgeo-org.1803224.n2.nabble.com/grass-start-bat-in-windows-tp4492202p4492202.html Finally, when I have my GRASS-enabled DOS box, I just type R (of course R needs to be in the %PATH%) and I am pretty much done. I hope this helps and sorry if I misunderstood your questions, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] No wxGUI for r.colors.stddev in winGRASS
Hello,
Just would like to mention that trying to run (windows 7)
r.colors.stddev from wxpython GUI either by typing the command name with
no args or using the raster menu, fails to start the module's GUI. The
problem seems that the OS thinks .stddev is a file extension -- a
message pops up saying windows is unable to find a suitable program to
open r.colors.stddev. On the other hand, trying to associate .stddev
with msys sh.exe fails anyway, with the following error:
Traceback (most recent call last):
File C:/Program
Files/GRASS-64-SVN/etc/wxpython/wxgui.py, line 473, in
OnRunCmd
self.goutput.RunCmd(cmd, switchPage=False)
File C:\Program
Files\GRASS-64-SVN\etc\wxpython\gui_modules\goutput.py,
line 354, in RunCmd
menuform.GUI().ParseCommand(cmdlist, parentframe=self)
File C:\Program
Files\GRASS-64-SVN\etc\wxpython\gui_modules\menuform.py,
line 1852, in ParseCommand
xml.sax.parseString(getInterfaceDescription(cmd[0]).decode(e
nc).split('\n',1)[1].replace('', '?xml version=1.0
encoding=utf-8?\n', 1).encode(utf-8),
File C:\Program
Files\GRASS-64-SVN\etc\wxpython\gui_modules\menuform.py,
line 1791, in getInterfaceDescription
raise IOError, _(Unable to fetch interface description for
command '%s'.) % cmd
IOError
:
Unable to fetch interface description for command
'r.colors.stddev'.
(Then the process of un-associate file extensions is at best tedious.)
The r.colors.stddev.bat file seems OK. Using the TclTk GUI, the GUI
interface for r.colors.stddev works fine.
Has anybody experienced this already?
Kind regards,
Luigi
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Previewing column names in input ASCII file without messing g.parser up
Hi there, Working on windows 7, I was trying to run a GRASS bash shell script (written for the Cygwin version of GRASS) using the WinGRASS-6.4.SVN-r42329-1 installed from http://josef.fsv.cvut.cz/wingrass/. After some tuning to adopt the direct rendering approach and to adjust to msys pathname conventions, all runs fine (winGRASS is in Program Files and no problems occur using a variety of grass and shell commands) except for one feature of the script that I am not able to reproduce in the native winGRASS version. The shell script basically imports (v.in.ascii) an ASCII text file with columns including latitude, longitude, and some variables, and then maps a variable of choice. It calls a little Perl script that prints column order and names before g.parser is called. In the Cygwin version, this results in (1) the output of the Perl script to be printed to the GRASS/bash terminal, and (2) the script GUI to be launched as well. This way, the user can look at names/numbers of columns in the ASCII file, and input column numbers of choice in the GUI for v.in.ascii. In winGRASS, the execution of the Perl script that prints column names/numbers prevents the GUI of the main shell script from starting up when called in the Cmd text box of the Python wxgui (started using the shortcut created by the installer), with the following error message in the command output tab: self.goutput.RunCmd(cmd, switchPage=False) File C:\Program Files\GRASS-64-SVN\etc\wxpython\gui_modules\goutput.py, line 354, in RunCmd menuform.GUI().ParseCommand(cmdlist, parentframe=self) File C:\Program Files\GRASS-64-SVN\etc\wxpython\gui_modules\menuform.py, line 1853, in ParseCommand handler) File C:\OSGeo4W\apps\Python25\lib\xml\sax\__init__.py, line 49, in parseString parser.parse(inpsrc) File C:\OSGeo4W\apps\Python25\lib\xml\sax\expatreader.py, line 107, in parse xmlreader.IncrementalParser.parse(self, source) File C:\OSGeo4W\apps\Python25\lib\xml\sax\xmlreader.py, line 123, in parse self.feed(buffer) File C:\OSGeo4W\apps\Python25\lib\xml\sax\expatreader.py, line 211, in feed self._err_handler.fatalError(exc) File C:\OSGeo4W\apps\Python25\lib\xml\sax\handler.py, line 38, in fatalError raise exception xml.sax._exceptions . SAXParseException : unknown:2:0: syntax error However, when calling the shell script in winGRASS text mode (started using the shortcut created by the installer) the Cygwin behavior is reproduced, i.e. column numbers and names are printed to the DOS terminal by the Perl script, and the GUI of the main shell script is launched as well. Apparently, this is due to the wxpython not having a DOS prompt where to print. Also, it seems to be calling code from OSGeo4W although I have checked my %PATH% environment variable, and there does not seem to be any reference to the C:\OSGeo4W installation: typing path | FINDSTR OSGeo4W at the DOS prompt returns nothing. Does anybody see a way around the wxpython problem that would allow column number/names in the input ASCII file to be previewed without preventing the g.parser GUI to start up? A side note: it seems like the /scripts/ folder is not accessible inside custom shell scripts so that I had to add @set PATH=%GISBASE%\scripts\;%PATH% in the corresponding .bat file that lives inside GISBASE/bin/ and is used to call the custom script itself from wxpython gui. Not sure why this happens. Finally, I wanted to thank authors of posts from which I have collected info that enabled me to port shell scripts to native winGRASS (e.g. Glynn Clements and Elena Mitasova). Kind regards and sorry for a long post of somewhat mixed content, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Language of installed manual
Hi Markus, On 31/05/2010 20:57, Markus Neteler wrote: Hi Luigi, On Mon, May 31, 2010 at 4:49 PM, Luigi Ponti lpo...@inbox.com wrote: Hello, I could not find any further reply to this, and I just would like to mention that the problem (mixed languages in manual pages when installing wingrass from http://josef.fsv.cvut.cz/wingrass/grass64/) is gone as of WinGRASS-6.4.SVN-r42329-1-Setup.exe. Yes, a known problem and Martin didn't manage to convince Windows to speak English when running the virtual session during compilation for the creation of the manual pages... Well, what I meant was that Martin apparently did find a way to fix it -- that is what my post was about: the manual seems OK now -- no more Czech language in the manual pages. I haven't actually checked all the man pages, but the test pages I had reported as having mixed language (e.g. r.colors) now show 100% in English. Thanks and regards, Luigi Luigi wrote: On 19/02/2010 16:33, Martin Landa wrote: ... The default locale is C, which behaves the same as if no locale is set (i.e. no call to setlocale()). LC_ALL takes precedence over the individual LC_* variables and LANG, so you may need to use: export LC_ALL=C I have already tried to put `LC_ALL=C` to package.sh and recompile GRASS, but it didn't seem to help (module --interface-description still returns localized text). Martin Thanks Martin. Just to detail further my report, in case it is useful (sorry if redundant): ... You can see there is English description plus some Italian text depending on how far the translator got. It is the same text I get in the g.parser GUI when invoking r.colors without arguments. I think this is fine since I have an Italian locale. However, the HTML manual page of r.colors is a partial Czech translation. ... which is fine in the same way since Martin has a CZ Windows box. @devs,Martin: I wonder if LC_ALL=C could be enforced in include/Make/Html.make ? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Language of installed manual
Hello, I could not find any further reply to this, and I just would like to mention that the problem (mixed languages in manual pages when installing wingrass from http://josef.fsv.cvut.cz/wingrass/grass64/) is gone as of WinGRASS-6.4.SVN-r42329-1-Setup.exe. Thanks and regards, Luigi On 19/02/2010 16:33, Martin Landa wrote: Hi, 2010/2/18 Glynn Clements [hidden email] http://osgeo-org.1803224.n2.nabble.com/user/SendEmail.jtp?type=nodenode=4599112i=0: [...] The default locale is C, which behaves the same as if no locale is set (i.e. no call to setlocale()). LC_ALL takes precedence over the individual LC_* variables and LANG, so you may need to use: export LC_ALL=C I have already tried to put `LC_ALL=C` to package.sh and recompile *GRASS*, but it didn't seem to help (module --interface-description still returns localized text). Martin Thanks Martin. Just to detail further my report, in case it is useful (sorry if redundant): Installed last available WinGRASS-6.4.SVN-r41105-1-Setup.exe of 19 February. If I do for example: r.colors --interface-description what is get is: ?xml version=1.0 encoding=CP1252? !DOCTYPE task SYSTEM *grass*-interface.dtd task name=r.colors description Creates/modifies the color table associated with a raster map layer. /description keywords raster, color table /keywords parameter name=map type=string required=no multiple=no description Nome della mappa raster in input /description keydesc item order=1name/item /keydesc gisprompt age=old element=cell prompt=raster / guisection Required /guisection /parameter [...] /task You can see there is English description plus some Italian text depending on how far the translator got. It is the same text I get in the g.parser GUI when invoking r.colors without arguments. I think this is fine since I have an Italian locale. However, the HTML manual page of r.colors is a partial *Czech* translation. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] US states and county layers?
On Tue, May 18, 2010 at 12:17 AM, Matthew Mulbrandon mulb...@hotmail.com wrote: Hello, I was looking for grass layer with US states and US counties. Can't find using google but it must be around somewhere. Does anyone know where I can download this info or is it back to converting shp files. I guess that you can get them here: http://www.nationalatlas.gov/atlasftp.html as SHAPE files and then import with v.in.ogr into a location in Lambert Azimuthal Equal-Area projection as I understand from here: http://www.nationalatlas.gov/articles/mapping/a_projections.html Alternative sources of administrative data: GADM database http://www.gadm.org/ Natural Earth http://www.naturalearthdata.com/downloads/ Regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with running Python script in GRASS
Dear Glynn, I am always interested in GRASS scripting-related questions. Thanks for your support on Python/Windows issues. From: Glynn Clements gl...@gclements.plus.com Subject: Re: [GRASS-user] Problem with running Python script in GRASS To: LeeDaniel lee.daniel.1...@gmail.com Cc: grass-user@lists.osgeo.org Message-ID: 19426.59411.559013.36...@cerise.gclements.plus.com Content-Type: text/plain; charset=us-ascii LeeDaniel wrote: I've written a Python script, doing my best to use the Python I know and reverse engineer the python scripts I found in the Internet. As far as I can tell, the script should be fine, although I naturally can't execute it independently. [...] Windows, Python and 6.4 isn't the most reliable combination. At a minimum, you need a fairly recent version of 6.5 to be able to use Python scripts on Windows (the hacks required to get shell scripts to work on Windows get in the way of running other scripts). 6.4.0-RC6 won't work (g.parser was updated, but lib/python wasn't). Is this true also for the daily WinGRASS-6.4.SVN at http://josef.fsv.cvut.cz/wingrass/ and will this hold true for 6.4 in general? You also need a clean Python install with the correct registry entries, From what you say, one needs two Python installations: the one that comes with GRASS and an additional fresh one -- is it ok to install the current Python 2.6.5 version or 2.5 is better (2.6 seems to be ok from http://grass.osgeo.org/wiki/GRASS_and_Python)? From the GRASS/Python wiki one also infers that on Windows the Python binaries that come with the GRASS installation are no longer used (?). (Currently I am using WinGRASS-6.4.SVN-r42046-1 from the installer downloaded at the link above; OS is windows 7.) and you may need to hack the GRASS startup scripts (the WinGRASS installer fails quite badly with regard to Python, and the OSGeo4W installer fails even harder). But my question is actually: if a user wants to take a (Windows) Python scripting approach to GRASS, what version should she/he target? My impression is that trying to build functionality using GRASS 7 may have the best returns, although I am not sure how feasible is that right now, i.e. what GRASS 6 functionality can currently be ported to GRASS 6 (I am thinking for example to a way around the display issue that in 6.4 is solved using appropriate settings for e.g. GRASS_RENDER_IMMEDIATE). Given that WinGRASS users have the extreme luxury of 7.0.svn snapshot installers being built almost daily thanks to Martin Landa: http://josef.fsv.cvut.cz/wingrass/grass70/ it would be very interesting to know your opinion. Kind regards and thank you in advance, Luigi -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map legend with rgbcolumn colors
Dear Hamish, It definitely helped! On 04/03/2010 03:21, Hamish wrote: Luigi Ponti wrote: I haven't been able to find this in previous discussions but it seems like a trivial yet impossible (for me) to solve thing. (Running grass6.4-svn windows standalone installer win7.) (it needs to be explained better in the docs.) I am trying to get a ps.map using an input file like the following: [...] I would like to print a categorical legend with the same colors as the rgbcolumn, but I only get one gray color that is different from the RGB_COLOR definitions: https://docs.google.com/fileview?id=0B0EpsfMZ-IZYNzI2ZjRjMTQtNTNiNi00NTJkLWJlZjAtNzAyN2E0MTM3OWUwhl=it nice! It is global ecological zones from FAO http://www.fao.org/geonetwork/ with color scheme from http://colorbrewer2.org/ and underlying shaded relief from globe relief http://www.ngdc.noaa.gov/mgg/topo/globe.html (there is also 10m scale shoreline from http://www.naturalearthdata.com/). I am impressed with ps.map results (never used before): it does look a lot more like a printed map. Any pointer? the vector legend is by map, not by category. Because you only used the vareas instruction once, you only get one entry in the vector legend. two alternatives: 1) add one vareas instruction for every vector zone, and add a where column_name = 'zonename' On my system it needs to be unquoted (at least in my case, where values were integers) -- I mean, no quotes at all. to each one. You might have to explicitly give the fill color, I don't think it is smart enough to know that the SQL query only results in 1. Yes, it is not smart enough; I had to use fcolor option with R:G:B triplet in vareas in place of rgbcolumn. Set the label to be each zonename. (easiest way for a few values) Thanks: I have gone this way, for now. See link below: https://docs.google.com/fileview?id=0B0EpsfMZ-IZYYmYwYmRlMWItY2Y4NS00MTNhLWEzZWUtZjQ2Y2U0OTU2YzRihl=it One thing I am not able to do yet, is to use system fonts (e.g. Arial). I have tried by setting absolute path but it doesn't seem to work. I am afraid this is more of a postscript question... Is ps.map able to access and embed GRASS fonts? (ok, tried to get GRASS in.) 2) take the 'v.colors -s' approach, and create a dummy raster map containing a category file and color table matching what's in the vector's DB. Then use the colortable command to display it. example: This is a great example that I need to study a bit more. Thanks for your help, Luigi (this exposes a bug in the ps.map categorical legend though! the fill colors get rearranged!) # North Carolina sample dataset g.copy v=soils_wake,soils_wakeL # assign soil type ID number to each soil of the 77 soil types v.db.addcol soils_wakeL col='DSL_NUM integer' SOIL_TYPES=`v.db.select soils_wake col=DSL_NAME | sort | uniq` i=0 ( for TYPE in $SOIL_TYPES ; do i=`expr $i + 1` echo UPDATE soils_wakeL SET DSL_NUM=$i WHERE DSL_NAME='$TYPE'; done ) | db.execute v.extract in=soils_wakeL out=soils_wakeLc type=area where=DSL_NUM 70 d.vect soils_wakeLc type=area -c where=DSL_NUM 70 v.colors -s map=soils_wakeLc column=DSL_NUM color=random d.erase d.vect soils_wakeLc type=area -a g.rename vcolors_23877,soils_wakeLc.legend #create cats file: v.db.select -c soils_wakeLc columns=DSL_NUM,DSL_NAME fs=: | \ sort | uniq | r.category soils_wakeLc.legend rules=- d.legend soils_wakeLc.legend ps.map in=test.psm out=test.ps gv test.ps #test.psm # ps.map input file border y color black width 1 end raster elevation_shade vareas soils_wakeLc rgbcolumn GRASSRGB label SOIL_CODE lpos 1 end #vlegend # where 5.5 8 # border black # font arial # fontsize 12 # cols 1 # end colortable where 1 8 raster soils_wakeLc.legend font arial fontsize 12 cols 1 nodata Yes end end # hope it helps, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] ps.map legend with rgbcolumn colors
Hi there, I haven't been able to find this in previous discussions but it seems like a trivial yet impossible (for me) to solve thing. (Running grass6.4-svn windows standalone installer win7.) I am trying to get a ps.map using an input file like the following: # ps.map input file border y color black width 1 end raster shadedRelief vareas ecologicalZones layer 1 rgbcolumn RGB_COLOR label GEZ_CODE lpos 1 end vlegend where 0.5 6 border black font arial fontsize 12 cols 1 end end I would like to print a categorical legend with the same colors as the rgbcolumn, but I only get one gray color that is different from the RGB_COLOR definitions: https://docs.google.com/fileview?id=0B0EpsfMZ-IZYNzI2ZjRjMTQtNTNiNi00NTJkLWJlZjAtNzAyN2E0MTM3OWUwhl=it Any pointer? Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Raster surface from regularly spaced points
Hello, I have a grid of (almost) regularly spaced vector points from which I would like to get a continuous raster surface. I say almost regularly spaced, because the grid is almost square in that the position of points derives from a netCDF grid with a different projection than the current GRASS location. One cell of this non-aligned grid covers several raster cells at the current region resolution. So far I have been using a v.surf.idw approach but I am not sure whether that is appropriate. An exact interpolator would be best, but at least I want conserve the range of the original data. According the the GRASS book (p. 228), my options would be v.surf.idw and v.surf.rst but the latter does not conserve data range, I think. Another idea would be to use bilinear interpolation. Any hints very welcome and thanks for your attention if you got so far, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Raster surface from regularly spaced points
Thanks Markus! On 19/02/2010 11:52, Markus Metz wrote: You can try the overhauled v.surf.bspline module. You would need to svn up to get the new version, available in grass64 and higher. I was browsing the source code but did not see it http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/vector http://trac.osgeo.org/grass/browser/grass/trunk/vector Am I looking at the wrong spot? I will probably get it in the next grasswin standalone installer, but I also need source code to update an heritage cygwin/grass version. run v.surf.bspline with the -e flag first to get estimated mean distance between points. If your points are not completely but almost regularly spaced, multiply the estimated distance by 1.5 and use that value for sin and sie. This is great fine-tuning get me up and running -- thanks. BTW, method=bicubic gives much nicer results than method=bilinear. I think it is slower, isn't it? Not sure how much slower, though. To conserve the range of the original data, use a low lambda_i value somewhere between 0.01 and 0.1. I would be really interested if it works for you! I will let you know. Thanks again, Luigi Markus M Luigi Ponti wrote: Hello, I have a grid of (almost) regularly spaced vector points from which I would like to get a continuous raster surface. I say almost regularly spaced, because the grid is almost square in that the position of points derives from a netCDF grid with a different projection than the current GRASS location. One cell of this non-aligned grid covers several raster cells at the current region resolution. So far I have been using a v.surf.idw approach but I am not sure whether that is appropriate. An exact interpolator would be best, but at least I want conserve the range of the original data. According the the GRASS book (p. 228), my options would be v.surf.idw and v.surf.rst but the latter does not conserve data range, I think. Another idea would be to use bilinear interpolation. Any hints very welcome and thanks for your attention if you got so far, Luigi ___ 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] Language of installed manual
On 28/01/2010 15:51, Markus Neteler wrote: Martin: please read on: On Thu, Jan 28, 2010 at 3:27 PM, Luigi Ponti lpo...@infinito.it wrote: Hi all, Not sure why this happens, but some of the manual pages of my WinGRASS-6.4.SVN-r40650-1 installation are in English e.g. v.build.all - Rebuilds topology on all vector maps in the current mapset. while other are in another (not sure which) language e.g. v.buffer - Vytvoĝí buffer okolo prvkù zadaného typu (plochy musí obsahovat centroid) Is this a known issue? It is a bugfeature: some want it some not. Ideally both English and the current locale would be used for creating the manual, see enhancement request: https://trac.osgeo.org/grass/ticket/846 Apparently winGRASS-daily was/is build in CZ locale and NLS active. Before compilation, the locale settings should be set to English by defining LANG and LC_MESSAGES variables. IMHO easy to fix on Martin's server. Hello, Just wanted to mention the partly-Czech manual is still there on the daily standalone installer (WinGRASS-6.4.SVN-r40876): many (not all) of the man pages have the first part (Flags, Parameters) in Czech, while starting from the Description section the rest of the page is in English. Kind regards, Luigi P.S. It was really a major improvement to have daily builds packaged for windows -- THANKS! Markus ___ grass-windows mailing list grass-wind...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-windows ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Max length of sql_query in v.extract
On 28/01/2010 00:45, Markus Neteler wrote: On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti lpo...@infinito.it wrote: Hello, Is there a length limit to a where sql statement fed to v.extract? I am getting an ... Error in db_open_select_cursor() ... in the middle of a very long query. Could you please try to analyse with g.gisenv set=DEBUG=3 to identify when it gets lost? And perhaps provide an example based on the Spearfish or North Carolina data sets? Version: WinGRASS-6.4.SVN-r40650-1 (installed in C:\GRASS-64-SVN i.e. no spaces in path; OS Windows 7) Dataset: North Caroline dataset Mapset: user1 vector: census_wake2000 (this actually resides in PERMANENT) Working on the Cmd input box of the wxGUI. I have chosen a case analogous to that where I encountered the error, i.e. a DBF Character field containing 105 different numeric codes (e.g. 050100) one per record: (note that you can find full debug output in a text file available at the following link: https://docs.google.com/leaf?id=0B0EpsfMZ-IZYOTJiYWVmNjUtNGYzMC00NDM5LWI1NDYtZTMyNzg3M2NjOThksort=namelayout=listnum=50 I thought 20,000+ lines was too much for the mailing list but please advice if had better taken a different course of action.) ### START GRASS CMD HISTORY ### g.gisenv set=DEBUG=3 (Thu Jan 28 12:12:34 2010) Command finished (0 sec) (Thu Jan 28 12:12:43 2010) v.extract input=census_wake2000 output=census_extract_all_trt2000 where=(TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402') D3/3: Mapset = PERMANENT D1/3: Vect_open_old(): name = census_wake2000 mapset= PERMANENT update = 0 D1/3: Vect_set_thresh(): thresh = 0.00 [...] D3/3: db_select_int() D3/3: SQL: SELECT cat FROM census_wake2000 WHERE (TRT2000= '050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000= '050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000= '050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000= '051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000= '051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000= '051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000= '052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000= '052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000= '052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000= '052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000= '052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000= '052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000= '052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000= '052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000= '052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000= '052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000= '053101')or(TRT DBMI-DBF driver error: SQL parser error: syntax error, unexpected $end processing
Re: [GRASS-user] Max length of sql_query in v.extract
Thanks for your answer, Markus. On 28/01/2010 14:57, Markus Neteler wrote: On Thu, Jan 28, 2010 at 1:34 PM, Luigi Ponti lpo...@infinito.it wrote: On 28/01/2010 00:45, Markus Neteler wrote: On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti lpo...@infinito.it wrote: Hello, Is there a length limit to a where sql statement fed to v.extract? I am getting an ... Error in db_open_select_cursor() ... in the middle of a very long query. [...] v.extract input=census_wake2000 output=census_extract_all_trt2000 where= [... very long WHERE suppressed...] (TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402') Yes, that's very long. Would there be a better way of achieving this in GRASS e.g. via *.db.* commands or is v.extract a wrapper for them, and hence they would fail anyway? Kind regards, Luigi [...] I guess that we need to change to dynamic string length allocation here? The cut string is pretty close to the 1023 chars length. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Max length of sql_query in v.extract
Hello, Is there a length limit to a where sql statement fed to v.extract? I am getting an ... Error in db_open_select_cursor() ... in the middle of a very long query. Thanks for any hints, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Natural Earth: public domain GIS datasets
From: John A Stevenson john.steven...@manchester.ac.uk Subject: Re: [GRASS-user] Natural Earth: public domain GIS datasets To: Luigi Ponti lpo...@infinito.it Cc: grass-user@lists.osgeo.org Message-ID: 4b5336fa.1070...@manchester.ac.uk Content-Type: text/plain; charset=ISO-8859-1; format=flowed Luigi Ponti wrote: Dear users, I did not see this cited in the mailing list archive so I thought others may find it useful as a source of basic GIS layers. Natural Earth http://www.naturalearthdata.com/ They seem to import fine into GRASS, and vectors have clean and informative attribute tables. Hi Luigi, There is a lot of nice data on there. I've had some trouble trying to import the vector data, however. I keep getting a buffer-overflow with v.in.ogr (see below). It happens with 6.4.0RC5, and with 6.5.svn. How did you import them? Dear John, I have done a test import of country administrative boundaries at 110m:1 scale via v.in.ogr (GUI wxPython version) using GRASS 6.4.0svn r36506 from OSGeo4W installer. Received no complaints. Regards, Luigi Cheers John GRASS 6.4.0RC5 (global):~/laptop/GIS_datasets/Natural_Earth_GIS_data_10m/physical v.in.ogr ../cultural/10m-populated-places.shp out=cities Projection of input dataset and current location appear to match Layer: 10m-populated-places Importing map 6599 features... *** buffer overflow detected ***: v.in.ogr terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7057ed8] /lib/tls/i686/cmov/libc.so.6[0xb7056f10] /lib/tls/i686/cmov/libc.so.6[0xb7056869] /lib/tls/i686/cmov/libc.so.6(__snprintf_chk+0x34)[0xb7056754] /usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature16GetFieldAsStringEi+0x34e)[0xb74eb3be] /usr/lib/libgdal1.5.0.so.1(OGR_F_GetFieldAsString+0x28)[0xb74ec1c8] v.in.ogr(main+0x21e8)[0x804d9d8] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb6f8db56] v.in.ogr[0x804aab1] === Memory map: 08048000-0805 r-xp 08:06 24396 /usr/lib/grass64/bin/v.in.ogr 0805-08051000 r--p 7000 08:06 24396 /usr/lib/grass64/bin/v.in.ogr 08051000-08052000 rw-p 8000 08:06 24396 /usr/lib/grass64/bin/v.in.ogr 086e6000-08728000 rw-p 00:00 0 [heap] b4eb-b4eba000 r-xp 08:06 968 /lib/tls/i686/cmov/libnss_files-2.10.1.so b4eba000-b4ebb000 r--p 9000 08:06 968 /lib/tls/i686/cmov/libnss_files-2.10.1.so b4ebb000-b4ebc000 rw-p a000 08:06 968 /lib/tls/i686/cmov/libnss_files-2.10.1.so b4ebc000-b4ec2000 r-xp 08:06 964 /lib/tls/i686/cmov/libnss_compat-2.10.1.so b4ec2000-b4ec3000 r--p 5000 08:06 964 /lib/tls/i686/cmov/libnss_compat-2.10.1.so b4ec3000-b4ec4000 rw-p 6000 08:06 964 /lib/tls/i686/cmov/libnss_compat-2.10.1.so b4edc000-b4f1b000 r--p 08:06 134849 /usr/lib/locale/en_GB.utf8/LC_CTYPE b4f1b000-b4f1f000 rw-p 00:00 0 b4f1f000-b4f22000 r-xp 08:06 942/lib/libgpg-error.so.0.4.0 b4f22000-b4f23000 r--p 2000 08:06 942/lib/libgpg-error.so.0.4.0 b4f23000-b4f24000 rw-p 3000 08:06 942/lib/libgpg-error.so.0.4.0 b4f24000-b4f34000 r-xp 08:06 6439 /usr/lib/libtasn1.so.3.1.5 b4f34000-b4f35000 r--p f000 08:06 6439 /usr/lib/libtasn1.so.3.1.5 b4f35000-b4f36000 rw-p 0001 08:06 6439 /usr/lib/libtasn1.so.3.1.5 b4f36000-b4f4e000 r-xp 08:06 6375 /usr/lib/libsasl2.so.2.0.23 b4f4e000-b4f4f000 r--p 00017000 08:06 6375 /usr/lib/libsasl2.so.2.0.23 b4f4f000-b4f5 rw-p 00018000 08:06 6375 /usr/lib/libsasl2.so.2.0.23 b4f5-b4f51000 rw-p 00:00 0 b4f51000-b4f61000 r-xp 08:06 1006 /lib/tls/i686/cmov/libresolv-2.10.1.so b4f61000-b4f62000 r--p 0001 08:06 1006 /lib/tls/i686/cmov/libresolv-2.10.1.so b4f62000-b4f63000 rw-p 00011000 08:06 1006 /lib/tls/i686/cmov/libresolv-2.10.1.so b4f63000-b4f65000 rw-p 00:00 0 b4f65000-b4f67000 r-xp 08:06 951/lib/libkeyutils-1.2.so b4f67000-b4f68000 r--p 1000 08:06 951/lib/libkeyutils-1.2.so b4f68000-b4f69000 rw-p 2000 08:06 951/lib/libkeyutils-1.2.so b4f69000-b4f6f000 r-xp 08:06 2750 /usr/lib/libkrb5support.so.0.1 b4f6f000-b4f7 r--p 5000 08:06 2750 /usr/lib/libkrb5support.so.0.1 b4f7-b4f71000 rw-p 6000 08:06 2750 /usr/lib/libkrb5support.so.0.1 b4f71000-b4f97000 r-xp 08:06 2756 /usr/lib/libk5crypto.so.3.1 b4f97000-b4f98000 ---p 00026000 08:06 2756 /usr/lib/libk5crypto.so.3.1 b4f98000-b4f99000 r--p 00026000 08:06 2756 /usr/lib/libk5crypto.so.3.1 b4f99000-b4f9a000 rw-p 00027000 08:06 2756 /usr/lib/libk5crypto.so.3.1 b4f9a000-b4fad000 r-xp 08:06 962 /lib/tls/i686/cmov/libnsl-2.10.1.so b4fad000-b4fae000 r--p 00012000 08:06 962 /lib/tls/i686/cmov/libnsl-2.10.1.so b4fae000-b4faf000 rw-p 00013000 08:06 962 /lib/tls/i686/cmov/libnsl-2.10.1
[GRASS-user] Natural Earth: public domain GIS datasets
Dear users, I did not see this cited in the mailing list archive so I thought others may find it useful as a source of basic GIS layers. Natural Earth http://www.naturalearthdata.com/ They seem to import fine into GRASS, and vectors have clean and informative attribute tables. Apologies if this info in redundant and/or misplaced. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
On 10/12/2009 23:29, Glynn Clements wrote: Luigi Ponti wrote: This is likely naive and/or just out of ignorance, but I am not sure whether there is a chance to get GRASS 6.4 running on Cygwin should I be able to compile it from source on my Cygwin installation. Sorry in advance if this is nonsense. All I know is that the binaries which I compiled work fine on my Windows XP system. Update: you are right -- it works on XP, but I am on Windows 7. While installing on Cygwin the packages required to compile GRASS, it occurred to me I had read on Cygwin website that Windows 7 would have been supported starting next major version 1.7 (see http://cygwin.com/). However, 1.7 is in beta testing and available to install, which I did. Things work much better, and now GRASS 6.4.0RC5 starts up fine with tcltk gui. First problem I encountered next is with the dbf driver. The output of /db.connect -p/ seems ok: But when I do /db.test test1/ errors arise: [...] My guess is that this is a problem with Cygwin and Windows 7. I have eventually reverted back to GRASS 6.3.0 for now, after fixing some missing dll's. I am not sure what is wrong with 6.4 vs 6.3 but I need a functional GRASS/Cygwin version to run some bash scripts while I port them to Phython. Actually, my bash GRASS scripts call a number of Perl scripts for text processing purposes (tweaking ascii georeferenced files to be fed to v.in.ascii, creating color rules on the fly, writing HTML files to summarize output, and other little tasks that I found convenient to code in Perl given my limited programming experience and the huge amount of Perl info and examples available on the web). Therefore, I was thinking to do text processing and other stuff using Python but this will require a bit more than simply implementing a series of grass commands (i.e. learning some Python), that is why I need the Cygwin version meanwhile. Also, is it even possible to do Python scripting in the native Windows GRASS 6.4.x? For example, I noticed that some of the GRASS scripts that have been translated to Python require a grass.py package, which I don't see in my osgeo4w installation. Kind regards, Luigi Any idea what happens and/or testing hints for better diagnosis? Not really. This may just be a case of Cygwin not fully supporting Windows 7 yet. In case I want to keep trying compiling on Cygwin, should I do that in a parallel Cygwin installation on, say, a different HD partition (to preserve at least one functional Cygwin version)? Kind regards and thanks again for your help, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
On 07/12/2009 19:42, Glynn Clements wrote:
Luigi Ponti wrote:
This is likely naive and/or just out of ignorance, but I am not sure
whether there is a chance to get GRASS 6.4 running on Cygwin should I be
able to compile it from source on my Cygwin installation. Sorry in
advance if this is nonsense.
All I know is that the binaries which I compiled work fine on my
Windows XP system.
Update: you are right -- it works on XP, but I am on Windows 7.
While installing on Cygwin the packages required to compile GRASS, it
occurred to me I had read on Cygwin website that Windows 7 would have
been supported starting next major version 1.7 (see http://cygwin.com/).
However, 1.7 is in beta testing and available to install, which I did.
Things work much better, and now GRASS 6.4.0RC5 starts up fine with
tcltk gui.
First problem I encountered next is with the dbf driver. The output of
/db.connect -p/ seems ok:
driver:dbf
database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
schema:
group:
But when I do /db.test test1/ errors arise:
create table grass_test1 (i1 integer, d1 double precision, c1 varchar(20))
EXECUTE: OK
insert into grass_test1 values ( 1, 123.456, 'abcd' )
EXECUTE: OK
insert into grass_test1 values ( 2, null, 'xxx' )
EXECUTE: OK
select * from grass_test1
EXECUTE: OK
1c1
1|123.456|abcd
---
1|123.456000|abcd
ERROR: RESULT: ERROR
select c1 from grass_test1 where d1 500 / 2 and i1 2 and c1 ~ 'bc'
EXECUTE: OK
RESULT: OK
insert into grass_test1 values ( 3, 0.0, '_''_' )
3 [main] db.execute 2616 fork: child -1 - died waiting for longjmp
before initialization, retry 0, exit code 0xC005, errno 11
Resource temporarily unavailable: can't create fork
ERROR: Unable to start driver dbf
ERROR: EXECUTE: ERROR
alter table grass_test1 add column i2 integer
dbmi: Protocol error
ERROR: Unable to start driver dbf
ERROR: EXECUTE: ERROR
update grass_test1 set d1 = 18.6, i2 = 987 where i1 = 2
DBMI-DBF driver error:
Column 'i2' not found
Error in db_execute_immediate()
ERROR: Error while executing: 'update grass_test1 set d1 = 18.6, i2 = 987
where i1 = 2
'
ERROR: EXECUTE: ERROR
select * from grass_test1
3 [main] db.select 4772 fork: child -1 - died waiting for longjmp
before initialization, retry 0, exit code 0xC005, errno 11
Resource temporarily unavailable: can't create fork
ERROR: Unable to start driver dbf
ERROR: EXECUTE: ERROR
0a1,3
1|123.456000|abcd|
2|18.60|xxx|987
3|0.00|_'_|
ERROR: RESULT: ERROR
drop table grass_test1
EXECUTE: OK
Any idea what happens and/or testing hints for better diagnosis?
Kind regards,
Luigi
If you compile from source, even if you have problems with the
resulting binaries, it will be easier to debug such problems with
debug info.
The Cygwin binaries on the GRASS website have been stripped, as
unstripped binaries are over twice as large, which is inconvenient
both for me and for anyone downloading them.
FWIW, I configured with:
./configure
--with-includes=/usr/local/include
--with-libs=/usr/local/lib
--with-proj-share=/usr/share/proj
--with-cxx
--with-freetype
--with-opengl
--with-readline
--with-nls
--without-odbc
--with-cairo
--with-sqlite
--with-blas
--with-lapack
--with-postgres
--with-cairo-includes=/usr/include/cairo
'--with-cairo-ldflags=-lcairo -lX11'
--with-freetype-includes=/usr/include/freetype2
--with-python
--with-motif
--with-glw
[I need /usr/local/{include,lib} for GDAL and Tcl/Tk.]
For a basic GRASS installation, most of the above --with-* switches
aren't needed. As I was building a package for distribution, I
included every option which I could get to work.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
On 05/12/2009 11:05, Glynn Clements wrote: Hamish wrote: Is it a matter of trying compiling on Cygwin? I assume that gdb is the debugger of gcc. I'm not sure if a recompile in needed. Glynn, are those binaries compiled with -g and not stripped? The Cygwin binaries are stripped. Normally, I'd mention that you can still get a backtrace from stripped binaries. But in retrospect, the stackdump file says probably corrupted stack, so I don't think that you could get a backtrace even if the binaries weren't stripped. At this point, I'm out of ideas. Thanks for your feedback. This is likely naive and/or just out of ignorance, but I am not sure whether there is a chance to get GRASS 6.4 running on Cygwin should I be able to compile it from source on my Cygwin installation. Sorry in advance if this is nonsense. Any hints appreciated. Thanks again, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
On 04/12/2009 20:36, Markus Neteler wrote: On Fri, Dec 4, 2009 at 12:04 PM, Glynn Clements gl...@gclements.plus.com wrote: Luigi Ponti wrote: Can you post the contents of the g.gisenv.exe.stackdump file? Here it is: 9888 [main] g.gisenv 3672 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 11805 [main] g.gisenv 3672 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Unfortunately that doesn't help. I don't think that we will be able to make any progress on this until someone who can reproduce it can get a backtrace out of gdb. ... which isn't that hard. If you need help, Luigi, let me know. Is this the place to start from? http://grass.osgeo.org/wiki/Compile_and_Install Is it a matter of trying compiling on Cygwin? I assume that gdb is the debugger of gcc. I remember threads on Cygwin compilation but I was not able to find them on the mailing list archive. If somebody has a pointer to relevant threads/resources, that would be appreciated. Regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: CYGWIN
Dear Glynn and Markus, I found no follow-up to this message of last November 17 so I am replying to this one. On windows 7 and using a fresh Cygwin/GRASS install as per instructions at http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ I start Cygwin shell - startxwin.sh - grass64 -tcltk The startup GUI pops up, I select a mapset, and press enter GRASS as usual. I get a very similar error to that reported by Markus below, i.e.: 5 [main] g.gisenv 4772 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLOW 358850 [main] g.gisenv 4772 open_stackdumpfile: Dumping stack trace to g.gisenv.exe.stackdump (every time you get same message with different numbers) Also, by calling GRASS in the following way: grass64 -tcltk 2 logGRASS.txt The content of the log is /usr/local/grass-6.4.0RC5/etc/Init.sh: line 837: tput: command not found Hope this help better diagnosis. My apologies if I missed follow-up to this thread. Kind regards, Luigi Date: Tue, 17 Nov 2009 12:54:46 + From: Glynn Clements gl...@gclements.plus.com Subject: Re: [GRASS-user] CYGWIN To: Markus Neteler nete...@osgeo.org Cc: GRASS user list grass-user@lists.osgeo.org Message-ID: 19202.40214.211883.542...@cerise.gclements.plus.com Content-Type: text/plain; charset=us-ascii Markus Neteler wrote: Starting grass64/cygwin with -tcltk leads to 13 [main] g.gisenv 2100 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLOW 78803 [main] g.gisenv 2100 open_stackdumpfile: Dumping stack trace to g.gisenv.exe.stackdump Subsequently the GUI isn't started (the tcltk startup screen comes up well). Running on command line: g.gisenv returns the settings as it should. Running on command line: g.region -p returns to command line without printing anything. Perhaps there is a version conflict with the proj libraries? All of the above work for me. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
On 04/12/2009 07:58, Glynn Clements wrote: Luigi Ponti wrote: On windows 7 and using a fresh Cygwin/GRASS install as per instructions at http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ I start Cygwin shell - startxwin.sh - grass64 -tcltk The startup GUI pops up, I select a mapset, and press enter GRASS as usual. I get a very similar error to that reported by Markus below, i.e.: 5 [main] g.gisenv 4772 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLOW 358850 [main] g.gisenv 4772 open_stackdumpfile: Dumping stack trace to g.gisenv.exe.stackdump Can you post the contents of the g.gisenv.exe.stackdump file? Here it is: 9888 [main] g.gisenv 3672 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 11805 [main] g.gisenv 3672 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Thanks for your reply, Luigi Also, by calling GRASS in the following way: grass64 -tcltk 2 logGRASS.txt The content of the log is /usr/local/grass-6.4.0RC5/etc/Init.sh: line 837: tput: command not found This is harmless; the only consequence is that the terminal window won't be cleared. The tput program is in the ncurses package, which isn't otherwise required (the libraries required by curses-based programs are in a separate libncurses9 package). Hope this help better diagnosis. My apologies if I missed follow-up to this thread. I don't think that there has been any follow-up. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] netCDF import via r.in.gdal
On 15/04/2009 9.13, Markus Neteler wrote: On Wed, Apr 15, 2009 at 2:00 AM, Luigi Ponti lpo...@infinito.it wrote: ... When I try to import to a latlong location, I get G_set_window(): Illegal latitude for North and no raster is created. When I use a projected location, the file gets imported but then I have bounding coordinates in dd:mm:ss and r.region complains that those are invalid. r.region map=SRF_1958.AVG n=61.4488N s=21.29965N e=43.07446E w=12.74702W n=61.4488N ** illegal value ** Not sure what I am doing wrong now. you mix sexagesimal and decimal notation... try: r.region map=SRF_1958.AVG n=61.4488 s=21.29965 e=43.07446 w=-12.74702 Thanks -- my fault: now it works. But how do you tell r.region that you are using degrees and not meters? Regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] netCDF import via r.in.gdal
Dear Markus, On 10/04/2009 18.13, Markus Neteler wrote: Hi Luigi, On Fri, Apr 10, 2009 at 4:39 PM, Luigi Ponti lpo...@infinito.it wrote: Hi there, I don't seem to be able to import netCDF via r.in.gdal in grass-6.4.0RC3 osgeo4w version running on XP sp3. GRASS 6.4.0RC3 (UTM32):C:\ r.in.gdal input=SRF_1958.AVG.NC output=SRF_1958.AVG location=ERA40_SRF Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute Location ERA40_SRF created ERROR: Selected band (1) does not exist Is this something that I should be able to manage to do? GRASS complains about bands -- the file includes georeferenced daily climate variables. The file opens OK in viewers such as Panoply http://www.giss.nasa.gov/tools/panoply/. Is there anything I am missing? The netCDF support depends on GDAL (not on GRASS). I had limited success so far.. Is the map in question available? The map is 500+ MB and resides on the local server of a national lab in Italy, so it is not available to public. It is from a set of netCDFs including daily weather data for the Mediterranean Basin that I need to put in text files after having removed grid points in the sea -- that is why I needed GRASS: to find a way to mask the dataset for data on the water that are not of interest, so as to have only data referring to land. Each element of the netCDF array is already coded using rows and columns of the grid, so I wanted GRASS to tell me which elements (referring to sea) to remove from the dataset and which to retain (those referring to land). Here are a series of issues listed: http://trac.osgeo.org/gdal/wiki/NetCDF Thanks for this: I had seen some of the posts by googling around but didn't know about this page that collects all NetCDF-related gdal issues. Perhaps it is worthwhile to report the problem in the appropriate ticket if reproducible. I am not sure it can be easily reproduced, but please suggest a way if you see one. Ciao, Luigi Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Second try, run grass scripts as batch, process in Windows
Message: 8 Date: Thu, 25 Sep 2008 15:22:03 +0100 From: Glynn Clements [EMAIL PROTECTED] Subject: Re: [GRASS-user] Second try, run grass scripts as batch process in Windows To: Moritz Lennert [EMAIL PROTECTED] Cc: grass-user@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii [...] I've started re-writing the scripts in 7.0 in Python. For now, I've left the Bourne-shell versions in place so that people can compare the two versions for testing purposes. That's great! Is there already some Python version available? Regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Precipitation color table?
Hamish wrote: Luigi Ponti wrote: [...] However, when you have a continuously varying color bar in the map, you will have label numbers next to the bar and you will try to associate the bar color next to the label value with a color in the map. The argument Borland Taylor (2007) make is that if each label of the color bar is located between two constant color bands in the bar, you will have that value easily located in the map along the boundary between the two contiguous areas of constant color. What do you think about this? So they argue that (filled) contour lines are better than continuous rainbow legend. Well, why not draw contour lines over the top of a continuous rainbow then? It is a false dichotomy, as you can do both together. My feeling is that there is more room for danger with contour lines than with the reader squinting to see what orangish- yellow means. Contour lines are dangerous because they state loudly where a transition is, regardless of if the data has that confidence or not. It is like the difference between politicial speak and scientist speak in a way, one gives black and white options, the other gives some probability that a theory is correct. OK -- I got the point and that's good because I don't have to change the way I am doing things. Plus you provided good arguments to support it. I have no bias given my very limited experience on the matter -- just trying to make an informed decision. Thanks again for discussing this and sorry if this is way off topic for the list (please advice). I veer way offtopic as well, and again it reminds me about the next book I need to borrow from the library (www.edwardtufte.com). Yes: it's highly cited by both supporters and enemies of constant color bands. To claw back on topic I will mention that you can have a rainbow colorscale with crossing band lines in ps.map: give the tickbar instruction to the colortable command. (then create and overlay contours at those levels) That's something that can turn useful, thanks! [...] The statistical equivalent is to slowly vary the number bins in a histogram while the peaks seemingly double and halve. Yes, you lose information that way. And worse, it is very easy to do so without noticing that you've done it. Thank you for a very interesting thread -- it's nice to veer off-topic every now and then. Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Precipitation color table?
From: Hamish [EMAIL PROTECTED] Subject: Re: [GRASS-user] Precipitation color table? To: GRASS user list grass-user@lists.osgeo.org, Markus Neteler [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Markus wrote: anyone having a nice precipitation color table (e.g., range from 0mm to 2000mm)? you might find some nice ones here: http://sview01.wiredworkplace.net/pub/cpt-city/ convert those .cpt (ie GMT) color rules to something suitable for r.colors with the r.cpt2grass addon script. Sorry, I omitted that in my reply to Markus because it had been mentioned several times on the list -- my fault. or maybe one of the color scales here do the trick: http://oceancolor.gsfc.nasa.gov/PRODUCTS/colorbars.html I have converted a couple of those to GRASS r.colors rules files, here: http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.tools/palettes conversion script are given in the SVN log messages of those if you would like to convert the euphotic depth rules. By the look of it their version of NDVI is staged and would best be converted by hand. The SVN conversion script is something I have tried to figure out for a while: great! It always challenges me to find ways to dynamically generate raster color maps. I have understood that the algorithm is able to scale a 0-255 color map to the 0-65535 range; I am not sure how it could be adapted to scale to any range of data. Questions: - Why do you use 65535? - Slope and Intercept: are they parameter of a linear regression to convert 0-255 values to 0-65535? - In the line: 10((Slope * (($1 +1)2 -1)) + Intercept), $2, $3, $4)}' I am not sure what (($1 +1)2 -1)) does. The goal would be to develop a script which would take the data range of any raster and scale a 0-255 color rule to it. Thanks and regards, Luigi # scale 0-255 to 0-65535 and then convert to chlor-a values ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Precipitation color table?
Hamish wrote:
[...]
Luigi Ponti wrote:
The SVN conversion script is something I have tried to figure out for
a while: great! It always challenges me to find ways to dynamically
generate raster color maps.
I have understood that the algorithm is able to scale a 0-255 color map
to the 0-65535 range; I am not sure how it could be adapted to scale to
any range of data. Questions:
[...]
Thanks for the detailed description of your script. It keeps amazing me
how many things an awk script can do in a couple of lines.
The goal would be to develop a script which would take the
data range of any raster and scale a 0-255 color rule to it.
scale 0-255 to 0-100 and add a % sign. r.colors will do the rest.
r=
g=
b=
RULE=`echo $EIGHTBIT | awk '{print $1 / 2.55}'`% $r:$g:$b
- if $EIGHTBIT=255 then $RULE becomes 100% r:g:b
Really a good tip -- will implement it right away.
Regards,
Luigi
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Precipitation color table?
Dear Markus, I just ran into this page http://geography.uoregon.edu/datagraphics/color_scales.htm that includes, among others, precipitation color tables. I don't know if that can be useful. The page of this Lab also provides an interesting paper titled End of the Rainbow which elaborates on why one should not use continuously varying color schemes (and absolutely no rainbow color table). The way to go seems to be banded color schemes -- a color scheme with equally sized bands of constant color [1]. As I side note I was wondering how to draw such a color scheme (i.e. with equally sized bands of constant color) in GRASS. Kind regards, Luigi [1] Borland D, Taylor II RM (2007) Rainbow color map (still) considered harmful. IEEE Computer Graphics and Applications, 27, 14-17. From: Markus Neteler [EMAIL PROTECTED] Subject: [GRASS-user] Precipitation color table? To: GRASS user list grass-user@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 hi, anyone having a nice precipitation color table (e.g., range from 0mm to 2000mm)? I would like to nicely visualize data from the Global Precipitation Climatology Project (GPCP, [1]): ftp://rsd.gsfc.nasa.gov/pub/1dd/ Could be a nice addon for r.colors. thanks, Markus [1] details ftp://rsd.gsfc.nasa.gov/pub/1dd/1dd.summary ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Print message before hitting Run in the g.parser UI
Hi there, I have a bash script that processes a text file consisting of longitude and latitude columns plus other columns with point data -- the script imports the data and maps it. The script includes a parser-friendly section so that the g.parser UI shows up if called with no arguments. I would like to print info on the file such us the name of columns with data (e.g. via g.message) so that the user can choose which one to import. However, nothing can apparently be printed to the Output - GIS.m window before the Run button of the g.parser UI is pressed (too late for choosing a column...). Does anybody see a way around this? Running native WinGRASS 6.3.0 on a XP machine. Regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Connect additional dbf file based on layer 1 attribute column
Hamish wrote: Luigi: Does the GRASS DBF engine has a size limitation for some operations? I got an error while trying the following: GRASS 6.2.2 (SoilEurope2):~ d.vect -c sgdbe4_0_reclass display=attr attrcol=EAWC_TOP DBMI-DBF driver error: SQL parser error in statement: select EAWC_TOP from smu_ptrdb.dbf where cat = 330677 Error in db_open_select_cursor() ERROR: Cannot select attributes: select EAWC_TOP from smu_ptrdb.dbf where cat = 330677 Note that cat=330677 is 2572th row of the .dbf table (if I change attribute column, I always get an error on the same cat). select EAWC_TOP from smu_ptrdb where cat = 330677 not select EAWC_TOP from smu_ptrdb.dbf where cat = 330677 Yes, my fault: I had tried to v.db.connect using a table name with .dbf extension (i.e., smu_ptrdb.dbf). When using smu_ptrdb instead, all went well. Apparently the DBF driver assumes the table has a .dbf extension. Thanks and regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Connect additional dbf file based on layer 1 attribute column
Dear list, I am trying to import the European Vector Database (ESDB) version 2 to GRASS -- original data is ArcInfo shapefile. Maybe most of you already know about this freely downloadable database, but for those who don't: http://eusoils.jrc.ec.europa.eu/Library/ESDAC/Online_Data.cfm Well, the main ESDB shapefile layer name is called sgdbe4_0, which comes in the usual .shp, .prj, .shx, and .dbf extensions. The sgdbe4_0 layer gets imported OK via v.in.ogr, but most of the soil database is left out of the new GRASS vector, because it is included in additional .dbf files with different names, which are therefore not imported into the new GRASS vector. The sgdbe4_0.dbf table in the GRASS vector has at least one attribute column in common with the other additional .dbf files that don't get imported. Is it possible to connect those .dbf files to the imported GRASS vector based on an attribute column (not the 'cat' column) that is present both in layer 1 of the vector and in those additional (not connected) .dbf files? Thanks and regards, Luigi [GRASS 6.2 - Cygwin] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Connect additional dbf file based on layer 1 attribute column
Dear Moritz: that's a lot of options -- thanks!!! Moritz Lennert wrote: On 31/03/08 16:04, Luigi Ponti wrote: Dear list, I am trying to import the European Vector Database (ESDB) version 2 to GRASS [...] Is it possible to connect those .dbf files to the imported GRASS vector based on an attribute column (not the 'cat' column) that is present both in layer 1 of the vector and in those additional (not connected) .dbf files? Several options: 1) Use a real database backend (sqlite, postgresql), import the other dbf files with db.in.ogr, then either a) link to the map attribute table with v.db.join b) create a view combining the cat column from the map attribute with the other table and use v.db.connect to link to that table I suspected that joins and views were the way to go, because I had been reading philosophical threads some time ago about whether or not grass was supposed to support those. However, I am not a database expert, so thanks for indicating this path that may be a good primer to get more into real database backends for GRASS. 2) If the columns linking your map to the other tables are integer, you can also do - v.reclasse with 'column' option - v.db.connect the result of the reclass to the relevant dbf table Yes, the link columns are integers, luckily. I tried this -- easy and elegant. It works fine with DBF. Does the GRASS DBF engine has a size limitation for some operations? I got an error while trying the following: GRASS 6.2.2 (SoilEurope2):~ d.vect -c sgdbe4_0_reclass display=attr attrcol=EAWC_TOP DBMI-DBF driver error: SQL parser error in statement: select EAWC_TOP from smu_ptrdb.dbf where cat = 330677 Error in db_open_select_cursor() ERROR: Cannot select attributes: select EAWC_TOP from smu_ptrdb.dbf where cat = 330677 Note that cat=330677 is 2572th row of the .dbf table (if I change attribute column, I always get an error on the same cat). 3 More complicated: - in your existing map create a new layer of cats with e.g. v.category map=sgdbe4_0 option=add layer=2 - find the correspondance of the newly created cats with the cats in layer 1 with v.build sgbde4_0 option=cdump - use that information to create a new table which contains the layer 2 cat and the key column needed to link to the other dbf tables - then proceed as in 1) This one is a bit out of my range: I need to do some homework. Of the three options, this was the hardest for me to understand. We really could do with an enhancement to v.category to allow the creation of a second layer of categories based on a column value of the attributes linked to the first... Moritz Thanks again for a great GRASS-database seminar. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-windows] Re: [GRASS-user] Xming as X server for winGRASS?
Paul Kelly wrote: On Thu, 13 Mar 2008, Luigi Ponti wrote: [...] This works fine in my Cygwin/grass6.2.2 installation, although the GRASS_PNG_READ variable does not seem to be available in grass6.2 http://grass.ibiblio.org/gdp/html_grass62/pngdriver.html so the overlay thing suggested by Paul wouldn't work. In that case you might be able to use the g.pnmcomp module to compose the different PNG files together into one image. Yes, thanks for the tip -- I didn't think about that option. Trying the same with native winGRSSS 6.3.0 RC5 is less of a success: (1) no way to set environment variables via the GUI Output - GIS.m window; (2) not able to start GRASS via cmd.exe as suggested at http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status by typing the following at the cmd.exe prompt: C:\grass63RC5\bin\grass63.bat -text I get the output below: Welcome to GRASS 6.3.0RC5 (2008) GRASS homepage: http://grass.itc.it/ This version running thru: Windows Command Shell (cmd.exe) When ready to quit enter:exit Help is available with the command: g.manual -i See the licence terms with: g.version -c cmd.exe non è riconosciuto come comando interno o esterno, un programma eseguibile o un file batch. (the Italian error message would sound more or less like: cmd.exe is not recognized as an internal or external command, an executable program or a batch file.) That's very strange. Is it possible you have accidentally modified your PATH environment variable so that it no longer contains the path to cmd.exe? What does echo %PATH% say? (Run straight after you get the error message above). Also, in case its useful information, did you compile yourself or which binary version did you use (download location?) Paul Paul: echo %PATH% says: C:\msys\1.0\bin;C:\Perl\bin; which I have set in the grass63.bat file. When I type cmd.exe at the command prompt or just put only 'cmd.exe' inside a cmd.bat file, the Windows Shell starts fine. Even adding '%windir%\system32\cmd.exe' to PATH environmental variable leaves the error message unchanged. grass-6.3.0RC5 21-Feb-2008 downloaded from http://geog-pc40.ulb.ac.be/grass/wingrass/ Glynn: I am using Windows XP [Version 5.1.2600]. Changing the only reference to cmd.exe in init.bat to %COMSPEC% eliminates the error message. However, when I try to render a raster via Paul's command sequence, the PNG driver works fine but it complains about unknown png file type and no output.png file is written: GRASS 6.3.0RC5 (UTM32):C:\cygwin\home\luigi d.rast sample_raster PNG: GRASS_TRUECOLOR status: TRUE PNG: collecting to file: c:\output.png , GRASS_WIDTH=640, GRASS_HEIGHT=480 100% ERROR: write_image: unknown file type: png Thanks and regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-windows] Re: [GRASS-user] Xming as X server for winGRASS?
Paul Kelly wrote: On Fri, 14 Mar 2008, Luigi Ponti wrote: [...] Paul: echo %PATH% says: C:\msys\1.0\bin;C:\Perl\bin; I think that's the problem then. You need to *add* those directories to the PATH, not *replace* the PATH with them. The correct command should probably be something like set PATH=C:\msys\1.0\bin;C:\Perl\bin;%PATH% I'm not sure on the problem with the PNG driver. Paul OK, thanks: I had probably stripped off %PATH% from the grass63.bat file while modifying the PATH. Now it works fine. The PNG error: [...] PNG: collecting to file: c:\output.png , [...] ...there was a blank after the PNG filename [note the comma not right after the file name above], which made the extension '.png ' unknown. I will keep you posted on my progress. Regards and thanks again, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-windows] Re: [GRASS-user] Xming as X server for winGRASS?
Dear Paul and Glynn: thank you very much for your feedback. Glynn Clements wrote: [...] The problem with using monitors on native Windows isn't the graphics, it's the client-server communication. OK: hopefully I won't bother the list any longer on X-monitors. [...] If the environment variable GRASS_RENDER_IMMEDIATE is set to TRUE, PNG or PS, all d.* commands write graphics directly to a file, without using a monitor. The filename, format and dimensions are set by environment variables, as described at: http://grass.ibiblio.org/gdp/html_grass63/variables.html#png http://grass.ibiblio.org/gdp/html_grass63/variables.html#ps All of the functionality of the PNG and PS drivers is available in this way. This works fine in my Cygwin/grass6.2.2 installation, although the GRASS_PNG_READ variable does not seem to be available in grass6.2 http://grass.ibiblio.org/gdp/html_grass62/pngdriver.html so the overlay thing suggested by Paul wouldn't work. Trying the same with native winGRSSS 6.3.0 RC5 is less of a success: (1) no way to set environment variables via the GUI Output - GIS.m window; (2) not able to start GRASS via cmd.exe as suggested at http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status by typing the following at the cmd.exe prompt: C:\grass63RC5\bin\grass63.bat -text I get the output below: Welcome to GRASS 6.3.0RC5 (2008) GRASS homepage: http://grass.itc.it/ This version running thru: Windows Command Shell (cmd.exe) When ready to quit enter:exit Help is available with the command: g.manual -i See the licence terms with: g.version -c cmd.exe non è riconosciuto come comando interno o esterno, un programma eseguibile o un file batch. (the Italian error message would sound more or less like: cmd.exe is not recognized as an internal or external command, an executable program or a batch file.) Thanks again for your time and insights, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Xming as X server for winGRASS?
Hello, Is there any chance to use the native X Window server Xming http://www.straightrunning.com/XmingNotes/ for adding d.mon functionality to winGRASS 6.3? I gave it a try with no luck and would like to know if there is any background on this (apparently no clues on the web). I am trying to get batch display functionality on winGRASS to test it on a regular basis. Regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: strange behaviour of v.surf.idw
Dear Paul, I have found your PhD thesis excerpt very interesting: thanks for sharing it. Date: Tue, 12 Feb 2008 21:31:44 + (GMT) From: Paul Kelly [EMAIL PROTECTED] Subject: Re: [GRASS-user] strange behaviour of v.surf.idw To: G. Allegri [EMAIL PROTECTED] Cc: grassuser grass-user@lists.osgeo.org Also, have you tried running using the -n flag (no indexing) and comparing the results. I think they should be the same for all regions then but might turn up something else interesting. I started using v.surf.idw (for irregularly spaced points) in grass6.0 with no -n flag, then in 6.1 I noticed that the output raster changed from what it used to be (i.e., some stair-like artifacts appeared) and it was restored to the original look (i.e., a much smoother look) by adding the -n flag. By looking at your PhD thesis excerpt, it looks like the -n flag should only make the interpolation faster: I wonder if you have any idea why there may be differences, as you also say above. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: strange behaviour of v.surf.idw
Paul Kelly wrote: Hello Luigi Yes, I would consider that very small. As you can see in the thesis excerpt, the size of dataset I had in mind when I implemented the new algorithm was hundreds of thousands of points. Paul OK, I got it -- input points are very few: the algorithm was not designed for that and there is little performance gain. Thanks for the explanation. Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] --html-description flag
Markus Neteler wrote: Maybe the --html-description option should be mentioned at least in the Wiki AddOns page http://grass.gdf-hannover.de/wiki/GRASS_AddOns#Adding_something_new since I assume most of the HTML help files that come with add-on scripts were generated this way. Please go ahead - it's a Wiki :) markus Done. http://grass.gdf-hannover.de/wiki/GRASS_AddOns#Documenting_your_code I am not an expert in Wiki markup, so I tried to keep it simple. Regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Virtual memory available to cygwin GRASS
Glynn Clements wrote: Any process will use 100% CPU unless either it can process the data faster than the OS can provide it or it has to contend for the CPU with other active processes. The only time the CPU will be idle is if no process is ready to run, i.e. if all processes are blocked waiting for input, whether user input or data from a disk, network connection, external device, etc. OK: I will take some notes! Thanks very much for addressing this off-topic. Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Virtual memory available to cygwin GRASS
From: Jonathan Greenberg [EMAIL PROTECTED] Subject: Re: [GRASS-user] Virtual memory available to cygwin GRASS To: grass-user grass-user@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed There are ongoing issues with various windows incarnations of GRASS. Cygwin has had some issues with large files and higher memory addressing pretty much since its incarnation (I wrestled with this quite a bit a few years back). You might want to try the new grass binary that relies on mingw, I've seen my memory spike higher than 1gb during some analyses... Thanks, I have that installed for testing but most of what I do with GRASS involves batch processing via bash scripts that also call d.mon, so I have to stick to Cygwin for now. or, install unix someplace! I have done that on every windows machine I have worked with, by installing Ubuntu/GRASS dual boot (as suggested on this ML). I still keep working also under windows because many (should I say all?) people and institutions I collaborate with require a windows version of everything. I look forward to start experimenting with GRASS/d.mon functionality and meanwhile try to get some experience with Python, as this seems the future direction for cross-platform batch processing in GRASS -- am I wrong? Thanks, Luigi --j Luigi Ponti wrote: Hello, As a less-than-two-year old cygwin/GRASS user, I have never seen virtual memory going over 1 GB while doing intensive computations with GRASS (e.g., v.surf.idw interpolation). I haven't found much on the topic in the web so I tried the following to increase virtual memory available to cygwin: http://sources.redhat.com/ml/cygwin/2003-02/msg00234.html but noticed no difference and so I am wondering whether cygwin/GRASS gets compiled with the -mno-cygwin flag that apparently allows programs to allocate up to 1920 MBytes: http://sourceware.org/ml/cygwin/2005-04/msg01309.html Does anybody has experience with this? Thanks and regards, Luigi ___ 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] Re: [GRASS-windows] Virtual memory available to cygwin GRASS
Hamish wrote: Luigi Ponti wrote: As a less-than-two-year old cygwin/GRASS user, I have never seen virtual memory going over 1 GB while doing intensive computations with GRASS (e.g., v.surf.idw interpolation). Have you been getting out-of-memory errors or are you concerned that you are not making best use of all available resouces? Yes: the latter. If the latter, you don't see grass using much memory because it is fairly efficent most of the time and doesn't need to- especially the core GIS and raster parts of it. When you consider the amount of RAM+CPU power typically available back when that code was written, it isn't surprising that it was done in such a way. Thanks Hamish, I see your point. What I don't quite understand is why CPU usage always goes up to 100% when running GRASS commands, while allocated memory is always about 25% -- flat, no peaks. A nice side effect of being built under those constraints is that now with more computing resources available it scales to huge datasets quite well. That's something I never considered -- interesting. So only worry if you are getting out-of-memory errors, otherwise just enjoy. It won't use any more or less memory than just the amount it needs. So in my case the CPU is very busy because of the Cygwin overload but the memory usage doesn't go up because of GRASS efficiency? Kind regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Virtual memory available to cygwin GRASS
Hello, As a less-than-two-year old cygwin/GRASS user, I have never seen virtual memory going over 1 GB while doing intensive computations with GRASS (e.g., v.surf.idw interpolation). I haven't found much on the topic in the web so I tried the following to increase virtual memory available to cygwin: http://sources.redhat.com/ml/cygwin/2003-02/msg00234.html but noticed no difference and so I am wondering whether cygwin/GRASS gets compiled with the -mno-cygwin flag that apparently allows programs to allocate up to 1920 MBytes: http://sourceware.org/ml/cygwin/2005-04/msg01309.html Does anybody has experience with this? Thanks and regards, Luigi ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
