Re: [GRASS-user] improve v.rast.stats speed?
Hamish wrote: Jose Gómez-Dans wrote: My take on this is to rasterize my vector data with gdal_rasterize (you can have a look at the rasterisation code and see how it works, in case you need to eg buffer your vector data), load it up in python, load my dataset in python, and calculate whatever stats with scipy+numpy. If you look at this thread, you'll find it is very fast: http://article.gmane.org/gmane.comp.python.scientific.user/19412. numpy is already requested by the new wxGUI*, so with numpy around anyway, maybe some python module could be written for grass7, where python is a full dependency? * see gui/wxpython/gui_modules/profile.py I think too that grass should provide a reasonably fast way to get this kind of stats. You can still devise your own solution if you want, but IMHO grass must be able to do this job reasonably fast and user-friendly. Taking the risk of becoming annoying: with r.univar.zonal, everything could be done in one pass: rasterize vector, no need for mapcalc, run r.univar.zonal once (which itself needs only one pass), load stats to attribute table, done. With the example that started this thread, everything should be completed in very few minutes. Rasterizing the vector might take the longest. Anyway, when it comes to processing time, I'm a speed junky, and 5 hours is simply unacceptable if it can also be done in minutes or even seconds, and grass should do that, not forcing users to come up with their own workarounds for something that grass is supposed to do. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: FW: FW: [GRASS-user] unable to install Grass
2009/2/21 Jimmy Maro jimmy.m...@nari.org.pg: I managed to get the mapset error sorted after reinstalling the program. It still wont start its giving following error; Python.exe - Unable to locate Component This application has failed to start because ipp-5.3.dll was not found. Reinstalling the application may fix this problem Was it perhaps ippj-5.3.dll? Then please try this http://trac.osgeo.org/osgeo4w/ticket/27 Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 7 and SQLITE o POSTGRES
Hi Benjamin, thanks for the reply. I read something about spatial lite. I work mainly with GRASS and thought to use it with SQLite because GRASS 7 should be able to work directly on the SQLite for the geometries and the attributes (in short, without v.exeternal). I think, but I do not know if it is correct, that implementing a DB in SQLite might be possible to access data with GRASS 7, QGIS, gvSIG, etc... (my colleagues still do not use GRASS) but maybe it's only my hope :-) With postgres/postgis I should always connect with v.external and I could not do spatial analysis using the tools of GRASS ... right? Thank you very much Gabriele Benjamin Ducke wrote: Hi Gabriele, A spatial database extension allows you to store geographic features as part of the database itself. There are many advantages to this, especially if you work with huge vector datasets. SQLite has a spatial extension equivalent to PostGIS. It is called SpatiaLite. It has the same functionality as PostGIS. The latest version of OGR already has some basic support for SQLite, so hopefully in the near future all open source GIS will support SQLite/SpatiaLite as a datasource. However, if you are planning to to set up a spatial data infrastructure for collaborative work, you should probably choose PostgreSQL/PostGIS as your data backend, because it supports user access control and is currently better supported by open source GIS. Ben - Original Message - From: Gabriele N. gis...@libero.it To: grass-user@lists.osgeo.org Sent: Friday, February 20, 2009 5:38:48 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: [GRASS-user] GRASS 7 and SQLITE o POSTGRES Hello. I work with colleagues sharing the files (shapes .. etc) that are on a NAS server. I use ubuntu 8.10 (with GRASS locally) and my colleagues use windows. I would do this: - A GIS with all these data - Building a database (sqlite or postgres/postgis/ on NAS) - An excellent organization of the data - To enable access to data with other software (such as QGIS and gvSIG) GRASS 7 will default SQLite and therefore should be different to GRASS 6. In the sense that now GRASS 6 connects to the DB (postgres and / or sqlite) but works differently than the dbf ... or wrong? SQLite does not have the spatial component as postgis with postgres? What does this? Can you tell me the steps to follow? What do you recommend? Thanks Gabriele -- View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2360247.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2363407.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 7 and SQLITE o POSTGRES
On 21/02/09 12:44, Gabriele N. wrote: Hi Benjamin, thanks for the reply. I read something about spatial lite. I work mainly with GRASS and thought to use it with SQLite because GRASS 7 should be able to work directly on the SQLite for the geometries and the attributes (in short, without v.exeternal). I think, but I do not know if it is correct, that implementing a DB in SQLite might be possible to access data with GRASS 7, QGIS, gvSIG, etc... (my colleagues still do not use GRASS) but maybe it's only my hope :-) The SQLite support in GRASS concerns the attribute management, not geometries. To access geometries in a SpatiaLite, you have to go through v.external. One of the main reasons is that GRASS vector format is topological and SpatiaLite isn't. Most vector modules expect topological structure to work. With postgres/postgis I should always connect with v.external and I could not do spatial analysis using the tools of GRASS ... right? Right, but it is the same for SpatiaLite. Note that QGIS can access GRASS data directly (not sure about gvSIG) so you can actually have your geometries in GRASS format and still work with QGIS. Moritz Thank you very much Gabriele Benjamin Ducke wrote: Hi Gabriele, A spatial database extension allows you to store geographic features as part of the database itself. There are many advantages to this, especially if you work with huge vector datasets. SQLite has a spatial extension equivalent to PostGIS. It is called SpatiaLite. It has the same functionality as PostGIS. The latest version of OGR already has some basic support for SQLite, so hopefully in the near future all open source GIS will support SQLite/SpatiaLite as a datasource. However, if you are planning to to set up a spatial data infrastructure for collaborative work, you should probably choose PostgreSQL/PostGIS as your data backend, because it supports user access control and is currently better supported by open source GIS. Ben - Original Message - From: Gabriele N. gis...@libero.it To: grass-user@lists.osgeo.org Sent: Friday, February 20, 2009 5:38:48 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: [GRASS-user] GRASS 7 and SQLITE o POSTGRES Hello. I work with colleagues sharing the files (shapes .. etc) that are on a NAS server. I use ubuntu 8.10 (with GRASS locally) and my colleagues use windows. I would do this: - A GIS with all these data - Building a database (sqlite or postgres/postgis/ on NAS) - An excellent organization of the data - To enable access to data with other software (such as QGIS and gvSIG) GRASS 7 will default SQLite and therefore should be different to GRASS 6. In the sense that now GRASS 6 connects to the DB (postgres and / or sqlite) but works differently than the dbf ... or wrong? SQLite does not have the spatial component as postgis with postgres? What does this? Can you tell me the steps to follow? What do you recommend? Thanks Gabriele -- View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2360247.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ 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] Re: v.generalize for area boundaries?
for v.generalize the bare description.html file is already 250 lines long, so presumably already contains most important info. (although no examples) FWIW, I've cleaned up the existing v.generalize html page by rewriting parts where I thought the meaning could be explained better, as well as spelling corrections and other misc. formatting in trunk, devbr6, and relbr64 (r35984, r35985 and r35986). I'm not familiar at all with the functionality of the module, so examples will take a bit longer to work up. ~ Eric. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.vol.rst problem
Hi Ivan, On Tue, Jan 27, 2009 at 1:43 PM, ivan marchesini marches...@unipg.it wrote: Dear grass users.. I'm working with grass6 devel. Trying to use v.vol.rst with option cellout I have obtained a strange result: The elev 3D map is correctly created (I have seen it by means of nviz) but the cellout map is created as a small map (like a miniature of the map that I would expect) that is placed at the up-left corner of the region.. (I'm using monitors and I haven't MASK in my mapset). The remaining part of the cellout map has only values = 0. this is strange - I am using v.vol.rst regularly and do not observe such a problem. What was the command line? I think I can obtain the same thing using r3.cross.rast starting from the elev map created from v.vol.rst, but: could the problem I have found be a little bug? or it is a problem o f zmult or wmult (but the resolution is the same along the x,y,z directions...) please tell us how you launched it (preferably a North Carolina example to be able to replicate it) Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 7 and SQLITE o POSTGRES
On 21/02/09 14:25, Gabriele N. wrote: Hi Moritz. I have read here http://grass.osgeo.org/wiki/GRASS_7_ideas_collection Database establish SQLite as default DBMI driver (DBF is too limited). done May 2008. That's because I thought that SQLite support in GRASS 7 concerns the attribute management and the geometries. No, only attribute management. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: improve v.rast.stats speed?
I'm out of office. When I'll be back I shall summerize the various proposals and try to make some benchmark on my dataset. The first thing is to make a cleaner distinction between the various stats commands. Thanks for all the contributions! 2009/2/21, Nikos Alexandris nikos.alexand...@felis.uni-freiburg.de: On Sat, 2009-02-21 at 09:20 +0100, Markus Metz wrote: Hamish wrote: Jose Gómez-Dans wrote: My take on this is to rasterize my vector data with gdal_rasterize (you can have a look at the rasterisation code and see how it works, in case you need to eg buffer your vector data), load it up in python, load my dataset in python, and calculate whatever stats with scipy+numpy. If you look at this thread, you'll find it is very fast: http://article.gmane.org/gmane.comp.python.scientific.user/19412. numpy is already requested by the new wxGUI*, so with numpy around anyway, maybe some python module could be written for grass7, where python is a full dependency? * see gui/wxpython/gui_modules/profile.py I think too that grass should provide a reasonably fast way to get this kind of stats. You can still devise your own solution if you want, but IMHO grass must be able to do this job reasonably fast and user-friendly. Taking the risk of becoming annoying: with r.univar.zonal, everything could be done in one pass: rasterize vector, no need for mapcalc, run r.univar.zonal once (which itself needs only one pass), load stats to attribute table, done. With the example that started this thread, everything should be completed in very few minutes. Rasterizing the vector might take the longest. Anyway, when it comes to processing time, I'm a speed junky, and 5 hours is simply unacceptable if it can also be done in minutes or even seconds, and grass should do that, not forcing users to come up with their own workarounds for something that grass is supposed to do. Markus M +1 (from an end-user :: I had to do my workaround once) -- Inviato dal mio dispositivo mobile ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] improve v.rast.stats speed?
Dylan: OK. This is the old stable branch (I think). If you can get 2.0 to compile I would suggest trying that. Dylan, which one is 2.0 for linux? Can't trace it. Thanks, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] improve v.rast.stats speed?
On Sat, Feb 21, 2009 at 11:19 PM, Nikos Alexandris nikos.alexand...@felis.uni-freiburg.de wrote: Dylan: OK. This is the old stable branch (I think). If you can get 2.0 to compile I would suggest trying that. Dylan, which one is 2.0 for linux? Can't trace it. He meant Starspan. but I don't see a 2.x version: http://starspan.casil.ucdavis.edu/doku/doku.php?id=download ? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] improve v.rast.stats speed?
On Sat, 2009-02-21 at 23:53 +0100, Markus Neteler wrote: On Sat, Feb 21, 2009 at 11:19 PM, Nikos Alexandris nikos.alexand...@felis.uni-freiburg.de wrote: Dylan: OK. This is the old stable branch (I think). If you can get 2.0 to compile I would suggest trying that. Dylan, which one is 2.0 for linux? Can't trace it. He meant Starspan. but I don't see a 2.x version: http://starspan.casil.ucdavis.edu/doku/doku.php?id=download ? Markus Exactly. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Long post - Remote Sensing - Classifications
Hi, it's in Raster - Manage map colors - Create RGB there was a wish a while ago to build a menu tree for the commands, not sure if it went anywhere. Maybe something could be built into tools/module_synopsis.sh (add a line of text under each module descr with italicized a-b-c menu location?) todo. hmmm... MODULE=r.composite xml2 gui/wxpython/xml/menudata.xml | grep -B5000 $MODULE | \ sed -e 's+^/menudata/menubar/menu/++' | tac | \ grep '/label=\|^label=' | grep -B1000 '^label=' -m 1 | ... ? may have to call in awk.. ..thanks, Moritz told me where to find it...my bad! if you know it's there but can't find it, what hope does a new user have of learning that it exists? It indicates a non-intuitive placement or where the label could be improved. This sort of feedback is rather valuable IMO. mitch: I'm generally familiar with getting to know new GIS sw and new GUIs..that was my bad (probably not too much attention). Commercial sw give you the possibility to save your visualization once loaded (menu file-save as...and stuff like that)...d.rast doesn't. Maybe I was expecting to find composite as a key word in a first level menu rather that Create RGB in a second level...but again, I wasn't paying too much attention. Once you start understanding that in the GRASS GUI you have to look for a word related to the module, you've got it (i.*it's got to be in that Imagery menu somewhere, doesn't it?) I have to be honest though, the amount of mickeys using GRASS is pretty relevant but, giving its CL nature (virtually everything could be done just typing), this comment doesn't really make sense (unless the direction is really toward a usable GUI as I read in a paper somewhere). Hamish: I would say mitigated not corrected. The imagery modules generally still don't like to look at maps in @othermapsets, and generally don't like @currentmapset tacked on map names either. But hopefully it breaks less now and exits with an understandable error message. The imagery libs need some TLC. Are you saying that it's not a matter of version? no. it should be better in 6.4. Just that even with the new fixes the imagery modules (library) are still not as solid as the raster modules in this regard. Would I have the same problem with the 6.4? I don't know. Hopefully it is fixed, but it might not be. (feedback from users is really the only way to know) I'm sure it doesn't work when I copy the images in the user mapset... would that work working in PERMANENT? try with the imagery maps in the same mapset. perhaps with the maps in PERMANENT you don't need @mapset (it's in the search path), so it would be ok. shrug. I did try to include the images in the group using the graphic way but deleting (in the box) @mapset...no luck. you can look in the $MAPSET/groups/ files too, they are just plain text. for all of the above -- mitch: I installed 6.4 0rc3 and the I realized that for a couple of times unsupervised was working entering @user and using permanent as a pool. Then, same thing (unable to find the signature file...when all the files are there in the group!). So I entered @permanent and worked there...fine (I still don't understand the inconsistency). I entered @user, copied the images and it worked. BTW I used only the GUI (I was testing it) so, a bunch of double clicks generating a bunch of @here and @there in the file naming...that wasn't the problem (at least in my case). But still, how about the Supervised? Wouldn't that work and tell me that THERE IS a sub-group since I used it (the one created via command) for the Usupervised? (I tried to create another group -- via command -- and run the i.class but when I have to define the subgroup...nothing!..it doesn't find it. I don't work with any of the classification stuff, so am not really familiar with them, but if you can recreate the problem(s) from the command line, using the North Carolina or Spearfish sample datasets, please post the commands to trigger it to the bug tracker and we can try and reproduce it at our end. mitch: supervised...oh man, my black ship :-) from GUI it seemed to be working the first time: OPTION: Name of raster map to be displayed key: map format: name required: YES Enter the name of an existing raster file Enter 'list' for a list of existing raster files Hit RETURN to cancel request lsat7_2002_40 lsat7_2002_40 OPTION: Name of input imagery group key: group format: name required: YES Enter the name of an existing group file Enter 'list' for a list of existing group files Hit RETURN to cancel request landsuper landsuper OPTION: Name of input imagery subgroup key: subgroup format: name required: YES enter option landsuper You have chosen: subgroup=landsuper Is this correct? (y/n) [y] OPTION: File to contain result signatures key: outsig format: name required: YES Enter a new output file name Hit RETURN to cancel request land_sup_class land_sup_class
Re: [GRASS-user] Long post - Remote Sensing - Classifications
Hamish wrote: [finding r.composite] mitch_TX wrote: it's in Raster - Manage map colors - Create RGB there was a wish a while ago to build a menu tree for the commands, not sure if it went anywhere. Maybe something could be built into tools/module_synopsis.sh (add a line of text under each module descr with italicized a-b-c menu location?) todo. hmmm... MODULE=r.composite xml2 gui/wxpython/xml/menudata.xml | grep -B5000 $MODULE | \ sed -e 's+^/menudata/menubar/menu/++' | tac | \ grep '/label=\|^label=' | grep -B1000 '^label=' -m 1 | ... ? may have to call in awk.. I don't know what you're trying to do, but I'm 95% certain that it would be easier to do it in Python, probably by cannibalising gui/wxpython/gui_modules/menudata.py. -- 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] Long post - Remote Sensing - Classifications
Oh man...you guys have to excuse me...I've just started the wxpython GUI and it looks pretty cool =)..so, forget all I posted before and let me try it. I'll maybe solve my problems...thanks. Sorry again, mitch Glynn Clements wrote: Hamish wrote: [finding r.composite] mitch_TX wrote: it's in Raster - Manage map colors - Create RGB there was a wish a while ago to build a menu tree for the commands, not sure if it went anywhere. Maybe something could be built into tools/module_synopsis.sh (add a line of text under each module descr with italicized a-b-c menu location?) todo. hmmm... MODULE=r.composite xml2 gui/wxpython/xml/menudata.xml | grep -B5000 $MODULE | \ sed -e 's+^/menudata/menubar/menu/++' | tac | \ grep '/label=\|^label=' | grep -B1000 '^label=' -m 1 | ... ? may have to call in awk.. I don't know what you're trying to do, but I'm 95% certain that it would be easier to do it in Python, probably by cannibalising gui/wxpython/gui_modules/menudata.py. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://n2.nabble.com/Long-post---Remote-Sensing---Classifications-tp2347807p2366095.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.generalize for area boundaries?
Eric: FWIW, I've cleaned up the existing v.generalize html page by rewriting parts where I thought the meaning could be explained better, as well as spelling corrections and other misc. formatting I'm not familiar at all with the functionality of the module, so examples will take a bit longer to work up. I've imported the tutorial into the wiki: http://grass.osgeo.org/wiki/V.generalize_tutorial a number of examples are given there. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
