Re: [GRASS-user] face to DEM?
Hello Adam, hope I understood what you mean to do. If I had to cope with your problem, I would import the source file as points, then run v.to.rast, and r.surf.nnbathy with the l interpolation method. The risk for this solution is the triangulation performed by r.surf.nnbathy be different from your source TIN... Good luck, Vincent. Le samedi 14 février 2009 à 16:42 -0800, Adam Dershowitz a écrit : I have some 3-d vector faces. They were defined in a text file like this: F 10 1 2 1 2 2 2 ... ... etc. I imported them into grass like this: v.in.ascii -zn input=faces.txt out=faces format=standard and all seems fine. I can see the faces, and if I click on points around the edges I can get a height as well. I can't figure out how to generate a raster DEM from these faces. Essentially I would like to know the approximate elevation at each raster point inside the faces. I tried v.to.rast but then I get Column parameter missing For v.to.rast3 I get Unable to get layer info for vector map I also tried v.extrude but I see all 0s (ie Number of areas: 0 etc.) Did I do something wrong on my import? Did I miss some other way to do the conversion? I want to be able to do some mapcalcs with the heights of an these faces compared to another raster map, but I can't figure out how to convert these faces to something that I can work with. Thanks much, --Adam ___ 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] archaeologist GRASS users - was Thiessen Polygons
Benjamin Ducke a écrit : Hi Lyle, see this presentation for some case studies: ftp://88.208.250.116/ducke-frankfurt-foss-gis-arch.pdf The Xtent model shown there might be what you are looking for (essentially another way to get weighted Voronoi diagrams). I am sure Michael Barton could point you to other cool stuff that he and his students/colleagues have been doing with GRASS. Maybe we should set up a GRASS for Archaeology user group and/or web page some time. CAA 2009 might be a good pretext for that. Cheers, Ben Hi Benjamin, could you point me to some explanations of this xtent model and how to use it in grass ? Date: Thu, 12 Feb 2009 17:54:07 -0500 From: Lyle E. Browning lebrown...@att.net The messages from Kurt Spring and Jean Roc Morreale point to archaeological work using GRASS. How many other archaeologists are there on the list using GRASS. I'd be interested in hearing about archaeological applications as I have just begun the learning curve for my own archaeological work. Thanks, Lyle Browning In France, even if it has been teach in the mid'90s there is now only an handful of people using GRASS. The main sofwares used are MapInfo and Arcgis, with gvsig being the new frontend to the gov archeological register. GIS are used to study the repartition of the material and sites, the relation between sites and mainly the production of maps. The volumetric's abilities of GRASS would often be a godsend but too few knows about it. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Glynn Clements wrote: Jan Hartmann wrote: With that in mind, if the algorithm you propose would be indeed an approximation to weighted Voronoi polygons, *and* it wouldn't be all to hard to implement (I have no idea about that), would it make sense to propose this as a new RFC for GRASS? Oops; I spoke too soon. In retrospect, this won't work. r.grow.distance relies upon the fact that once a cell falls out of consideration, it stays out. It will only consider cells which either are from the current row, or were used on the previous row. With distance scaling, this doesn't hold. A cell could be temporarily overriden by much nearer cells with increased scale factors (lower weights), then regain its influence once the distance increases. IOW, this isn't something which can implemented given the algorithm used by r.grow.distance. Any algorithm which implemented distance scaling would inevitably have worst-case memory usage proportional to the number of non-null input cells, as you can never forget a cell whose scale factor is lower than those currently being considered, as it will eventually regain its influence. Do you mean that implementing a raster version of weighted Voronoi methods would be very inefficient, compared to vector methods, or that it would be very difficult? I have tried to see what's in the ArcGIS extension (http://portal.acm.org/citation.cfm?id=1332465, documentation at: http://www.geog.unt.edu/~pdong/software/VoronoiHelp.pdf), but the math is beyond me. If you think it would be viable to implement this in GRASS, I could have a closer look at it. These weighted Voronoi polygons are really an interesting methodology. Jan Hartmann Departmann of Geography University of Amsterdam ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] wxpython: vdigit crash
Hi My problem with wxpython vdigit crashing was solved by deleting the symbolic link to: /usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so This symbolic link was created during the early days of vdigit when it was listed as a requirement. I have noticed another user [1] apparently caught by the same gotcha. Regards Craig [1] http://permalink.gmane.org/gmane.comp.gis.grass.user/28008 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] edges in basin map from r.watershed
IMO the esri term of a filled DEM being hydrologically correct is a misnomer. Natural terrain has real depressions that impact surface water flow. Big depressional wetlands can retain water and release via groundwater or evapotranspiration. I like how r.watershed acomodates known depressions and handles the flow as interception. Also, then one can use other tools to find problematic areas in a raw DEM. I modeled an internally drained basin using known depressions in GRASS, and it worked fantastic. One problematic example for esri is modeling an internally drained or sink-watershed. These have no surface water outlet. If one filled it to get flow out of a 9 sq. mile watershed, the esri analyses are then meaningless. Which is one reason why filling a dem just to get an esri module to work and calling the DEM hydrologically correct is a misnomer an a limitation. Mark On Feb 13, 2009, at 11:09 AM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Christian Schwartze wrote: Dear GRASS users, with r.watershed I get strange basin boundaries for some areas und I'm not able to give account of it. Attached you can find that part of the basin map which looks curiously. I means the sharp-edged regions... Whats the reason? This is most probably a flat area (no slope). Flow direction, flow accumulation, stream segments and basins can not reasonably be calculated for flat areas, these are regarded as missing information and some assumption has been made by the algorithm. What could help is to use a raster DEM as input that is *not* filled, some would say not hydrologically correct, but r.watershed works better with the raw, not filled DEM. What could also help, if this does not work or it really is a flat area, is r.watershed of grass7 with multiple flow direction. Note that the result may look nicer, but it still holds true that drainage direction (and therefore all other output) has to be estimated for flat areas. The A * Search of r.watershed is doing a pretty good job, and multiple flow accumulation can improve it a bit more, within limits. Basis is an Arc Info .adf raster file for DEM data. I think Arc Info wants a depressionless, filled, hydrologically correct DEM. r.watershed does explicitely not want such a DEM, it wants a raw DEM with depressions, not filled, and not hydrologically correct. I hope that helps, Markus M ___ 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] wxpython: vdigit crash
Hi, 2009/2/15 Craig Leat craig.l...@gmail.com: My problem with wxpython vdigit crashing was solved by deleting the symbolic link to: /usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so This symbolic link was created during the early days of vdigit when it was listed as a requirement. I have noticed another user [1] apparently caught by the same gotcha. I was thinking about that. Too all wxGUI users - symlink to _gdi.so is not needed for = 6.4.0RC3. Please remove existing symlink to avoid crashing of wxvdigit... Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] ERROR geonames_features
Dear grass user,
It may be a silly error but it is confusing me. I will be very glad if you
could help.
I am learning GRASS GIS from Open source gis a grass gis approach book.
This a an excellent book for the beginners.
I am using winGRASS 6.3.0.4 native version and running nc_spm 0...@permanent.
I have executed the following comand:
r.contour elevation out=elev_contour_m step=3 min=55 max=154
it is giving following error:
BMI-DBF driver error:
SQL parser error: syntax error, unexpected NAME, expecting '(' processing
'geonames_features'
in statement:
create table database geonames_features.elev_contour_m ( cat integer,
level double precision )
Error in db_execute_immediate()
Unable to create table: create table database
geonames_features.elev_contour_m ( cat integer, level double precision )
then I have run the following steps:
- db.connect
- db.connect driver=dbf
{database=$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/} {schema=database
geonames_features}
- I want to remove the schema=database geonames_features ; because i think
it is creating problem
- I have deleted from txtbox and execute db.connect driver=dbf
{database=$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/}
- but when again I open db.connect window it shows schema=database
geonames_features
- How can I remove it.
best
Md. Zahid Parvez
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problemas con winGRASS 6.4.0RC3 del instalador OSGeo4W
I confirm that error on old latlong location (created over 1 years ago, I didn't use it since that time) due to this error gis.m cannot start, but grass still working in the text mode Addational masage in text console are: Error in startup script: can't read monitor_zooms(1,1,n): no such variable while executing lappend region $monitor_zooms($mon,1,$attr) (procedure MapCanvas::currentzoom line 15) invoked from within MapCanvas::currentzoom $mon (procedure MapCanvas::coordconv line 23) invoked from within MapCanvas::coordconv $mon (procedure MapCanvas::create line 68) invoked from within MapCanvas::create (procedure Gm::startmon line 11) invoked from within Gm::startmon (procedure Gm::create line 79) invoked from within Gm::create (procedure main line 30) invoked from within main $argc $argv (file /usr/local/grass-6.4.svn/etc/gm/gm.tcl line 566) Jarek Marilena Yeguez pisze: Saludos, me anime a descargar el instalador OSGeo4W que trae GRASS para Windows entre muchas otras cosas, tal como me recomendaron. Lo instalé y al abrir GRASS me dio un error al no estar predefinido el directorio de datos, estuve revisando a ver si encontraba una carpeta que el instalador creara para tal fin, pero no la halle, realmente la crea?...Decidí crear mi propio directorio, copie una locación de prueba, pero GRASS me arroja el siguiente error: Erro setting region (Problem with g.region?): child lilled:unknown signal Agradezco a quien pueda ayudarme... Marilena Get news, entertainment and everything you care about at Live.com. Check it out! http://www.live.com/getstarted.aspx Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us ___ 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] binary 7.0 or 6.4 wingrass
Thanks for all, miltinho 2009/2/15 Markus Neteler nete...@osgeo.org On Sun, Feb 15, 2009 at 4:27 AM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear Alex On http://grass.osgeo.org/download/index.php I can find only binaries for MacOSX and Linux (for 6.4). I have linked the OSGeo4W installer now. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problemas con winGRASS 6.4.0RC3 del instalador OSGeo4W
On Sun, Feb 15, 2009 at 8:41 PM, Jarek Jasiewicz jar...@amu.edu.pl wrote: I confirm that error on old latlong location (created over 1 years ago, I didn't use it since that time) due to this error gis.m cannot start, but grass still working in the text mode Addational masage in text console are: Error in startup script: can't read monitor_zooms(1,1,n): no such variable while executing This is typically a GDAL problem. What does g.region -p say? Please test this since you can use GRASS in text mode. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Jan Hartmann wrote: With that in mind, if the algorithm you propose would be indeed an approximation to weighted Voronoi polygons, *and* it wouldn't be all to hard to implement (I have no idea about that), would it make sense to propose this as a new RFC for GRASS? Oops; I spoke too soon. In retrospect, this won't work. r.grow.distance relies upon the fact that once a cell falls out of consideration, it stays out. It will only consider cells which either are from the current row, or were used on the previous row. With distance scaling, this doesn't hold. A cell could be temporarily overriden by much nearer cells with increased scale factors (lower weights), then regain its influence once the distance increases. IOW, this isn't something which can implemented given the algorithm used by r.grow.distance. Any algorithm which implemented distance scaling would inevitably have worst-case memory usage proportional to the number of non-null input cells, as you can never forget a cell whose scale factor is lower than those currently being considered, as it will eventually regain its influence. Do you mean that implementing a raster version of weighted Voronoi methods would be very inefficient, compared to vector methods, or that it would be very difficult? I mean only that it cannot be done using the approach which r.grow.distance uses, using memory proportional to the number of columns (it uses a number of row buffers, i.e. one-dimensional arrays, with one element per column). [In any case, weighted distances won't produce polygons; at least, not for Euclidean distances. The boundary will only be a straight line if the weights are equal.] However, that doesn't meant that other algorithms wouldn't be feasible, particularly if you're only interested in typical behaviour rather than worst-case behaviour. Also, it may be possible to use the r.grow.distance approach with something other than scaling. An offset would work, optionally combined with a monotonic function of the distance (provided that it's the same for every point). -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] sample bash script for multiple mapsets
In a single script I would like to: open a mapset and do vector processing, then, open another mapset, import vectors from previous mapset continue processing. Any psuedoscript to do this? -- 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] sample bash script for multiple mapsets
maning sambale wrote: In a single script I would like to: open a mapset and do vector processing, then, open another mapset, import vectors from previous mapset continue processing. Any psuedoscript to do this? is it all in the same location? if so you can use g.mapset (no s) to change the current mapset, then refer to other mapset maps as mapn...@othermapset. (imagery modules need work here) no need to import anything. if not you could still use g.mapset to change the location, but it is probably safer/more sane to use GRASS_BATCH_JOB to drive the process to leave restart GRASS in the new location and run v.proj, maybe with another script to drive the overall job. will the g.gui GUI be needed? that might complicate things for g.mapset. TODO: finish script to create a new location with command line params from outside of GRASS (See thread from ~2 weeks ago) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] mossy grass seeds
Hi, Inspired by Benjamin's rather nice OS/archaeology presentation[1] I was reading a piece[2] by Carl Reed (CTO of the OGC) about his work on MOSS GIS from the late 70s - early 80s while at the US FWS. MOSS was a vector GIS [and Carl claims the first interactive user GIS] early GRASS [several years later, but there was some overlap] was primarily a raster GIS so I don't think there would be much code overlap*. None the less, the two names demonstrate a clear influence in the tradition of pine/elm, pico/nano, less/more and certain ideas+terminology seem to be inherited such as mapsets. [1] ftp://88.208.250.116/ducke-frankfurt-foss-gis-arch.pdf [2] http://www.scribd.com/cnreed [*] but v.out.moss in GRASS 5 was written by MOSS developers, maybe some SDTS stuff too? just curious: was GRASS just cheeky naming by a competing US Gov't GIS team or was there tangled roots in the early days? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] mossy grass seeds
On Mon, Feb 16, 2009 at 8:38 AM, Hamish hamis...@yahoo.com wrote: ... just curious: was GRASS just cheeky naming by a competing US Gov't GIS team or was there tangled roots in the early days? Here are some pointers: http://grass.osgeo.org/devel/grasshist.html * GRASS History I: Lynn Van Warren recalls the design of Fort Hood GIS software design that lead to GRASS development * GRASS History II: GRASS Roots by Jim Westervelt (In Proc. Free/Libre and Open Source Software for Geoinformatics: GIS-GRASS Users Conference 2004, Sept. 12-14, Bangkok, Thailand, 2004) * GRASS History III: Early GRASS Community Views on FOSS by Jim Westervelt (Keynote at FOSS4G2006, 11-15 September 2006, Lausanne, Switzerland) cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
