Re: [GRASS-user] can not install addons with g.extension
Thanks Glynn! I have added py extension in `rules` file [1] and requested for the new build. Should be available in 10min. Thanks for the fix. It already percolated into the ubuntu package grass70 Version: 7.0.0+1svn64634~ubuntu14.04.1 g.extension fails now because it can not find the html module. [...] Traceback (most recent call last): File /usr/lib/grass70/tools/g.html2man.py, line 5, in module from html import HTMLParser, HTMLParseError ImportError: No module named html [...] It's in the tools directory (along with groff.py, which is also required). But the rules file doesn't appear to install those. Comparing the contents of the directory 'tools' from the ubuntu package and the built from source: $ ls -l /usr/lib/grass70/tools total 16 -rwxr-xr-x 1 root root 1501 Feb 17 17:00 g.html2man.py -rwxr-xr-x 1 root root 8449 Feb 17 17:00 mkhtml.py $ ls -l /usr/local/src/grass70/dist.x86_64-unknown-linux-gnu/tools total 60 -rwxrwxr-x 1 rnuske rnuske 6240 Feb 17 11:27 g.echo -rwxr-xr-x 1 rnuske rnuske 1501 Feb 17 11:27 g.html2man.py -rw-r--r-- 1 rnuske rnuske 5940 Feb 17 11:27 groff.py -rw-r--r-- 1 rnuske rnuske 10174 Feb 17 11:27 groff.pyc -rw-r--r-- 1 rnuske rnuske 5384 Feb 17 11:27 html.py -rw-r--r-- 1 rnuske rnuske 6892 Feb 17 11:27 html.pyc -rwxr-xr-x 1 rnuske rnuske 8449 Feb 17 11:27 mkhtml.py There is at least groff.py and html.py missing in the ubuntu package. No idea about 'g.echo'. Martin could you (or somebody else knowledgeable) add these two to the rules probably below line 183 [1] ? [1] http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/rules#L183 Thanks a lot Robert ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] sampling points in a grid
On Tue, Feb 17, 2015 at 5:30 PM, Markus Neteler nete...@osgeo.org wrote: On Tue, Feb 17, 2015 at 4:49 PM, Margherita Di Leo direg...@gmail.com wrote: Hi, I have a vector of points. According to a regular grid, I need to (randomly) sample a certain number n of these points in each cell of the grid. Such number n is given in a column of the attribute table of the grid. How would you do this? With a small script this should be doable: - generate the grid as polygons (v.mkgrid) - loop over each polygon - fetch category number or v.extract - fetch corresponding number of points to be created from DB - v.random, using the current grid polygon for restricted creation feature http://grass.osgeo.org/grass70/manuals/v.random.html#restriction-to-vector-areas Here lies the problem. I need to randomly pick points that are already existing. Example: for grid cell that has ID 42, I have 50 points, and have to randomly pick 7 out of these 50. - save point map - patch all point maps into single resulting map - remove single point maps Something like this... Markus -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Deleting polygons
Hello, I got some shp files with many polygons. Now I want to delete some of them, but I have not been able to do so. I tried v.edit which does not seem to have any effect. Then I went to the attribute table and tried both deleting the record and the feature and both times I got rid of the filling of the polygon, but still have the border. I tried to delete these borders using the digitizing tool, but I did not find any way of doing so. Thanks a lot. Best wishes, Andrea Gesendet:Montag, 16. Februar 2015 um 23:12 Uhr Von:Thomas Adams tea...@gmail.com An:Markus Metz markus.metz.gisw...@gmail.com Cc:grass-user@lists.osgeo.org grass-user@lists.osgeo.org Betreff:Re: [GRASS-user] Question about r.watershed and flow accumulation grid Markus, Thank you very much for you insights; Yes, I have seen significant differences between DEM derived streams and those from other sources. I have not attempted burning the streams into the DEM as Micha suggested. FORTUNATELY, I had a 100m DEM from the USGS that was fine for my uses; so, the problem area that I had was resolved and I did not have to resort to such drastic measures -- it was disheartening to think I might have to resort to that. So, whats really cool is that I have hydrologically modeled a good size basin (8332 sq km) at a 250 meter grid spacing; all the model parameter estimation was done using GRASS 70, as is the animation of the simulation. Ill be posting it to Vimeo later today. Its the same basin area I did previously that you saw, only the previous one had a much coarser (4km) spatial resolution. Thanks all! Tom On Mon, Feb 16, 2015 at 2:42 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Feb 14, 2015 at 3:45 PM, Thomas Adams tea...@gmail.com wrote: The reason I need to use the D8 (SFD) algorithm is that I am generating a file that identifies how pixels are connected hydraulically; the distributed hydrologic model I am using requires that this connectivity be unique; so a pixel must be uniquely connected to a single downstream pixel. Consequently, with the GRASS scripting I have done to produce the needed ascii output file I need, I think I have to use the D8 SFD algorithm. The connectivity (drainage output of r.watershed) is always unique, no matter if you use D8 or MFD. In case of MFD, the predominant direction is used. As Micha said, r.watershed does not produce breaks in flow accumulation, it stops only at the edge of the current region and at NULL cells. Modifying a DEM to match a river network can be dangerous, I would recommend to not burn the whole river network into the DEM but modify only those parts that really need modification. Usually you will never get a perfect match between a river network created from different sources and a stream network derived from a DEM. Markus M Cheers! Tom On Sat, Feb 14, 2015 at 5:02 AM, Micha Silver mi...@arava.co.il wrote: Hi Thomas: On 02/13/2015 10:28 PM, Thomas Adams wrote: Micha, No, after looking at whats going-on in more detail, I think the DEM is too coarse (even at 90m), so the flow direction and accumulation is mis-directed in one critical area of the watershed. I tried using r.carve, but it is taking forever after 15 minutes, no advancement of the progress bar I dont see why carving into a DEM should cause r.watershed to run more slowly, unless you have carved out only a section of some of the streams. If your carving does not continue right to the outlet of the stream (i.e. to an ocean, or to the edge of the region) then r.watershed would actually have to fill in that carved out stream to find a flow path. That could cause the performance hit. Additionally, are you using GRASS 7.0? As you probably know some substantial improvements to the algorithms were introduced in 7 for several modules, r.watershed among them. And third, why use the D8 flow direction when MFD is available (again in GRASS 7.0)? That could also be causing what you refer to as breaks in the channels. MFD is especailly good, I believe, in flat areas. In any case, Keep up posted on your progress. Thanks, Micha I did not want to have to do this for my testing, but Ill probably try at 3 or 10 meter lots of pixels for my basin! The problem, in general, for me is that I want to apply my techniques at international locations where I probably wont have the benefit of higher resolution DEMs, so I need to develop something a bit more robust Cheers! Tom On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver mi...@arava.co.il wrote: On 02/13/2015 08:48 PM, Thomas Adams wrote: Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Are these breaks possibly caused by null pixels in the
Re: [GRASS-user] Is the location's VAR file required?
On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
To complete the description, the gisrc contains: LOCATION_NAME: startLocation MAPSET: PERMANENT DIGITIZER: none GISDBASE: /tmp/tmp9YVf_N OVERWRITE: 1 DEBUG: 0 GUI: text 2015-02-18 19:26 GMT+01:00 G. Allegri gioha...@gmail.com: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. Markus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. Markus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] can not install addons with g.extension
Hi, 2015-02-18 11:09 GMT+01:00 Robert Nuske rnu...@gwdg.de: $ ls -l /usr/local/src/grass70/dist.x86_64-unknown-linux-gnu/tools total 60 -rwxrwxr-x 1 rnuske rnuske 6240 Feb 17 11:27 g.echo -rwxr-xr-x 1 rnuske rnuske 1501 Feb 17 11:27 g.html2man.py -rw-r--r-- 1 rnuske rnuske 5940 Feb 17 11:27 groff.py -rw-r--r-- 1 rnuske rnuske 10174 Feb 17 11:27 groff.pyc -rw-r--r-- 1 rnuske rnuske 5384 Feb 17 11:27 html.py -rw-r--r-- 1 rnuske rnuske 6892 Feb 17 11:27 html.pyc -rwxr-xr-x 1 rnuske rnuske 8449 Feb 17 11:27 mkhtml.py There is at least groff.py and html.py missing in the ubuntu package. No idea about 'g.echo'. Martin could you (or somebody else knowledgeable) add these two to the rules probably below line 183 [1] ? done in [1]. I requested new build right now, should be available in 15min for testing. Martin [1] http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/revision/47 -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
Hi Giovanni, On Wed, Feb 18, 2015 at 7:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. are you on 32 bit or 64 bit? Please try trunk or current svn of 7.0, a number of bugs have been fixed in the meantime. Markus M I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. Markus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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] Is the location's VAR file required?
On Wed, Feb 18, 2015 at 4:01 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Feb 18, 2015 at 9:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: I think we should really implement #2579 [1] in one way or the other. This would make custom setups [2] not necessary for most cases. What do you think? What should be the command line parameters? Importing a shapefile to a new location without a VAR file works for me, and I think we should find out why it does not work for Giovanni. His approach should (must) work as it is. Could this be related? http://lists.osgeo.org/pipermail/grass-dev/2014-September/070639.html Anna Markus M Vaclav [1] http://trac.osgeo.org/grass/ticket/2579 [2] http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly On Wed, Feb 18, 2015 at 1:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
Here I am, it seems that trunk is working. I didn't obtain segfault anymore. But now the import (to a new location) doesn't works for me. I did the same as in the previous release versione, even changing dns to input. I will investigate more. 2015-02-18 22:14 GMT+01:00 Anna Petrášová kratocha...@gmail.com: On Wed, Feb 18, 2015 at 4:01 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Feb 18, 2015 at 9:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: I think we should really implement #2579 [1] in one way or the other. This would make custom setups [2] not necessary for most cases. What do you think? What should be the command line parameters? Importing a shapefile to a new location without a VAR file works for me, and I think we should find out why it does not work for Giovanni. His approach should (must) work as it is. Could this be related? http://lists.osgeo.org/pipermail/grass-dev/2014-September/070639.html Anna Markus M Vaclav [1] http://trac.osgeo.org/grass/ticket/2579 [2] http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly On Wed, Feb 18, 2015 at 1:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
On Wed, Feb 18, 2015 at 10:14 PM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Feb 18, 2015 at 4:01 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Feb 18, 2015 at 9:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: I think we should really implement #2579 [1] in one way or the other. This would make custom setups [2] not necessary for most cases. What do you think? What should be the command line parameters? Importing a shapefile to a new location without a VAR file works for me, and I think we should find out why it does not work for Giovanni. His approach should (must) work as it is. Could this be related? http://lists.osgeo.org/pipermail/grass-dev/2014-September/070639.html I think not because I started GRASS in a new location, VAR was created, then I deleted it, then I ran v.in.ogr successfully, and VAR was recreated again. v.in.ogr works for me without a VAR file present. Markus M Anna Markus M Vaclav [1] http://trac.osgeo.org/grass/ticket/2579 [2] http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly On Wed, Feb 18, 2015 at 1:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
I think we should really implement #2579 [1] in one way or the other. This would make custom setups [2] not necessary for most cases. What do you think? What should be the command line parameters? Vaclav [1] http://trac.osgeo.org/grass/ticket/2579 [2] http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly On Wed, Feb 18, 2015 at 1:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
On Wed, Feb 18, 2015 at 9:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: I think we should really implement #2579 [1] in one way or the other. This would make custom setups [2] not necessary for most cases. What do you think? What should be the command line parameters? Importing a shapefile to a new location without a VAR file works for me, and I think we should find out why it does not work for Giovanni. His approach should (must) work as it is. Markus M Vaclav [1] http://trac.osgeo.org/grass/ticket/2579 [2] http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly On Wed, Feb 18, 2015 at 1:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. 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] Is the location's VAR file required?
I confirm that trunks doesn't causes segfault. Same mapset and location. Now I have to figure our why the import doesn't happen: v.in.ogr input=/mnt/data/centroids.shp location=workLocation output=centroids -ie The location is created but is empty. Thr same shape is correctly imported from GUI. I will double check and try it again... Il 18/feb/2015 22:34 Markus Metz markus.metz.gisw...@gmail.com ha scritto: On Wed, Feb 18, 2015 at 10:14 PM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Feb 18, 2015 at 4:01 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Feb 18, 2015 at 9:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: I think we should really implement #2579 [1] in one way or the other. This would make custom setups [2] not necessary for most cases. What do you think? What should be the command line parameters? Importing a shapefile to a new location without a VAR file works for me, and I think we should find out why it does not work for Giovanni. His approach should (must) work as it is. Could this be related? http://lists.osgeo.org/pipermail/grass-dev/2014-September/070639.html I think not because I started GRASS in a new location, VAR was created, then I deleted it, then I ran v.in.ogr successfully, and VAR was recreated again. v.in.ogr works for me without a VAR file present. Markus M Anna Markus M Vaclav [1] http://trac.osgeo.org/grass/ticket/2579 [2] http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly On Wed, Feb 18, 2015 at 1:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. 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 ___ 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] sampling points in a grid
Maybe you can use a database selection approach for example in sqlite. First update your points with your grid cell ID and then randomly select 7 rows from the selection where the grid cell ID == 42. In sqlite there exists the function random(). Here you can find an approach to select random rows from a sqlite table: http://stackoverflow.com/questions/2279706/select-random-row-from-an-sqlite-table I have not tested that approach, but maybe worth a try... /Johannes On Wed, Feb 18, 2015 at 11:55 AM, Margherita Di Leo direg...@gmail.com wrote: On Tue, Feb 17, 2015 at 5:30 PM, Markus Neteler nete...@osgeo.org wrote: On Tue, Feb 17, 2015 at 4:49 PM, Margherita Di Leo direg...@gmail.com wrote: Hi, I have a vector of points. According to a regular grid, I need to (randomly) sample a certain number n of these points in each cell of the grid. Such number n is given in a column of the attribute table of the grid. How would you do this? With a small script this should be doable: - generate the grid as polygons (v.mkgrid) - loop over each polygon - fetch category number or v.extract - fetch corresponding number of points to be created from DB - v.random, using the current grid polygon for restricted creation feature http://grass.osgeo.org/grass70/manuals/v.random.html#restriction-to-vector-areas Here lies the problem. I need to randomly pick points that are already existing. Example: for grid cell that has ID 42, I have 50 points, and have to randomly pick 7 out of these 50. - save point map - patch all point maps into single resulting map - remove single point maps Something like this... Markus -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ 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] v.in.ogr with new location doesn't import my data
I'm using v.in.ogr with the location option. The new location is created correctly, and the projection is set to the one defined by my shapefile's .prj file, but no data is imported. The mapset is empty. The command line reports the following message: WARNING: All available OGR layers will be imported into vector map centroidi_province Location workLocation created The same command launched in a preexisting location (and without the location option) works fine and the data is correctly imported. giovanni -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr with new location doesn't import my data
I forgot to say that I'm using grass 7 on a Ubuntu machine 2015-02-18 13:06 GMT+01:00 G. Allegri gioha...@gmail.com: I'm using v.in.ogr with the location option. The new location is created correctly, and the projection is set to the one defined by my shapefile's .prj file, but no data is imported. The mapset is empty. The command line reports the following message: WARNING: All available OGR layers will be imported into vector map centroidi_province Location workLocation created The same command launched in a preexisting location (and without the location option) works fine and the data is correctly imported. giovanni -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Is the location's VAR file required?
I'm getting segmentation faults in case I run a command on a location missing the VAR file. I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases giovanni -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr with new location doesn't import my data
On Wed, Feb 18, 2015 at 7:07 AM, G. Allegri gioha...@gmail.com wrote: I forgot to say that I'm using grass 7 on a Ubuntu machine 2015-02-18 13:06 GMT+01:00 G. Allegri gioha...@gmail.com: I'm using v.in.ogr with the location option. The new location is created correctly, and the projection is set to the one defined by my shapefile's .prj file, but no data is imported. The mapset is empty. The command line reports the following message: WARNING: All available OGR layers will be imported into vector map centroidi_province Location workLocation created The same command launched in a preexisting location (and without the location option) works fine and the data is correctly imported. Hm, it is working for me in G70 and G71 (Ubuntu as well): v.in.ogr input=/home/anna/grassdata/data/shoreline_oceanfront_1998/Shoreline_Oceanfront_1998.shp output=test location=testLoc Location testLoc created Check if OGR layer Shoreline_Oceanfront_1998 contains polygons... 100% Importing 21 features (OGR layer Shoreline_Oceanfront_1998)... 100% - Building topology for vector map test@PERMANENT... Registering primitives... 67 primitives registered 19183 vertices registered Building areas... 100% 0 areas built 0 isles built Attaching islands... Attaching centroids... 100% Number of nodes: 128 Number of primitives: 67 Number of points: 0 Number of lines: 67 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 Anna giovanni -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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] v.in.ogr with new location doesn't import my data
Thanks Anna, yuor example gave me the hint: I didn't set the output parameter, which I thought could be obtained from the input dataset name. giovanni 2015-02-18 15:28 GMT+01:00 Anna Petrášová kratocha...@gmail.com: On Wed, Feb 18, 2015 at 7:07 AM, G. Allegri gioha...@gmail.com wrote: I forgot to say that I'm using grass 7 on a Ubuntu machine 2015-02-18 13:06 GMT+01:00 G. Allegri gioha...@gmail.com: I'm using v.in.ogr with the location option. The new location is created correctly, and the projection is set to the one defined by my shapefile's .prj file, but no data is imported. The mapset is empty. The command line reports the following message: WARNING: All available OGR layers will be imported into vector map centroidi_province Location workLocation created The same command launched in a preexisting location (and without the location option) works fine and the data is correctly imported. Hm, it is working for me in G70 and G71 (Ubuntu as well): v.in.ogr input=/home/anna/grassdata/data/shoreline_oceanfront_1998/Shoreline_Oceanfront_1998.shp output=test location=testLoc Location testLoc created Check if OGR layer Shoreline_Oceanfront_1998 contains polygons... 100% Importing 21 features (OGR layer Shoreline_Oceanfront_1998)... 100% - Building topology for vector map test@PERMANENT... Registering primitives... 67 primitives registered 19183 vertices registered Building areas... 100% 0 areas built 0 isles built Attaching islands... Attaching centroids... 100% Number of nodes: 128 Number of primitives: 67 Number of points: 0 Number of lines: 67 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 Anna giovanni -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Landsat 8 Workflow for Grass 7.0.0RC2
Hi Grass Users, I want to use the following Landsat 8 workflow to obtain some pansharpened images but have a problem when i convert the DN values to 8bit for pansharpening. Here is my preferred workflow in Grass 7.0.0RC2. · r.in.gdal (success) · i.landsat.toar (success) · r.rescale bands 432 8 (convert reflectance 'DN' values to 0-255, 8bit) · i.pansharpen bands 432 with 8 · r.rescale (convert 0-255 values back to reflectance 'DN) · i.colors.enhance (pansharp bands) · d.rgb My question...is this a valid workflow? because i'm getting the same two errors below and the images when displayed look solid grey when viewed with d.rgb:- *displaying the pansharpened images error log:-* (Tue Feb 17 14:57:26 2015) g.list rast LC82040242014206LGN00_B1 LC82040242014206LGN00_B10 LC82040242014206LGN00_B11 LC82040242014206LGN00_B2 LC82040242014206LGN00_B3 LC82040242014206LGN00_B4 LC82040242014206LGN00_B5 LC82040242014206LGN00_B6 LC82040242014206LGN00_B7 LC82040242014206LGN00_B8 LC82040242014206LGN00_B9 LC82040242014206LGN00_BQA LC82040242014206LGN00_refl1 LC82040242014206LGN00_refl10 LC82040242014206LGN00_refl11 LC82040242014206LGN00_refl2 LC82040242014206LGN00_refl3 LC82040242014206LGN00_refl4 LC82040242014206LGN00_refl5 LC82040242014206LGN00_refl6 LC82040242014206LGN00_refl7 LC82040242014206LGN00_refl8 LC82040242014206LGN00_refl9 LC82040242014318LGN00_B1 LC82040242014318LGN00_B10 LC82040242014318LGN00_B11 LC82040242014318LGN00_B2 LC82040242014318LGN00_B3 LC82040242014318LGN00_B4 LC82040242014318LGN00_B5 LC82040242014318LGN00_B6 LC82040242014318LGN00_B7 LC82040242014318LGN00_B8 LC82040242014318LGN00_B9 LC82040242014318LGN00_BQA LC82040242014318LGN00_refl1 LC82040242014318LGN00_refl10 LC82040242014318LGN00_refl11 LC82040242014318LGN00_refl2 LC82040242014318LGN00_refl2_rescale LC82040242014318LGN00_refl3 LC82040242014318LGN00_refl3_rescale LC82040242014318LGN00_refl4 LC82040242014318LGN00_refl4_rescale LC82040242014318LGN00_refl5 LC82040242014318LGN00_refl6 LC82040242014318LGN00_refl7 LC82040242014318LGN00_refl8 LC82040242014318LGN00_refl8_rescale LC82040242014318LGN00_refl9 (Tue Feb 17 14:57:27 2015) Command finished (0 sec) Command 'd.rast map=LC82040242014318LGN00_pansharp@PERMANENT' failed Details: Raster map LC82040242014318LGN00_pansharp@PERMANENT not found *i.colors.enhance error log:-* (Tue Feb 17 13:06:40 2015) i.colors.enhance red=LC82040242014318LGN00_B4@PERMANENT green=LC82040242014318LGN00_B3@PERMANENT blue=LC82040242014318LGN00_refl2@PERMANENT strength=96 Processing... Process Process-3: Traceback (most recent call last): File C:\OSGeo4W\apps\Python27\lib\multiprocessing\process.py, line 258, in _bootstrap self.run() File C:\OSGeo4W\apps\Python27\lib\multiprocessing\process.py, line 114, in run self._target(*self._args, **self._kwargs) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\scripts\i.color s.enhance.py, line 103, in get_percentile_mp result = get_percentile(map, percentiles) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\scripts\i.color s.enhance.py, line 89, in get_percentile percentiles = values, quiet = True) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\gras s\script\core.py, line 427, in read_command return handle_errors(returncode, stdout, args, kwargs) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\gras s\script\core.py, line 310, in handle_errors returncode=returncode) CalledModuleError: Module run None ['r.quantile', '--q', 'input=LC82040242014318LGN00_refl2@PERMANENT', 'percentiles=2,96'] ended with error Process ended with non-zero return code -1073741571. See errors in the (error) output. Process Process-2: Traceback (most recent call last): File C:\OSGeo4W\apps\Python27\lib\multiprocessing\process.py, line 258, in _bootstrap self.run() File C:\OSGeo4W\apps\Python27\lib\multiprocessing\process.py, line 114, in run self._target(*self._args, **self._kwargs) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\scripts\i.color s.enhance.py, line 103, in get_percentile_mp result = get_percentile(map, percentiles) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\scripts\i.color s.enhance.py, line 89, in get_percentile percentiles = values, quiet = True) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\gras s\script\core.py, line 427, in read_command return handle_errors(returncode, stdout, args, kwargs) File C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\gras s\script\core.py, line 310, in handle_errors returncode=returncode) CalledModuleError: Module run None ['r.quantile', '--q', 'input=LC82040242014318LGN00_B3@PERMANENT', 'percentiles=2,96'] ended with error Process ended with non-zero return code -1073741571. See errors in the (error) output. Process
Re: [GRASS-user] Landsat 8 Workflow for Grass 7.0.0RC2
On 18.02.2015 14:44, Paul Shapley wrote: I want to use the following Landsat 8 workflow to obtain some pansharpened images but have a problem when i convert the DN values to 8bit for pansharpening. .. Here's something that will work with anything, no matter the bit-ness: https://github.com/NikosAlexandris/i.fusion.hpf. I've been trying to get this integrated into i.pansharpen. But didn't do anything serious so far (various reasons). Best, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat 8 Workflow for Grass 7.0.0RC2
Paul Shapley wrote: I want to use the following Landsat 8 workflow to obtain some pansharpened images but have a problem when i convert the DN values to 8bit for pansharpening. Here is my preferred workflow in Grass 7.0.0RC2. · r.in.gdal (success) · i.landsat.toar (success) · r.rescale bands 432 8 (convert reflectance 'DN' values to 0-255, 8bit) · i.pansharpen bands 432 with 8 · r.rescale (convert 0-255 values back to reflectance 'DN) · i.colors.enhance (pansharp bands) · d.rgb My question...is this a valid workflow? because i'm getting the same two errors below and the images when displayed look solid grey when viewed with d.rgb: Paul, just some thoughts: - why mix the term Digital Number (DN) with Reflectance? DN's are (supposed to be) the result of the quantisation (and calibration) of the energy that hits the sensor. And Reflectance (unitless) is the result of radiometrically processing the DN values. - Not sure if the values of the end-product, as in the work-flow you outline above, can be called Reflectance. - Landsat8 is 16-bit. Once you downscale down to 8-bit, how would you come back to the 16-bit details? I think the radiometric detail is lost. Instead, import DN to ToAR Pan-Sharpen with i.fusion.hpf (to not loose the fine digits which are important if you seek for more than just sharp visuals for viewing purposes). Best, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is the location's VAR file required?
Everything is working fine now. The problem with the effective import was the -i option, which I obtained from another script and I wasn't aware of it... 2015-02-18 23:30 GMT+01:00 G. Allegri gioha...@gmail.com: I confirm that trunks doesn't causes segfault. Same mapset and location. Now I have to figure our why the import doesn't happen: v.in.ogr input=/mnt/data/centroids.shp location=workLocation output=centroids -ie The location is created but is empty. Thr same shape is correctly imported from GUI. I will double check and try it again... Il 18/feb/2015 22:34 Markus Metz markus.metz.gisw...@gmail.com ha scritto: On Wed, Feb 18, 2015 at 10:14 PM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Feb 18, 2015 at 4:01 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Feb 18, 2015 at 9:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: I think we should really implement #2579 [1] in one way or the other. This would make custom setups [2] not necessary for most cases. What do you think? What should be the command line parameters? Importing a shapefile to a new location without a VAR file works for me, and I think we should find out why it does not work for Giovanni. His approach should (must) work as it is. Could this be related? http://lists.osgeo.org/pipermail/grass-dev/2014-September/070639.html I think not because I started GRASS in a new location, VAR was created, then I deleted it, then I ran v.in.ogr successfully, and VAR was recreated again. v.in.ogr works for me without a VAR file present. Markus M Anna Markus M Vaclav [1] http://trac.osgeo.org/grass/ticket/2579 [2] http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly On Wed, Feb 18, 2015 at 1:26 PM, G. Allegri gioha...@gmail.com wrote: Hi Markus, I wrote the details in another recent email and I forgot to write the here, sorry. GRASS 7.0.0 RC1 on Ubuntu 14.04. I'm creating a temporary database with an empty start location, with no CRS defined (proj code 0, i.e. XY). My location contains only the the WIND and DEFAULT_WIND files with the following content: proj: 0 zone: 0 north: 1 south: 0 east: 1 west: 0 cols: 1 rows: 1 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 1 rows3: 1 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 The env variables I'm using are: export PYTHONPATH='/usr/lib/grass70/etc/python' export GISRC='/tmp/tmp9YVf_N/gisrc' export GRASS_VERSION='7.0.0' export PATH='/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/home/giova/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' export GIS_LOCK=$ export LD_LIBRARY_PATH='/usr/lib/grass70/lib' export GISBASE='/usr/lib/grass70' Whatevere shapefile I try to import I obtain a segfault. This is the test command: :/ v.in.ogr dsn=/mnt/data/centroids.shp output=centroids location=workLocation -ie If I add the VAR file with: DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db eveythign works fine. giovanni 2015-02-18 18:08 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Feb 18, 2015 at 3:24 PM, G. Allegri gioha...@gmail.com wrote: I'm getting segmentation faults in case I run a command on a location missing the VAR file. On which OS, which GRASS version? I thought it was optional, as it's said here: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#GRASS_databases Please post a reproducible example, thanks. 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
