[GRASS-dev] r.profile limits in Windows 7
Dear list, due to strange misbehaviours, we are doing some stress tests on r.profile under Grass 6.4 and Windows 7 Case A (less interesting, IMHO): r.profile fails with ERROR: G_malloc when the number of pixel queried is more than 1E6 our test: profile lenght: 300km, res=3 OK, res=2 failure ( example a river analysis on a lidar-derived DTM) Case B (more interesting): r.profile fails when profile input is a string larger than 8100 characters (more or less) I suppose the problem comes from a limit of cmd.exe (8191 characters) see [0] Please, consider that using UTM integer coordinates that means only 300 nodes, and this is not so unusual for profile analysis. Probably, using optionally a text file as profile input could solve the problem without refactoring the module... Could be this bug solved in Grass 7? Hope this helps regards enrico gallo [0] http://support.microsoft.com/kb/830473 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Change/update Python requirements for grass70?
Hi All, On Tue, Feb 11, 2014 at 11:12 PM, Hamish hamis...@yahoo.com wrote: Pietro wrote: So are you agree to change the requirements for grass70 from Python = 2.4 to Python = 2.7 or Python = 2.6? to add another me too for keeping support for python 2.6, Debian/Squeeze: Python 2.6.6 Ubuntu 10.04 LTS: Python 2.6.5 Ok, it seems that we all agree that we should change the requirements from python 2.4 to python 2.6, so I will change the file this afternoon. Best regards. Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2195: Query raster/vectors maps tool fails while saving modified attribute
#2195: Query raster/vectors maps tool fails while saving modified attribute -+-- Reporter: artegion | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI| Version: 6.4.3 Keywords: |Platform: All Cpu: Unspecified | -+-- If the key column is not called cat when saving modified attribute a wrong SQL command is issued UPDATE tablename SET WHERE cat=1; instead UPDATE tablename SET WHERE KEYNAME=1; [[Image(D:\ODBCtest\bug\Capture-2.jpg)]] -- Ticket URL: http://trac.osgeo.org/grass/ticket/2195 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
Salut GRASSers, Moritz Lennert wrote: [..] With all the elements in place, especially with Pietro's recent work, it should be quite easy to create a unifying module 'i.segment.classify' which would take as input - the segments coming out of i.segment - training zones - a choice of variables - a choice of classifier would then calculate the chosen variables, submit the results to the classifier and then update the segment map attribute table with the classification result. In other words a frontend combining v.to.db, v.rast.stats, v.class.ml and possibly some others. As another alternative way, so as to stay in the Raster world, what do you think of simply using r.statistics2 and providing an input cover= map in order to derive segment-oriented statistics and use'm further, for example in an unsupervised classification scheme? Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
Hi, 2014-02-12 13:41 GMT+01:00 Nikos Alexandris n...@nikosalexandris.net: [...] think of simply using r.statistics2 and providing an input cover= map btw, it remembers me that we haven't yet decided about renaming `r.statistics2` and `r.statistics3` to any reasonable name... Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.profile limits in Windows 7
Hello Enrico, please open a trac wish ticket for case A, as it should be possible to sample large datasets as to obtain the result of module it does not require to keep whole data set in RAM. JFYI - one solution would be to share code with v.profile add-on that allows to use a line from existing vector layer as the profiling line. Not exactly solutions but just my 0.02. Maris. 2014-02-12 10:30 GMT+02:00 Enrico Gallo enrico.ga...@gmail.com: Dear list, due to strange misbehaviours, we are doing some stress tests on r.profile under Grass 6.4 and Windows 7 Case A (less interesting, IMHO): r.profile fails with ERROR: G_malloc when the number of pixel queried is more than 1E6 our test: profile lenght: 300km, res=3 OK, res=2 failure ( example a river analysis on a lidar-derived DTM) Case B (more interesting): r.profile fails when profile input is a string larger than 8100 characters (more or less) I suppose the problem comes from a limit of cmd.exe (8191 characters) see [0] Please, consider that using UTM integer coordinates that means only 300 nodes, and this is not so unusual for profile analysis. Probably, using optionally a text file as profile input could solve the problem without refactoring the module... Could be this bug solved in Grass 7? Hope this helps regards enrico gallo [0] http://support.microsoft.com/kb/830473 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] Object-based image classification in GRASS
On Wed, Feb 12, 2014 at 7:42 AM, Martin Landa landa.mar...@gmail.comwrote: Hi, 2014-02-12 13:41 GMT+01:00 Nikos Alexandris n...@nikosalexandris.net: [...] think of simply using r.statistics2 and providing an input cover= map btw, it remembers me that we haven't yet decided about renaming `r.statistics2` and `r.statistics3` to any reasonable name... And they confuses with r.stats and r.univar. And r.univar is the most basic one from these, I would say, and has the most cryptic name. Is the merging (some of) them together still an option? Vaclav Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-user mailing list grass-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] New GRASS for Mac binaries
I still don’t know what has been happening with my attempts to run my own binaries. But following up on thoughts from William and Vaclav, I’m chalking it up to dropbox incomplete syncing. I’ve gone ahead and posted new versions for GRASS 7, GRASS 6.5, and GRASS 6.4 to the web site http://grassmac.wikidot.com/downloads. If anyone cares to try them and let me know, I’d appreciate it. I’m heading out of town but will see if I can test sometime during the trip. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] d.out.file
Hi, I just added the support of exporting image from wxGUI and d.mon through command line. It does not support the advanced options of d.out.file in GRASS 64 (mainly because of different rendering mechanism). Testing (especially in d.mon) is welcome. Related to this, any ideas if wxGUI should support d.erase? And if yes, what should it do? Erase display, uncheck all layers or perhaps remove all layers from the layer tree? The third one seems to be the most useful, at least for me. Best, Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.out.file
Anna wrote: I just added the support of exporting image from wxGUI and d.mon through command line. It does not support the advanced options of d.out.file in GRASS 64 (mainly because of different rendering mechanism). Testing (especially in d.mon) is welcome. Hi Anna, one very useful advanced option of the GRASS 6 d.out.file is the output format geotiff, that way you can compose a scene and export it, then reimport it as a georeferenced RGB image. Do we still have a way of doing that? The quadruple size is problematic for making poster sized output since the grid, barscale, vector line overlays are still exported as 1 px wide, which shrinks to 1/4 the size when you try and export as high quality. The cairo and vector-based output drivers may help, but the main solution I have for that is to encourage people to use ps.map for when they want hi-res hardcopy outputs. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.out.file
On Wed, Feb 12, 2014 at 6:13 PM, Hamish hamis...@yahoo.com wrote: Anna wrote: I just added the support of exporting image from wxGUI and d.mon through command line. It does not support the advanced options of d.out.file in GRASS 64 (mainly because of different rendering mechanism). Testing (especially in d.mon) is welcome. Hi Anna, one very useful advanced option of the GRASS 6 d.out.file is the output format geotiff, that way you can compose a scene and export it, then reimport it as a georeferenced RGB image. Do we still have a way of doing that? No, we don't. Or better say, accoring to the fact that d.out.file is being reintroduced, we don't have the way yet. But my question is: wouldn't be d.out.rast/d.to.rast even better than d.out.file to GeoTIFF with subsequent import and r.composite. d.out.rast/d.to.rast would do the mentioned process automatically. Clearly, there is a place for both and I think I would use both; export as GeoTIFF, referenced PNG, or what ever for use in other applications as well as direct (at least from user point of view) conversion to raster map (for 3D view surface cover). Vaclav The quadruple size is problematic for making poster sized output since the grid, barscale, vector line overlays are still exported as 1 px wide, which shrinks to 1/4 the size when you try and export as high quality. The cairo and vector-based output drivers may help, but the main solution I have for that is to encourage people to use ps.map for when they want hi-res hardcopy outputs. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
