Re: [GRASS-user] Mouse button functions in Grass 7
Martin Landa wrote: I can't find any info in the v.digit docs about what the mouse buttons actually do when digitizing - any hints? I guess you are speaking about wx vector digitizer... left - select / deselect features middle - cancel action right - confirm action Martin Thanks; I updated the wx vector digitizer docs in trunk and grass6_devel. -- Eric Patton ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Can this be done in GRASS
On Friday 22 May 2009, william told wrote: Hi, the attached 3D image I believe was generated by software. I was wondering is someone could tell me if there is a way to create something similar with GRASS, out of shapefiles (or do I need something more, like an aerial photo?) Many thanks Bill Hi, Looks like some kind of thematic map, draped over an elevation surface, with a vector representation of a river system on the right-side. This is not at all difficult to do in GRASS, you just need some data first. Do you have 1. thematic data in raster / vector format? 2. data sufficient to generate an elevation surface, or a DEM? 3. hydrologic data in raster / vector format? Once you have these things, all in the same coordinate system- planar if possible, bring them into a grass mapset (see the manual). You can generate perspectives like the attached image with a tool called 'nviz'. Here is an example, using a DEM, aerial photo, and 3D tree objects (see the GRASS add-ons page): http://169.237.35.250/~dylan/temp/pinn_trees_rnd.jpg Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.label.sa out of memory on small vector map.
I have just started playing with v.label.sa in GRASS 6.5-svn (last updated yesterday). I had success in getting it to process one fairly large map of US Forest Service trail data, but had it run out of memory on a similar map from the same source of road data. Even trying to run it on a very small subset (40 lines) of the road data in my area of interest gets an out-of-memory error as the size of v.label.sa grows to more than 1GB. Here's what I've done: Download Current Trails Inventory and Current Roads Inventory from http://www.fs.fed.us/r3/cibola/plan-revision/gis_data/data.shtml These are Zipped shapefile sets. I imported into a NAD83, UTM zone 13 region (EPSG:26913) using v.in.ogr without problem. I imported Trail_Route.shp as trails2008 and Road_Route.shp as usfs_roads2008. This works: v.label.sa map=trails2008 column=TRL_NO labels=trails2008 font=VeraSe It doesn't produce the lovliest of labels, but runs in small memory and in reasonable time. But this fails with a memory allocation error, after chewing a long time: v.label.sa map=usfs_roads2008 column=RTE_NO labels=roads2008 font=Vera usfs_roads2008 contains 6203 lines, so I tried to restrict my consideration to the area I actually want to make a paper map of. g.region -p projection: 1 (UTM) zone: 13 datum: nad83 ellipsoid: grs80 north: 3883362.61697134 south: 3877081.62443534 west: 373147.02714574 east: 380581.87668613 nsres: 2.4382735 ewres: 2.43845508 rows: 2576 cols: 3049 cells: 7854224 v.in.region output=tmpreg v.select ainput=usfs_roads2008 binput=tmpreg output=trnngroads operator=overlap v.info trnngroads ++ | Layer: trnngroads| | Mapset: PERMANENT | | Location:NewMexico | | Database:/users/russo/GIS | | Title: | | Map scale: 1:1 | | Map format: native| | Name of creator: russo | | Organization: | | Source date: Tue May 26 10:30:59 2009 | || | Type of Map: vector (level: 2) | || | Number of points: 0 Number of areas: 0 | | Number of lines:40 Number of islands:0 | | Number of boundaries: 0 Number of faces: 0 | | Number of centroids:0 Number of kernels:0 | || | Map is 3D: No | | Number of dblinks: 1| || | Projection: x,y (zone 0) | | N: 3940710.738S: 3846467.585 | | E:678499.548W:132270.347 | || | Digitization threshold: 0| | Comments:| || ++ But v.label.sa still gets a memory allocation error on this: Initialising labels... 100% Generating label candidates: ... 100% 51% At this point, top shows v.label.sa starting to grow tremendously, rapidly getting to 200M, gradually growing to 1000M. This only happens with this particular data set. What could make v.label.sa grow so much on a map with only 40 lines? -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM In some cultures what I do would be considered normal. -- Ineffective daily affirmation ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] /usr/lib/grass/scripts/r.in.wms: line 439: /usr/lib/grass/etc/r.in.wms/r.in.gdalwarp: Argument list too long
Hi All, I was starting a project that needed a lot of srtms. So I though: Let's use the WMS! there I went, set region: GRASS 6.2.3 (prominence):~/gis g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 13N south: 56S west: 82W east: 34W nsres: 0:00:03 ewres: 0:00:03 rows: 82800 cols: 57600 cells: 476928 then get the files: GRASS 6.2.3 (prominence):~/gis r.in.wms output=srtm.jpl mapserver=http://wms.jpl.nasa.gov/wms.cgi layers=huemapped_srtm so, 4673 GTIFF files later, I got this error: /usr/lib/grass/scripts/r.in.wms: line 439: /usr/lib/grass/etc/r.in.wms/r.in.gdalwarp: Argument list too long now the qiestions: 1. what happened? 2. how to overcome this? I have thought to manually join all 4673 files, but then there has to be a (much) better way. I am open to suggestions. -- Paulo Marcondes = PU1/PU2PIX -22.915 -43.224 = GG87jc = Corrected ! -23.578 -46.671 = GG66pk ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass-python scripting error
Milton Cezar Ribeiro wrote: and I need to compile the grass (or grass.py) again, or is just update this file with newst one?! You don't need to compile anything; just update the file. -- 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] Generate DEM with point and line vector
leonidas wrote: I need to generate a DEM using a line vector file (contours, step=20m, some are disjoined) and also combine a second point vector file with heights.How can I achieve that with Grass? v.to.rast + r.surf.contour In the contours file there is also the coastline (height=0).Will that produce any error? yes, please read the r.surf.contour help page carefully about that. the quick workaround is to use r.mapcalc to multiply your raster input with: r.mapcalc contline_mult = (contlines*10)+1 then run r.surf.contour then reverse the above multiplication: r.mapcalc dem = (contour_dem -1) / 10 besides that pain r.surf.contour does a really nice job. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error in ps.map scalebar units argument
Ahh no units option in my grass version: /250k_layout.map + REGION=surigao_test_reg + TITLE=SURIGAO + PCGS=2535 + g.region region=surigao_test_reg res=100 + ps.map out=surigao_test_reg.ps where x y length length height height segment no_segemnts numbers no_labels fontsize fontsize background [Y|n] enter 'end' when done, 'exit' to quit + echo 'finished generating postscript map of SURIGAO' finished generating postscript map of SURIGAO [Raster MASK present] I'll try a new grass version then. On Tue, May 26, 2009 at 7:35 PM, Hamish hamis...@yahoo.com wrote: maning wrote: GRASS 6.4.svn ERROR: units kilometers : illegal request (scalebar) that indicates it doesn't understand units (as opposed to km,miles,etc qualifier being bad). I don't know why it doesn't work for you. can you try putting in your script: scalebar s help exit end end and see if units auto|meters|kilometers|feet|miles|nautmiles is there in the output? All I can suggest is to 'make clean', 'svn update' to the latest 6.4svn (checking for 'C'onflicts), and rebuild. And make sure there are no invisible non-ascii chars instead of spaces or tabs on that line.. but I doubt that. can you email me the script or check with a hexdump program? worst come to worst you can add the kilometers text in with the text x% y% command by hand, then open the PS file in your favourite industrial strength text editor and search for the ZB (1) PB, (2), (3) m text and edit them to be like (10) (20) (30). [a wonderful trick for quickly fixing typos in the hardcopy] That should be pretty much near the end of the file. ???, Hamish -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error in ps.map scalebar units argument
Hi all, Any idea about how to change the default browser for GRASS help in the OSGeo4W GRASS package. best Venka ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] /usr/lib/grass/scripts/r.in.wms: line 439: /usr/lib/grass/etc/r.in.wms/r.in.gdalwarp: Argument list too long
On Wed, May 27, 2009 at 12:49 AM, Paulo 'Pmarc' Marcondes pmarc.deb...@gmail.com wrote: Hi All, I was starting a project that needed a lot of srtms. So I though: Let's use the WMS! there I went, set region: GRASS 6.2.3 (prominence):~/gis g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 13N south: 56S west: 82W east: 34W nsres: 0:00:03 ewres: 0:00:03 rows: 82800 cols: 57600 cells: 476928 then get the files: GRASS 6.2.3 (prominence):~/gis r.in.wms output=srtm.jpl mapserver=http://wms.jpl.nasa.gov/wms.cgi layers=huemapped_srtm so, 4673 GTIFF files later, I got this error: /usr/lib/grass/scripts/r.in.wms: line 439: /usr/lib/grass/etc/r.in.wms/r.in.gdalwarp: Argument list too long now the qiestions: 1. what happened? 2. how to overcome this? I have thought to manually join all 4673 files, but then there has to be a (much) better way. I am open to suggestions. This problem came up last year( in a different context): On Mon, Oct 6, 2008 at 11:38 AM, Glynn Clements gl...@gclements.plus.com wrote: On Wed, Sep 24, 2008 at 5:04 PM, Daniel Victoria daniel.victo...@gmail.com wrote: I've bumped into this problem before, with the same error, but outside GRASS. Which shows that this is not a GRASS bug but a limitation of the operating system. It's more robust to use sysconf(_SC_ARG_MAX), as the limit isn't necessarily fixed at compile time (e.g. it can vary between kernel versions). Also, the limit is divided between argv[] and the environment. If you have a lot of space taken up by environment variables, it will eat into the space available. This can be significant on older systems, where the limit may be as low as 4KiB (a single page of memory). Possible solution: - use r.in.wms from GRASS 7 (written in Python) - amend the script to use shorter filenames - use v.mkgrid and loop over the tiles to download in smaller chunks Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.label.sa out of memory on small vector map.
On Tue, May 26, 2009 at 10:44 PM, Tom Russo ru...@bogodyn.org wrote: I have just started playing with v.label.sa in GRASS 6.5-svn (last updated yesterday). I had success in getting it to process one fairly large map of US Forest Service trail data, but had it run out of memory on a similar map from the same source of road data. Even trying to run it on a very small subset (40 lines) of the road data in my area of interest gets an out-of-memory error as the size of v.label.sa grows to more than 1GB. Can you please use valgrind to check for a memory leak? http://grass.osgeo.org/wiki/GRASS_Debugging#Using_Valgrind CMD=v.label.sa map=usfs_roads2008 column=RTE_NO labels=roads2008 font=Vera valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD --o The result will be long - you may send it offlist to me and I'll extract the relevant part for the list. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error in ps.map scalebar units argument
Venkatesh wrote: Any idea about how to change the default browser for GRASS help in the OSGeo4W GRASS package. does the default work for you? (there is a typo in the current package) see OSGeo4W bug #86 http://trac.osgeo.org/osgeo4w/ticket/86 you need to change the GRASS_HTML_BROWSER variable. http://grass.osgeo.org/grass64/manuals/html64_user/variables.html#enviro to change it to Firefox or whatever edit C:\OSGeo4W\etc\ini\grass.bat and set the full path to firefox.exe instead of iexplore. ie: set GRASS_HTML_BROWSER=%PROGRAMFILES%\Mozilla Firefox\firefox.exe osgeo4w pkg-grass wiki page updated, http://trac.osgeo.org/osgeo4w/wiki/pkg-grass TODO in install script: use firefox if present Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
