Re: [GRASS-user] r.watershed multi flow direction
I believe that MFD in r.watershed is in versions 6.5 and up. Mark On Fri, May 21, 2010 at 7:27 AM, Kristian Foerster k.foers...@tu-bs.de wrote: Hi, I am using GRASS 6.4.0RC5+39438 (downloaded from svn server). I would like to obtain basins and stream segments from digital elevation data using the multi flow option in r.watershed as proposed in the documentation. The installed version of r.watershed obviously doesn't support this feature: Sorry, f is not a valid flag Sorry, convergence is not a valid parameter Is there another version of the program available supporting this function? Thank you in advance, best regards, Kristian Förster ___ 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] TopoFlow and GRASS (or any continuous distributed hydrologic model)
r.gwflow can help with the groundwater flow. The r.watershed module can help with where streams in basins originate and go to the outlet. The add-on of r.stream.extract can use weighting parameters to adjust where the streams start (eg. increase accumulation in wet areas, decrease accumulation in dry, and montgomery's exponent for adjusting accumulation thresholds to have more streams in steep areas or flat areas). These modules will help illustrate where streams begin based on contributing area/accumulation. The USGS gauging stations are a good way to validate your model. For long term, or rain-fall event orientated analysis, r.water.sim seems applicable. It will output depths and discharge rates based on rainfall and other input parameters. Validating these simulation results seems reasonable if you have real time data for a given rain event with corresponding discharge rates or depths at stations in the watershed of interest. I have not looked at the HydroFOSS as an addon, but it indicates it factors in evapotranspiration. http://www.foss4g2006.org/contributionDisplay.py?contribId=157sessionId=40confId=1 Good luck and please post back any updates. Mark On Wed, Apr 28, 2010 at 11:28 AM, stephen sefick ssef...@gmail.com wrote: I would like to be able to model groundwater and surface water flow for some particular watersheds with usgs gauging stations. The gauging stations are to help parameterize/validate the modeled discharge. I would then like to be able to try and predict probability of intermittance, or, in other words, where permenant flow starts in the watersheds under investigation. I think that D8 flow algorithm based distributed hydrologic models are the way to do this. If I am wrong I would greatly appreciate this being pointed out. I was wondering if there were any implementations for long-term simulation (I would like to account for different water years). Also, I would like to, at the least, use GRASS as a preprocessor for gridded rainfall and Evapotranspiration time series (along with whatever else may be necessary input data). I have looked into GSSHA, but don't not have the resources for acquiring the WMS software needed to drive the model ($1500), and it looks like TopoFlow for the Colorado CSMDS modelling group would work. If there are any suggestions, comments, or criticisms of my decisions for trying to attack this problem please point them out. Thank you all very much for your wonderful help. kindest regards, Stephen Sefick On Thu, Apr 22, 2010 at 8:54 AM, Rich Shepard rshep...@appl-ecosys.com wrote: On Thu, 22 Apr 2010, stephen sefick wrote: I would like to simulate the hydrology of a watershed. Does anyone have guidance for this particular endeavor- especially with the help of GRASS GIS as a raster processor, or engine for model analysis? There are several hydrologic modules available for your use. The raster manual (r.*) has details on each, and the wiki has a section on hydrological modeling. The question you need to answer in order to get more focused help here is just what it is you want to do. What problem are you trying to solve? What behavior(s) do you want to explore? Specificity, and telling us what you've done so far to educate yourself, goes a long way to helping you. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ 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] DIRECTION
How about v.what.rast ? Mark On Thu, Apr 22, 2010 at 9:39 AM, Sofina Natalia nsof...@gmx.de wrote: Hello everybody ! I would like to compare values for raster and vector points at positions of vector points. Raster is filtered with edge detection function. And as compared value is “direction”. I've created points along input lines in new vector (v.to.points). How can I get now the information about direction in each point for vector map? Many thanks. ___ 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] TopoFlow and GRASS (or any continuous distributed hydrologic model)
For a simulation of a rain event, r.sim.water is pretty advanced. To extract hydrologic features from a raster DEM, there are quite a few tools under Raster--Hydrologic Modeling. The Watershed Analysis (r.watershed) provides a lot of useful outputs. Also, the r.streams.* suite of tools are quite impressive as well, however, those are add-ons. Mark On Thu, Apr 22, 2010 at 9:41 AM, stephen sefick ssef...@gmail.com wrote: I would like to simulate the hydrology of a watershed. Does anyone have guidance for this particular endeavor- especially with the help of GRASS GIS as a raster processor, or engine for model analysis? -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ 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] set region extent to display in wxpython gui
Using tcltk interface, there is a button/dropdown Set computational region extents to match display in the Map Display. What is the comparable command line syntax, and how to set this using the wxpython GUI? Thanks... Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to import .shp and .dbf files???
Are you using v.in.ogr? If so, are you pointing the 'OGR datasource name' to the .shp file? Mark On Thu, Apr 8, 2010 at 7:59 AM, Nadine Jeschke blauba...@gmx.de wrote: Hi to everyone! I´m working with grass 6.3.0 on a ibook and I´d like to import some files with .shp and .dbf format but I always get the report: not recognised as a supported file format Are there some applications missing? Hope somebody can help! thanks!!! Nadine -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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] how to import .shp and .dbf files???
If you are sure the projection of the shapefile matches the projection of the location, you can use the -o option to override that check. Mark On Thu, Apr 8, 2010 at 10:20 AM, Nadine Jeschke blauba...@gmx.de wrote: Hi Mark and António! I´ve tried to use v.in.ogr but it didn´t work. The report says the projection of the dataset ist not identical with the projection of the location Do I have to install GDAL first??? That´s what I found at this page: http://grass.itc.it/grass62/manuals/html62_user/v.in.ogr.html Nadine Am 08.04.2010 um 14:27 schrieb M S: Are you using v.in.ogr? If so, are you pointing the 'OGR datasource name' to the .shp file? Mark On Thu, Apr 8, 2010 at 7:59 AM, Nadine Jeschke blauba...@gmx.de wrote: Hi to everyone! I´m working with grass 6.3.0 on a ibook and I´d like to import some files with .shp and .dbf format but I always get the report: not recognised as a supported file format Are there some applications missing? Hope somebody can help! thanks!!! Nadine -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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] v.lidar.edgedetection -e option
Just installed updated 6.5svn, and the -e option is indeed present. Thanks for the help. Mark On Tue, Apr 6, 2010 at 10:36 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Apr 6, 2010 at 4:26 PM, M S msei...@gmail.com wrote: I'll try updating. It looks like it was installed around February 11. Markus Metz fixed them on Feb 17 :) http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/lidar Cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.lidar.edgedetection -e option
The online documentation for v.lidar.edgedetection show's an -e option to get an estimate of point density ( http://grass.itc.it/grass65/manuals/html65_user/v.lidar.edgedetection.html). In the GUI I don't see the -e option, and when entered at command line it is not recognized. If this option was removed, is there another way to estimate the spacing of a lidar point cloud? GRASS 6.5 Kubuntu 9.10 Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.lidar.edgedetection -e option
I'll try updating. It looks like it was installed around February 11. Much thanks, Mark On Tue, Apr 6, 2010 at 10:17 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Apr 6, 2010 at 3:32 PM, M S msei...@gmail.com wrote: The online documentation for v.lidar.edgedetection show's an -e option to get an estimate of point density ( http://grass.itc.it/grass65/manuals/html65_user/v.lidar.edgedetection.html ). In the GUI I don't see the -e option, and when entered at command line it is not recognized. If this option was removed, is there another way to estimate the spacing of a lidar point cloud? GRASS 6.5 Kubuntu 9.10 Mark, how old is your installation? There was a major important overhaul a few months ago in v.lidar.*. Perhaps you need to update? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] No color for geotiffs exported with r.out.gdal
How about r.out.tiff? Mark On Fri, Apr 2, 2010 at 11:00 AM, William Hudspeth bhudsp...@edac.unm.eduwrote: Hello, I am using GRASS 6.4~rc5-2 on Ubuntu 9.10. I am trying to export a DCELL raster map to both a byte formatted and a UInt16 formatted Geotiff file. The UInt16 formatted file shows nothing when I try to open the file, and the byte formatted file is in black and white only. I can't seem to get color. The original GRASS raster uses the ndvi color scheme. Thanks, Bill ___ 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: 3D lines to raster with elevation
(answering self) v.to.points seems to be a nice solution, as going from 3D line to raster, and capturing Z of line didnt output raster features. Data went from 3D lines, to 3D points (verticies), to raster with Z. On Mon, Mar 29, 2010 at 12:15 PM, M S msei...@gmail.com wrote: Should v.to.rast be able to take a 3D line, and convert to raster with applicable Z values brought over? This command: v.to.rast input=lin...@permanent output=line3d use=z type=line layer=1 rows=4096 --overwrite outputs this: Loading data... Reading features... Writing raster map... Converted areas: 0 of 0 Converted points/lines: 0 of 1 v.to.rast complete. When I query the 3D line in GRASS, it has Z values: Map: line3d Mapset: PERMANENT Type: Line Id: 1 Length: 1619.419511 Line height min: 97.439897 Line height max: 98.149869 Layer: 1 Category: 1 Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 3D lines to raster with elevation
Should v.to.rast be able to take a 3D line, and convert to raster with applicable Z values brought over? This command: v.to.rast input=lin...@permanent output=line3d use=z type=line layer=1 rows=4096 --overwrite outputs this: Loading data... Reading features... Writing raster map... Converted areas: 0 of 0 Converted points/lines: 0 of 1 v.to.rast complete. When I query the 3D line in GRASS, it has Z values: Map: line3d Mapset: PERMANENT Type: Line Id: 1 Length: 1619.419511 Line height min: 97.439897 Line height max: 98.149869 Layer: 1 Category: 1 Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.to.vect Produces Too Many Areas
Since now a vector, can you select and delete those extraneous blocks? Mark On Mon, Feb 22, 2010 at 3:14 PM, Rich Shepard rshep...@appl-ecosys.com wrote: I've done something incorrectly but cannot find what that is. Ran r.water.outlet and produced the output basin map. Then I applied r.null to that map setting nulls to zeros. Next I applied r.to.vect to that map (with the '-s' option) setting feature to area. When I look at the aspect map overlaid by the sub-basin map I see the 5 extraneous cells that should not be there. You can see them on the attached screen shot. This did not happen the last time I used r.water.outlet, and the drainage map does not suggest to me why these 5 cells are included. Help would be appreciated in learning what happened and how to get this tail off the map. Thanks, Rich ___ 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] r.terraflow launch error in 6.5
I haven't, but will. Much thanks! Mark On Wed, Feb 10, 2010 at 11:00 AM, Markus Metz markus.metz.gisw...@googlemail.com wrote: M S wrote: I can launch r.terraflow in GRASS 6.4, but not in 6.5. (on kubuntu 9.10). 6.4 came from ubuntuGIS, which seems fine, however, 6.5 was compiled from source. Error message when launching the GUI is Error - Couldn't execute r.terraflow: no such file or directory. Have you configured --with-cxx ? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.extract - sqlite driver problem
Perfect. Setting the bad point null, and exporting without table or topology (3D) proved to be the fastest solution. Thanks for the suggestion. Much thanks, Mark On Fri, Feb 5, 2010 at 2:27 AM, Hamish hamis...@yahoo.com wrote: Mark: I have a bunch of points (4+ million) with one outlier that needs removed. perhaps use r.mapcalc or r.reclass to filter out the bad point? r.mapcalc clean = if(map 99, null(), map) or r.reclass 99 thru 999 = NULL * = * and finally r.null setnull=bad_value may be the simplest. ... or d.rast.edit ... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.extract - sqlite driver problem
I have a bunch of points (4+ million) with one outlier that needs removed. I created a vector points file by using r.to.vect to create a vector points file and associated table in sqlite. When I run v.extract (v.extract -r input=points...@permanent output=pointsfixed type=point layer=1 list=3884384 new=-1 --overwrite) I get the following error upon writing attributes: Writing attributes... Cannot allocate memory: can't create fork Unable to start driver sqlite Unable to copy table v.extract complete. db.connect -p outputs: driver:sqlite database:$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db schema: group: I'm on Kubuntu 9.10, using GRASS 6.5. Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] outwalk removed from r.sim.water in 6.4 and 6.5?
In GRASS 6.3 there was an output vector map option outwalk for walkers in r.sim.water. http://grass.itc.it/grass63/manuals/html63_user/r.sim.water.html In GRASS 6.4 and 6.5, that output option seems to have gone away. http://grass.itc.it/grass64/manuals/html64_user/r.sim.water.html http://grass.itc.it/grass65/manuals/html65_user/r.sim.water.html Has this feature been removed? Best Regards, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Help with importing points and their attributes
What does 'db.connect -p' show?
Mark
On Tue, Jan 26, 2010 at 9:02 AM, Rebecca Bennett rabenn...@ymail.com wrote:
Dear Sela,
Thank you for your advice. I have re-run the import having corrected the
format as you suggest, using the command below:
v.in.ascii -z -n input=/home/rebecca/lidar/08.txt output=test_08_attribute
format=point {fs= } skip=0 {columns=columns= 'x double precision, y double
precision, z double precision, i double precision'} x=1 y=2 z=3 cat=0
--overwrite
However I now get the error message
DBMI-SQLite driver error:
Unable to open database
/home/rebecca/Documents/Mapping/Grassdata/Salisbury/PERMANENT/sqlite by
driver sqlite
Unable to open database: unable to open database file
Unable to open database
/home/rebecca/Documents/Mapping/Grassdata/Salisbury/PERMANENT/sqlite by
driver sqlite
so it maybe a problem with my database driver rather than the input file? I
have a folder called sqlite but no files within it...
Once again thanks for your help, any more suggestions about how to fix this
are welcome!
Rebecca
--
View this message in context:
http://n2.nabble.com/Help-with-importing-points-and-their-attributes-tp4460359p4460750.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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Help with importing points and their attributes
Looking at mine, the only difference I see is that the name of the database is missing a .db extension. Please let me know if that makes a difference. Mark On Tue, Jan 26, 2010 at 9:09 AM, Rebecca Bennett rabenn...@ymail.com wrote: Hi Mark db.connect -p shows driver:sqlite database:$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite schema: group: Rebecca -- View this message in context: http://n2.nabble.com/Help-with-importing-points-and-their-attributes-tp4460359p4460798.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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS Install Manual
Lubica: Googling shows there are binary GRASS packages for Suse 11.0. Are they visible in your repo(s)? I'm not familiar with the Suse distro enough to give specific package management tools. Mark On Tue, Jan 12, 2010 at 9:41 AM, Rich Shepard rshep...@appl-ecosys.com wrote: On Tue, 12 Jan 2010, Cverckova, Lubica wrote: Is there any manual on how to install GRASS for Open Suse 11.2? Any response will be appreciated. Lubica, Have you considered the usual configure; make; make install? Rich ___ 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] Major update of r.stream.order and r.stream.basins. New module: r.stream.pos
Great updates to already great modules. Thanks for the contribution. I will likely be compiling these in the upcoming week(s). Mark 2010/1/5 Jarosław Jasiewicz jar...@amu.edu.pl: Hi all! A have made major update with r.stream.order and r.stream.basins: r.stream.order new functionality: - it can now create table to store drainage network topology. This table can be added to r.stream.extract vector file. For more details see description.html r.stream.basins new functionality: - much easier stream selection: now we can type only stream categories to create basins. No map algebra is necessary - r.water.outlet functionality added to r.stream.basins (define outlet by coordinates) - definition of outlets by vector point file r.stream.pos this is a helper module for linear geostatistics and local stream properties analysis. Nothing exciting PS. I have a problems with svn repository. If there are some problems with downloading or compiling please let me know, I will try to update as soon as possible. greetings Jarek ___ 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] Re: v.breach addon
Kubuntu 9.10 64bit, using GRASS 6.5. I ran v.breach on a stream network extracted with r.stream.extract. It runs through the program, and puts up an error dialogue at v.parallel. Attached is the log file. It looks like a negative number is being passed to v.parallel. I saw in the documentation this might be a problematic module in the script for non-metric coordinate system. Below is the portion of the output box from the module. Note the error 11 lines down. --- Building topology for vector map breach_pt_segm_2l_r_tmp_5636_0_v_breach_sh... Registering primitives... 100 primitives registered 259 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 100 ERROR: value -0.1 out of range for parameter distance Number of primitives: 100 Number of points: 0 Number of lines: 100 Number of boundaries: 0 Number of centroids: 0 Legal range: 0-1 Description: Creates parallel line to input vector lines. Keywords: vector, geometry --- Should I look in the script for this portion, and check if it is a metric issue? or does this seem like a different problem? Thanks, Mark 2009/12/14 Maciej Sieczka msiec...@sieczka.org: Luís Ferreira pisze: I used v.breach with both SQLite and dbf, with ETRS89 metric negative coordinates, from 20m to 2m resolution and worked fine. System: Ubuntu 9.10 Karmic Koala, 64 bits, GRASS 6.4SVN. But I remember to see some warnings like yours. Are these warnings critical? Visually, the interpolated DEMs with v.surf.rst are coherent. I'll let you know next time I take a hobbyist look at v.breach. But I really don't know when it will be. Good luck. Maciek On Mon, 2009-12-14 at 04:57 +0100, Maciej Sieczka wrote: @Luís: I applied most your of patch. Thanks! Are you sure that's all errors? I keep on getting warnings like: WARNING: Unable to get point on line: cat = 1 offset = 2.831711 (line length = 0) at v.segment calls in the script, and a crash at v.in.ascii. -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user v.breach.log Description: Binary data ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.breach addon
Luis: I noticed you mentioned you had run it with sqlite and dbf database drivers. Mine is mapped to sqlite currently. I see some v.to.db commands in the script, but do I understand correctly that you didnt have issues using sqlite as backend? Thanks, Mark 2009/12/14 Luís Ferreira lferreira7...@gmail.com: I used v.breach with both SQLite and dbf, with ETRS89 metric negative coordinates, from 20m to 2m resolution and worked fine. System: Ubuntu 9.10 Karmic Koala, 64 bits, GRASS 6.4SVN. But I remember to see some warnings like yours. Are these warnings critical? Visually, the interpolated DEMs with v.surf.rst are coherent. Luís On Mon, 2009-12-14 at 04:57 +0100, Maciej Sieczka wrote: @Luís: I applied most your of patch. Thanks! Are you sure that's all errors? I keep on getting warnings like: WARNING: Unable to get point on line: cat = 1 offset = 2.831711 (line length = 0) at v.segment calls in the script, and a crash at v.in.ascii. ___ 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] Hydroligics in grass
Another module that might be applicable is r.sim.water http://grass.itc.it/grass65/manuals/html65_user/r.sim.water.html Mark On Fri, Dec 11, 2009 at 1:44 PM, Joop Goedbloed jlgoedbl...@hetnet.nl wrote: Hi Users on the list To trace back the overland flood mechanism in (sub)urban area I've done some experiments in grass. (Sub)urban areas has in general a sewer-system (combined or storm). One of the design-parameters of a sewer is the maximal capacity of rainfall, in most cases e sewer is design to carry off about 20mm/h rain. In case of very heavy storm about 60 mm/h the sewer becoms full and an overland flood mechanism come into being. I've a 5x5 meter grid DEM of the area. In grass there are several modules to simulate overland flood. * r. terraflow * r.watershed * r.topmodel * r.topidx ... What is the most useful module(s) in grass to simulate overland flood mechanism? First I used the r.terraflow module the resulting accumulation map is here: Terraflow accumulation map Using the r.watershed module resulting streammap is here: Watershed stream map In both maps the red boxes are the complaints of water flood A foto of the real situation is here Foto Thanks Joop Goedbloed ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ 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.breach available?
I downloaded all the grass-addons, and didnt seen v.breach in the directory. I also tried to download it as a specific module and I get a message saying it doesnt exist. svn checkout https://svn.osgeo.org/grass/grass-addons/v.breach grass-addons/v.breach yields... svn: URL 'https://svn.osgeo.org/grass/grass-addons/v.breach' doesn't exist Any suggestions? Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] inverting DEMs
Kind of a odd solution, but would it be possible to use the outputs of r.param.scale to get the classed areas (i.e., peaks, pits, passes, valleys) and then recode them as their opposite? Alternatively, using r.mapcalc, can you multiply all the values by -1? Mark On Sat, Nov 21, 2009 at 9:01 AM, Bulent Arikan bulent.ari...@gmail.com wrote: Hi, I am trying to invert a DEM (i.e., make peaks basins and vice versa) but there does not seem to be a module for this. I am assuming this can be done through ' r.mapcalc ' which I have very limited experience. I also want to get ' r.prominence ' from the Add-ons site but the text file is not downloadable. Should I copy and paste to create a text file that contains the script? Thank you for all the suggestions, -- BÜLENT ARIKAN School of Human Evolution and Social Change Arizona State University Tempe - AZ 85287-2402 ___ 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] matlab scripts r.dominant_dir.m and r.calc_terraflow_dir.m
Thank you for the info. I wound up installing GRASS65 and using MFD in r.watershed. I was looking to those scripts to use MFD in GRASS64. So, in short, I'm good to go. Much thanks, Mark On Wed, Nov 18, 2009 at 4:52 AM, Hamish hamis...@yahoo.com wrote: Mark: I'm looking to use the addon scripts r.dominant_dir.m and r.calc_terraflow_dir.m, however, I have never used Matlab or Freemat. I looked around for some examples or documentation on how to run these scripts for (in?) GRASS, but have not found anything helpful. Can someone point me to a good resource to learn about this? I am not sure how useful those scripts are, they were mostly the result of me exploring some code. but who knows maybe you have a good use for them. Octave is another GPL'd matlab clone. without looking how they work I'd guess r.out.mat was used to save a .mat file which octave could then load. ? the .m script is run by typing the name without the .m from the matlab command prompt. if you are still stuck I can try to find a little time to document them better. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Watershed Area above a certain point
r.water.outlet works well for that. Mark On Wed, Nov 18, 2009 at 3:41 PM, stephen sefick ssef...@gmail.com wrote: I have sampling locations that are located along streams. I would like to generate watersheds above a particular sampling location. How can I do this in GRASS, easily? I have thought of finding the flow accumulation values at the points of interest and then using these values in multiple calls to r.watershed, but this would be increadibly time consuming. Is there a way to do this more automated. thanks, -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ 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] matlab scripts r.dominant_dir.m and r.calc_terraflow_dir.m
I'm looking to use the addon scripts r.dominant_dir.m and r.calc_terraflow_dir.m, however, I have never used Matlab or Freemat. I looked around for some examples or documentation on how to run these scripts for (in?) GRASS, but have not found anything helpful. Can someone point me to a good resource to learn about this? Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.stream.extract - stream dir map output
As an output from r.streams.extract, I'm getting a stream direction map that is only along the stream network, and null everywhere else. From the manual, it seems the direction map needs to be for the entire study area. I am looking to feed the streams and direction map into the r.stream.basins module. Since I'm on GRASS 6.4RC5, I dont have MFD option in my r.watershed, so I rely upon r.stream extract to output the stream network and the direction map. I had seen a portion in the notes stating Nowadays f direction map comes from r.stream.extract must be patched by direction map from r.watershed. (with r.patch). I wouldnt think I could patch the SFD direction output from r.watershed with the MFD stream direction map to create a direction map for the entire study area. Is there another solution to use MFD? Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.stream.extract - stream dir map output
Thanks, I'll give it a shot. Mark 2009/11/16 Markus Metz markus.metz.gisw...@googlemail.com: Jarosław Jasiewicz wrote: M S pisze: As an output from r.streams.extract, I'm getting a stream direction map that is only along the stream network, and null everywhere else. From the manual, it seems the direction map needs to be for the entire study area. I am looking to feed the streams and direction map into the r.stream.basins module. Since I'm on GRASS 6.4RC5, I dont have MFD option in my r.watershed, so I rely upon r.stream extract to output the stream network and the direction map. I had seen a portion in the notes stating Nowadays f direction map comes from r.stream.extract must be patched by direction map from r.watershed. (with r.patch). I wouldnt think I could patch the SFD direction output from r.watershed with the MFD stream direction map to create a direction map for the entire study area. Is there another solution to use MFD? if grass64 really do not have MFD (i'm suprised!) the only solution is to compile grass 65 from source grass64 has MFD in r.terraflow. You can use r.terraflow + r.dominant_dir.m + r.calc_terraflow_dir.m (grass-addons) in order to get the main drainage direction for MFD flow, use r.terraflow flow accumulation and the filled elevation map produced by r.terraflow as input to r.stream.extract, then patch the new flow directions into the main drainage direction extracted with the addon tools. You can also use flow accumulation from r.watershed with SFD as input to r.stream.extract and patch the flow directions of r.stream.extract into r.watershed flow directions, these are compatible. But note ticket #807. As Jarek said, best would be to use r.watershed in grass65 instead. Hope that helps, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] % of cover class upstream
I have a DEM, a drainage and a Cover mapa, and I need to estimate - for ANY pixel of my drainage - what is the amount of my cover classes that contribute (or are upstream) of that pixel. I'm not sure what is meant by 'for any pixel of my drainage', however, r.water.outlet will calculate a contributing area to a given user defined pixel in an accumulation map. Then once the contributing area is delineated, you could intersect that with your land cover layer and calculate the percentages within that CA of given land use. Alternatively, if using the r.stream.* addon modules, sub-basins can be delineated for a given stream network using r.stream.basins, and those could also be used to intersect the land cover and generate percent cover. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Data Import and Coordinate Information
That sounds similar to what I had to do with a custom Albers projection for Florida. If I recall correctly, I was able to use the custom parameters from the E$RI definition, and make the same custom projection in GRASS to work with the data. Mark On Sat, Nov 14, 2009 at 6:42 PM, Rich Shepard rshep...@appl-ecosys.com wrote: For my current project, almost all data come from the Oregon GIS office (now called the Geographic Enterprise Office). All the data available for download (.shp and .e00 primarily) are supposed to be in the state's own coordinate system, Oregon Conformal Conic. This is actually Lambert Conformal Conic with specific bounds, parallels, etc. Since they're all supposed to have the same bounds and other parameters I should be able to import them to the same location and map set. But I cannot do this. If I tell the import wizard to use the existing coordinates it tells me that they don't match what are in the file. So I have to import each theme into a different location. My first question is what might be causing this to happen? I'll reproject them all to a common location/map set when I get them all in, but wonder why there's an issue. More importantly, when I look at the location/PERMANENT/DEFAULT_WIND and WIND files I find the coordinates are far off what they should be, and what I defined them to be in the GUI. For example, instead of North and South bounds being 46.2N and 41.9N the files show them as 63N and 39N. Second question: what might be happening here? In the meantime, I'll create new locations for all themes then read up on how to reproject them so they're all recognized as using the same coordinates and parameters and will overlay properly. As an aside, I don't see a menu item (under File, I suppose it should be) to create a new location and map set for a new import. As a result, I exit grass and restart it. That's too Microsoftish to be correct. Rich ___ 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] Data Import and Coordinate Information
If I can help, please let me know. But the parameter mapping from the E$RI to GRASS was fairly straightforward. For all the themes being imported into a new location, are they all different projections? Mark On Sat, Nov 14, 2009 at 7:25 PM, Rich Shepard rshep...@appl-ecosys.com wrote: On Sat, 14 Nov 2009, M S wrote: That sounds similar to what I had to do with a custom Albers projection for Florida. If I recall correctly, I was able to use the custom parameters from the E$RI definition, and make the same custom projection in GRASS to work with the data. Mark, So, it may be related to using customized parameters. OK. I can live with that. I plan on importing each theme into a different location/map set, then creating a common one into which I will reproject/move/whatever each individual theme. Then I should be able to remove all those directories. Step-by-step I make progress. BTW, in the late 1980's I was a Technical Program Manager for the St. Johns River Water Management District. That's where I was first introduced to GIS (ARC/Info running on the Prime system there). Rich ___ 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] Data Import and Coordinate Information
... But, I cannot import them into an existing location/map set Is there an error or problem? Or am I missing something obvious? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.stream.extract
Great module! I like the optional parameters to tweak the stream extraction. In my current situation, I have 20,000 acres modeled with a 25ft cell DEM from relatively dense LiDAR data. The project area is very flat and has many wetlands. The elevation range for the 20K acres is only 30 to 170 feet. What is nice, is that I have field verified GPS data for the streams on the site to check against the stream extraction results and tune the parameters. Then, on a similar area project, I can utilize this module where we have no GPS or field data with confidence after tuning to known data. That all being said, I'm looking for suggestions to tune the stream extraction for flat areas with relatively low relief. Additionally, the component of many wetlands. My first question is about the accumulation parameter. As I understand it, MFD is only available in GRASS 7 with r.watershed. I'm on 6.4RC5. If I dont input accumulation with my elevation, will MFD be used in r.stream.extract? Looking at the weight parameter, it seems this may help tune the results also. For the project area, I have coded land use where I can essentially input wet areas (water bodies wetlands), and all else as dry (uplands). Would this help provide more accurate results, or is there another intended use of this parameter? For the mexp parameter, it seems to be applicable to helping with results in flat areas such as this study area. Is there caution against using a higher mexp value if one's whole project area is relatively flat? Thanks for the contribution of this module. I'm looking forward to using the other r.stream.* modules after I have a good stream network extracted. Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stuck Getting Started
You may find it easier to use the EPSG codes button, and pick the code to match your projection/coordinate system. There is the epsg and esri projection files. In Karmic Koaloa Kubuntu, they reside in /usr/share/proj/ Mark On Fri, Nov 13, 2009 at 1:16 PM, Rich Shepard rshep...@appl-ecosys.com wrote: It's been about 6 years since I last used GRASS (4.3), but it makes no sense that I cannot get started on a project now. I'm using the svn download from several days ago. 1.) Created the database /usr4/grassdata 2.) Within /usr4/ started grass: grass64 3.) Tclgrass display comes up and asks again for the database; I enter that. 4.) Click on 'Create new location using projection data'. 5.) The antiquated text entry window displays. I again enter the database, the new location name (ORdem10), and the mapset (rbs). 6.) I'm shown the list of coordinate systems and select D; enter the name 'Oregon Conformal Conic' (which cannot be edited if I mistype a letter), and answer 'y' because it's correct. 7.) Please enter a one line description for location ORdem10 Oregon Conformal Conic = Oregon Conformal Conic = ok? (y/n) [y] ERROR: region for current mapset is not set run g.region ERROR: /usr/local/grass-6.4.0RC5/etc/set_data exited abnormally. Press enter to continue. Can't enter the datum, ellipsoid, and other parameters to define this dataset. Where do I start looking for the reason? Rich ___ 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] installing addon problem for regular users (ubuntu newbies)
not a string literal and no format arguments gcc -L/usr/lib/grass64/lib -Wl,-Bsymbolic-functions -Wl,--export-dynamic -Wl,-rpath-link,/usr/lib/grass64/lib-o /usr/lib/grass64/bin/r.stream.extract OBJ.i486-pc-linux-gnu/close.o OBJ.i486-pc-linux-gnu/del_streams.o OBJ.i486-pc-linux-gnu/do_astar.o OBJ.i486-pc-linux-gnu/flag_clr_all.o OBJ.i486-pc-linux-gnu/flag_create.o OBJ.i486-pc-linux-gnu/flag_destroy.o OBJ.i486-pc-linux-gnu/flag_get.o OBJ.i486-pc-linux-gnu/flag_set.o OBJ.i486-pc-linux-gnu/flag_unset.o OBJ.i486-pc-linux-gnu/load.o OBJ.i486-pc-linux-gnu/main.o OBJ.i486-pc-linux-gnu/rbtree.o OBJ.i486-pc-linux-gnu/streams.o OBJ.i486-pc-linux-gnu/thin.o -lgrass_vect -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lgrass_dgl -lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_gis -lgrass_datetime -lz -lgrass_linkm -lgrass_rtree -lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -L/usr/lib -lgdal1.6.0 -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lm -lz make htmlcmd make[1]: Entering directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' make /usr/lib/grass64/docs/html/r.stream.extract.html HTMLSRC=/usr/lib/grass64/bin/r.stream.extract make[2]: Entering directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' if [ /usr/lib/grass64/bin/r.stream.extract != ] ; then GISRC=/usr/lib/grass64/demolocation/.grassrc64 GISBASE=/build/buildd/grass-6.4.0~rc5/dist.i486-pc-linux-gnu PATH=/usr/lib/grass64/bin:$PATH LD_LIBRARY_PATH=/usr/lib/grass64/bin:/usr/lib/grass64/lib: LC_ALL=C fakeroot /usr/lib/grass64/bin/r.stream.extract --html-description /dev/null | grep -v '/body\|/html' r.stream.extract.tmp.html ; true ; fi ERROR: G_getenv(): Variable LOCATION_NAME not set /usr/lib/grass64/tools/mkhtml.sh r.stream.extract ; mkdir -p /usr/lib/grass64/docs/html ; /usr/bin/install -c -m 644 r.stream.extract.tmp.html /usr/lib/grass64/docs/html/r.stream.extract.html ; for file in *.png *.jpg ; do head -n 1 $file | grep '^#!' /dev/null ; if [ $? -ne 0 ] ; then /usr/bin/install -c -m 644 $file /usr/lib/grass64/docs/html ; fi done 2 /dev/null ; true /bin/sh: /usr/lib/grass64/tools/mkhtml.sh: not found make[2]: Leaving directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' make[1]: Leaving directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' make mancmd make[1]: Entering directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' make /usr/lib/grass64/man/man1/r.stream.extract.1 MANSRC=/usr/lib/grass64/docs/html/r.stream.extract.html make[2]: Entering directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' mkdir -p /usr/lib/grass64/man/man1 GRASS_PERL=/usr/bin/perl VERSION_NUMBER=6.4.0RC5 sh /build/buildd/grass-6.4.0~rc5/tools/g.html2man/g.html2man /usr/lib/grass64/docs/html/r.stream.extract.html /usr/lib/grass64/man/man1/r.stream.extract.1 1 sh: Can't open /build/buildd/grass-6.4.0~rc5/tools/g.html2man/g.html2man make[2]: *** [/usr/lib/grass64/man/man1/r.stream.extract.1] Error 2 make[2]: Leaving directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' make[1]: *** [mancmd] Error 2 make[1]: Leaving directory `/usr/lib/grass64/grass-addons/raster/r.stream.extract' make: *** [cmd] Error 2 On Thu, Nov 12, 2009 at 10:32 AM, Glynn Clements gl...@gclements.plus.com wrote: M S wrote: I'm on Kubuntu 9.10, using both 32 and 64 bit systems. This output is from 32bit. It is GRASS 6.4 RC5. Seems to be the same logged issue of defaulting to /build rather than /var/lib/grass64 - I ran sudo make MODULE_TOPDIR=/usr/lib/grass64 This is the first line of output gcc -I/build/buildd/grass-6.4.0~rc5/dist.i486-pc-linux-gnu/include -Wall -g -O -I/usr/include/gdal -DPACKAGE=\grassmods\ -I/build/buildd/grass-6.4.0~rc5/dist.i486-pc-linux-gnu/include -o OBJ.i486-pc-linux-gnu/close.o -c close.c --- If I apply the GRASS_HOME=/usr/lib/grass64: -- $ sudo make MODULE_TOPDIR=/usr/lib/grass64 GRASS_HOME=/usr/lib/grass64 gcc -I/usr/lib/grass64/dist.i486-pc-linux-gnu/include -Wall -g -O -I/usr/include/gdal -DPACKAGE=\grassmods\ -I/usr/lib/grass64/dist.i486-pc-linux-gnu/include -o OBJ.i486-pc-linux-gnu/close.o -c close.c close.c:1:23: error: grass/gis.h: No such file or directory close.c:2:27: error: grass/glocale.h: No such file or directory close.c:3:24: error: grass/dbmi.h: No such file or directory close.c:4:24: error: grass/Vect.h: No such file or directory
Re: [GRASS-user] r.in.arc Beyond the Man Page
I've imported arc/info GRIDs before, but from .e00 files, or more recently the exports from the arctoolbox as .txt files, which are ascii files. I believe the files listed below are binary arc/info GRID files. Given the excerpt from the r.in.arc manpage, it seems to need an ascii file. (?) r.in.arc allows a user to create a (binary) GRASS raster map layer from an ESRI ARC/INFO ascii GRID file with (optional) title. Mark On Wed, Nov 11, 2009 at 2:14 PM, Rich Shepard rshep...@appl-ecosys.com wrote: I have files for 10M DEM in ARC/Info grid format that I want to use within GRASS-6.4.0RC5. I read the man page, but do not know which input file to use. I've not used this module before so I'm completely clueless. The souce data directory contains: dblbnd.adf info/ prj.adf vat.adf w001001x.adf hdr.adf log sta.adf w001001.adf The r.in.arc syntax includes the input string, but which of the above do I use? Or, do I need to convert each file separately? TIA, Rich ___ 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] r.in.arc Beyond the Man Page
Perhaps this can help. http://grass.osgeo.org/grass64/manuals/html64_user/r.in.gdal.html Mark On Wed, Nov 11, 2009 at 2:14 PM, Rich Shepard rshep...@appl-ecosys.com wrote: I have files for 10M DEM in ARC/Info grid format that I want to use within GRASS-6.4.0RC5. I read the man page, but do not know which input file to use. I've not used this module before so I'm completely clueless. The souce data directory contains: dblbnd.adf info/ prj.adf vat.adf w001001x.adf hdr.adf log sta.adf w001001.adf The r.in.arc syntax includes the input string, but which of the above do I use? Or, do I need to convert each file separately? TIA, Rich ___ 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] installing addon problem for regular users (ubuntu newbies)
It appears so. I'm going to look at the posts and see if I can get mine to work. Thanks, Mark On Tue, Nov 3, 2009 at 7:38 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Nov 3, 2009 at 1:32 PM, M S msei...@gmail.com wrote: I just installed from ubuntugis, and the package is grass_6.4.0~rc5-3~karmic1_amd64.deb, which I presume to be 64bit. I have problems compiling addons (using ubuntugis). Perhaps you are hit by this one: http://trac.osgeo.org/grass/ticket/620 Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installing addon problem for regular users (ubuntu newbies)
Markus, Based on http://lists.osgeo.org/pipermail/grass-user/2009-August/052074.html, is there a checklist of variables I can go through in the Platform.make file to change variable values to /usr/lib/grass64 ? Thanks, Mark On Tue, Nov 3, 2009 at 7:38 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Nov 3, 2009 at 1:32 PM, M S msei...@gmail.com wrote: I just installed from ubuntugis, and the package is grass_6.4.0~rc5-3~karmic1_amd64.deb, which I presume to be 64bit. I have problems compiling addons (using ubuntugis). Perhaps you are hit by this one: http://trac.osgeo.org/grass/ticket/620 Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installing addon problem for regular users (ubuntu newbies)
I'll try some things and report findings. With some guidance from a 'make guru', I'm would think this could be resolved. Thanks, Mark On Tue, Nov 10, 2009 at 3:33 PM, Markus Neteler nete...@osgeo.org wrote: Mark, On Tue, Nov 10, 2009 at 2:24 PM, M S msei...@gmail.com wrote: Markus, Based on http://lists.osgeo.org/pipermail/grass-user/2009-August/052074.html, is there a checklist of variables I can go through in the Platform.make file to change variable values to /usr/lib/grass64 ? Since I have no ubuntu I can only suggest to try (and to report back which didn't appear to happen in August). Sorry for no better answer (I still hope that a Makefile guru takes a look and fixes the missing pieces) Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installing addon problem for regular users (ubuntu newbies)
I just installed from ubuntugis, and the package is grass_6.4.0~rc5-3~karmic1_amd64.deb, which I presume to be 64bit. I have problems compiling addons (using ubuntugis). Mark On Sat, Oct 24, 2009 at 7:17 PM, Horacio Samaniego horacio.samani...@gmail.com wrote: At this point I'm not sure... but believe that I had the ppa on my repositories... On Sat, Oct 24, 2009 at 4:48 PM, Alex Mandel tech_...@wildintellect.com wrote: Were you using the default package in Ubuntu or the ones from Ubuntugis PPA? Alex Horacio Samaniego wrote: Dear Nathan, I discovered that the origin of the problem seem to be that the grass package in ubuntu is not compiled using 64bit libs and that to my understanding it's what's giving us problems. I concluded that by the nature of the error I was getting. So., I kind of went the long way... I repackaged grass for my architecture using: sudo apt-get source grass # downloads the source tree in current dir cd grass* dpkg-buildpackage -rfakeroot # will generate all the -dev -doc packages. best to use sudo? sudo dpkg -i ../*grass*deb # will install everything Once you've gone through that, you can simply install addons the normel way. Which is: download addon to /usr/lib/grass64/ raster or vector (depending on the type of addon) and make, make compile that solved the problem and created a real 64bit grass package along the way. The key seem to be that the installation of the -dev package provides all the libraries to install new addon. The problem arises when you simply install grass from the repository which is NOT 64bit!! but nonetheless functional. I hope that this will help! I'll post this solution to the wiki if nobody objects my assessment of this particular issue. So, please, comment on it if you have a deeper understanding of this than we have... Cheers, H On Fri, Oct 23, 2009 at 11:26 PM, Currit, Nathan Allen cur...@txstate.eduwrote: Hi Horacio, I saw you question posted on org.osgeo.lists.grass-user, but I do not see any responses. Did you find a solution to your problem? I have the same problem. Thanks, Nate *** Nate Currit Texas State University - San Marcos Department of Geography San Marcos, Texas 78666-4616 -- Horacio Samaniego, PhD Instituto de Silvicultura Facultad de Ciencias Forestales Universidad Austral de Chile Valdivia, Chile +56 (63) 222480 [of.] http://www.ecoinformatica.cl ___ 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] installing addons
Greetings All. I have downloaded the GRASS addons, and am working on installing them. I've used this instruction set-- http://grass.osgeo.org/wiki/Compile_and_Install#Addons I have installed GRASS 6.4RC5 binary and grass-dev package on Ubuntu Karmic Koala, from the ubuntugis repo. I'm trying to install r.streams.extract and related stream addons. I get the same error with v.profile. I tried the g.extension module, and command line. Both result in errors early in the compiling saying: close.c:1:23: error: grass/gis.h: No such file or directory close.c:2:27: error: grass/glocale.h: No such file or directory close.c:3:24: error: grass/dbmi.h: No such file or directory close.c:4:24: error: grass/Vect.h: No such file or directory I have found these to be in the /usr/lib/grass64/include/grass directory. Any suggestions? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help creating dissolved multipolygon
If you query two adjacent polygons, do they both have the same value for the 'diss' attribute? On Tue, Oct 20, 2009 at 7:05 PM, Roger André ran...@gmail.com wrote: Yeah, kinda long, but here it is. fwiw, I loaded the file into PostGIS and let it crank away at the dissolve. Was done after about an hour, so while I'm thrilled to have the correct data, I'd still like to figure out a solution in GRASS. v.dissolve global_mask out=new_mask col=diss --o 100% Building topology for vector map new_mask_18169... Registering primitives... 5450 primitives registered 288073 vertices registered Building areas... 100% 2723 areas built 2721 isles built Attaching islands... 100% Attaching centroids... 100% Number of nodes: 5448 Number of primitives: 5450 Number of points: 0 Number of lines: 0 Number of boundaries: 2727 Number of centroids: 2723 Number of areas: 2723 Number of isles: 2721 v.reclass complete. 2723 features reclassed. WARNING: Vector map new_mask already exists and will be overwritten Extracting features... Building topology for vector map new_mask... Registering primitives... 5450 primitives registered 288073 vertices registered Building areas... 100% 2723 areas built 2721 isles built Attaching islands... 100% Attaching centroids... 100% Number of nodes: 5448 Number of primitives: 5450 Number of points: 0 Number of lines: 0 Number of boundaries: 2727 Number of centroids: 2723 Number of areas: 2723 Number of isles: 2721 Writing attributes... Removing duplicate centroids... Building topology for vector map new_mask... Registering primitives... 5450 primitives registered 288073 vertices registered Building areas... 100% 2723 areas built 2721 isles built Attaching islands... 100% Attaching centroids... 100% Number of nodes: 5448 Number of primitives: 5450 Number of points: 0 Number of lines: 0 Number of boundaries: 2727 Number of centroids: 2723 Number of areas: 2723 Number of isles: 2721 On Tue, Oct 20, 2009 at 1:47 PM, MS msei...@gmail.com wrote: Is there output for the dissolve command? Mark On Oct 20, 2009, at 4:37 PM, Roger André ran...@gmail.com wrote: Hi all, I'm having trouble creating a single, dissolved feature and exporting it as a multipolygon. Here is what I've done: - layer I started with: v.info -t global_mask nodes=5448 points=0 lines=0 boundaries=2727 centroids=2723 areas=2723 islands=2721 faces=0 kernels=0 primitives=5450 map3d=0 - added dissolve field: v.db.addcol global_mask col=diss int v.db.update global_mask col=diss value=1 - check that diss field is there: v.info -c global_mask Displaying column types/names for database connection of layer 1: INTEGER|cat DOUBLE PRECISION|cat_ INTEGER|diss - dissolve: v.dissolve global_mask out=new_mask col=diss --o - inspect new layer: v.info -t new_mask nodes=5448 points=0 lines=0 boundaries=2727 centroids=2723 areas=2723 islands=2721 faces=0 kernels=0 primitives=5450 map3d=0 - export layer as shapefile: v.out.ogr -p input=new_mask type=area dsn=/tmp olayer=new_mask - check new shapefile: ogrinfo -summary /tmp new_mask INFO: Open of `/tmp' using driver `ESRI Shapefile' successful. Layer name: new_mask Geometry: Polygon Feature Count: 2723 Extent: (-180.00, -90.00) - (180.00, 83.623596) Layer SRS WKT: GEOGCS[GCS_WGS_1984, DATUM[WGS_1984, SPHEROID[WGS_1984,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[Degree,0.017453292519943295]] cat: Real (11.0) As you can see, I still have 2723 features, when I expect to have 1. What am I doing wrong? Roger ___ 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] r.basins.fill usage
Upon first glance, r.basins.fill seems like a great tool to generate subbasins within a watershed. Although I must not be understanding something obvious and essential. If one has to digitize in the internal ridges in a given watershed, why run the ridge input through the module if one has essentially just delineated the subbasins ridges? Is there an advantage to using a smaller threshold on r.watershed to get smaller basin delineations (ceasing when thin strip basins get introduced)? Thanks for any feedback, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] tool to put raster value to points?
Greetings, I have searched the manuals, and have not found a direct tool. The objective would be to output unique point ID's with corresponding elevations. Is there a tool which would provide for one to attach raster (elevation) values to vector points? If no tool, would this be the most efficient approach? points to raster (all others null). r.mapcalc to assign elevation raster values to converted raster cells. convert raster cells to polygons. overlay polygon (elevation) values onto original points. Thanks for any feedback, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tool to put raster value to points?
Yikes that was fast! Not sure how I missed that one. Much thanks. Mark On Tue, Sep 1, 2009 at 11:05 AM, Marco Lechner - FOSSGIS e.V. marco.lech...@fossgis.de wrote: http://grass.itc.it/grass62/manuals/html62_user/v.what.rast.html M S schrieb: Greetings, I have searched the manuals, and have not found a direct tool. The objective would be to output unique point ID's with corresponding elevations. Is there a tool which would provide for one to attach raster (elevation) values to vector points? If no tool, would this be the most efficient approach? points to raster (all others null). r.mapcalc to assign elevation raster values to converted raster cells. convert raster cells to polygons. overlay polygon (elevation) values onto original points. Thanks for any feedback, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- BITTE VORMERKEN INTERGEO 2009: 22.09. - 24.09.2009 in Karlsruhe; Halle 1, Stand 1.417 +++ FOSSGIS e.V. die unabhängige Hilfe bei freier GIS-Software und freien Geodaten www.fossgis.de + ___ 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] Hortonian analysis - current status
Excellent! Those are fantastic. Thanks for the contribution. We are working on some stream assessments, and I hope to be able to get time to try these modules. I will be sure to provide feedback. Great stuff! Mark 2009/8/27 Jarek Jasiewicz jar...@amu.edu.pl Dear grass users! I present next version of tools for hortonian analysis. Source code and tutorial are available here: http://heretic.livenet.pl/heretic/ Currently following modules are available: - r.stream.order: to calculate Strahler, Horton, Shreve and main stream (Hack) ordering. That module is almost ready to use - r.stream.basins: calculate basins according users input. Read more on web page - r.stream.distance: calculate downslope distance path and elevation above to streams/outlets. That module is in early development stage, but works, and results seems good. But it may will change in the feature. -r.streams.stats: calculate hortonian statistics is not avilable: maybe in next few days. All three modules works fine on small dems (up to 20 millions cells). Only on powerful machines with at least 2-4GB RAM they handle avarage dems (up to 120 M cells). I have no information about largers dems (over 100M cells because I haven't so). Till I finish my work modules are available only from my web page. After I will absolutely sure that everything is OK, add vector capabilities and solve problems with massive dems (for LIDAR puropse) I will try to add them to GRASS add-ons. best regards Jarek Jasiewicz ___ 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] Reading list of vector maps into file or array
Greetings All: How would one read the vector maps in a current mapset into a file, or a list in an array (using python)? If I do 'g.list vect walker.list', the list is not in one column and seems to be separated by tabs, with 4 columns and a bunch of rows of vector files. Would a simple solution be to begin processing that redirected output? As background... After running the r.sim.water module, I get a bunch of walker vector maps as outputs for given intervals. Works well thus far. I'm building an animated GIF of the walkers over time, on a shaded DEM. The method I am using is tedious and am seeking to automate the process. I load all the layers (shaded DEM, walkers at various intervals) and turn on one walker vector, and output a .png from the display monitor. Wash, rinse, repeat until all walkers have been captured as an image, then animate them with the 'convert' command. If anyone has some suggestions on how to get vector maps into a list, please let me know. Also, if there is a better way to solve this problem, any feedback would be greatly appreciated. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Reading list of vector maps into file or array
Most excellent. Thanks to both for the help. Great wiki page too. Mark On Thu, Aug 20, 2009 at 12:29 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: It is amazing!!! Thanks hamish! milton 2009/8/20 Hamish hamis...@yahoo.com Mark: If I do 'g.list vect walker.list', the list is not in one column and seems to be separated by tabs, with 4 columns and a bunch of rows of vector files. g.mlist I'm building an animated GIF of the walkers over time, on a shaded DEM. The method I am using is tedious and am seeking to automate the process. I load all the layers (shaded DEM, walkers at various intervals) and turn on one walker vector, and output a .png from the display monitor. Wash, rinse, repeat until all walkers have been captured as an image, then animate them with the 'convert' command. see loop shell scripts in http://grass.osgeo.org/wiki/Movies Hamish ___ 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] Extract Building Footprints from LiDAR
There is a great suite of lidar tools in GRASS. One that might target your needs is http://grass.itc.it/grass64/manuals/html64_user/v.lidar.edgedetection.html On Thu, Jun 4, 2009 at 3:03 PM, Shaun Melissa Busler busl...@gmail.comwrote: I was wondering if anyone has tried to extract building footprints from LiDAR LAS files. I searched the archives and could not find anything. Thanks! Shaun ___ 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] Green Highland
The software can be used for commercial use. Both raster and vector data can be exported to shapefiles, which can be read by nearly all GISs. One can use native GRASS vectors and rasters for cartography in GRASS, or the Quantum GIS software to make end product maps with native GRASS datasets. There are other open source softwares like GMT for cartography also, but QGIS has a great interface and linked to use GRASS data and locations. You can use existing data or create your own. As for your specific area of interest, I would suggest googling for that GIS data and/or looking to an agency who might already have the data in a GIS format. Good luck and most of all have fun! Mark On Tue, Apr 7, 2009 at 5:19 AM, Jayson Drummond jaysondrumm...@greenhighland.co.uk wrote: Hello, I have been looking at the replies from some of the members on here and it seems that this is the kind of stuff we will be using. Just a couple more potentially bone questions here: - What’s the scope regarding licenses? If we are using it for commercial purposes do we have to purchase a separate license? - Is it possible to export the finished template to another program in order to print it? - Is it just existing data that we can use? How do I find for example, drift geology of the Ben Lawers region? Or do I have to enter my own data for it? Once again, thank you for your help Jayson Drummond Environmental Manager Green Highland Renewables 1 Kenmore Street Aberfeldy PH15 2BL Tel: 01887 822042 Email: jaysondrumm...@greenhighland.co.uk web:greenhighland.co.uk ___ 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] r.contour / wxpython
I just started using the python interface with GRASS (6.3), where I have typically used the older interface. I ran r.contour. I wanted to re-run it, but change the input/output names. I noticed two things, and was wondering if they are intentional. This behavior was not present in the previous GUI. 1) After running r.contour, the run button is grayed out, and wont re-activate unless I close and re-open r.contour 2) looking at the command, --overwrite is set by default, even though in the options it is not checked off. If I check it and uncheck it, the overwrite option then goes away. Perhaps this is fixed in a subsequent release? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to make a conversion of ERSI Grid ASCII==USGS DEM?
You're on the right track. If you have obtained a an ESRI GRID representing a DEM in an e00 format, then with GDAL and/or GRASS you can convert from ESRI GRID (e00) to USGS DEM format, with the workflow Hamish outlined previously. ESRI data is in binary raster/vector formats when ESRI software is reading/writing data. Your e00 is an ASCII export format of the binary GRID (e00's are also for arc/info coverage vector exports). e00's were intended to export raster and vector data from arc/info workspaces for importing into other ones, because you cant easily copy/move/share datasets in the native format. ESRI GRIDS use a directory for the spatial component in a directory, linked to attribute data in a separate INFO directory which has all the workspace attributes in it. e00's grab relavant attributes from the INFO directory and package them with the spatial data from another directory, into one ASCII e00 file (or if specified e00, e01, etc.) Best of luck. Mark On Sun, Mar 1, 2009 at 10:26 AM, Illidan illidan.mode...@gmail.com wrote: I'm overall new to GIS. But my work has to rely on USGS DEM formatted data, so I cannot run away. However, I'm only fortunate enough to get DEM data in ESRI ASCII format. That's why I have to do a conversion. http://en.wikipedia.org/wiki/ESRI_grid I guess ESRI ASCII format is well-known to GIS guys. Maybe I made a mistake mixing e00 up with ESRI ASCII. A friend of mine, who is now a newbie GIS engineer, told me that ESRI ASCII was the same thing as e00 file. On Sun, Mar 1, 2009 at 7:29 PM, MS msei...@gmail.com wrote: e00s can contain all the formats Hamish mentioned. I think the question was more about the type of data the e00 contains. Mark On Mar 1, 2009, at 6:06 AM, Illidan illidan.mode...@gmail.com wrote: On Sun, Mar 1, 2009 at 4:05 PM, Hamish hamis...@yahoo.com wrote: Illidan wrote: I'm trying a conversion of from ERSI Grid ASCII(e00) to legacy USGS DEM that one old piece of software I'm using supports. I searched the web and only got results about the reverse conversion, i.e. USGS DEM== e00. So I ask for help here. I appreciate any feasible work flow or hint on an existing conversion software. $ gdalinfo --formats | grep USGS DOQ1 (ro): USGS DOQ (Old Style) DOQ2 (ro): USGS DOQ (New Style) ISIS3 (ro): USGS Astrogeology ISIS cube (Version 3) ISIS2 (ro): USGS Astrogeology ISIS cube (Version 2) USGSDEM (rw): USGS Optional ASCII DEM (and CDED) (see gdal.org) hopefully you want USGSDEM? if so import to GRASS with v.in.e00 and do what you have to do to get into raster format before running r.out.gdal format=USGSDEM. what is the nature of the e00 file? contour lines? TIN? points? ascii-grid of some sort? Thanks for you reply. I'll try what you suggest. e00 is plain text file containing raster data, developed by ESRI. It contains headers of about six lines, followed by raster data for each cell. Its format is somewhat similar to USGS DEM. Hamish -- Illidan Networking System Modeler Northern Capital, Republic of Pandaren http://illidan.go.3322.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Illidan Networking System Modeler Northern Capital, Republic of Pandaren http://illidan.go.3322.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass wiki on RST troubleshooting
this wiki has been quite helpful, as well as the link in it for working with contours. http://grass.osgeo.org/wiki/RST_Spline_Surfaces#Troubleshooting I'm not sure I understand where this is to make the change for MAXPOINTS? In the v.surf.rst/v.vol.rst, there is a MAXPOINTS value defined (surf.h). MAXPOINTS simply says how many input points are allowed to be computed without segmentation. I had to increase the value of MAXPOINTS in surf.h to 1346 (or a bit more) and then to use segmax=1346 to avoid segmentation. (sidenote) : Something else I found cool, was using some contour lines from a USGS map, and patching in the spot elevations (I'm working on projects in central/south florida where its quite flat, so any supplemental elevation data helps). It seems that, since they are both on layer 1, that the module incorporates the use of the points from the contour lines as well as the spot elevations that were patched in. Nice! In that other software you cant have different geometries in the same file. I never understood why this would be practical. In GRASS, this is a refreshing flexibility! Thanks, and happy GRASS-ing! Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM generation with v.surf.rst and isolines
I found this link from the GRASS wiki to be quite helpful. http://skagit.meas.ncsu.edu/~helena/grasswork/interpgen.html Mark On Thu, Feb 26, 2009 at 9:52 AM, Christian Braun christian.br...@tudor.luwrote: Dear list members, I am currently working on the generation of a hydrologic correct DEM. As base data I have isolines on a 20k scale and 6 fix height points for whole Luxembourg (approx. 2500km^2) I tried first v.surf.rst with the isoline input and it generates in the region of valleys and plateaus artificial artifacts where it isn't able to gather enough data in range of the isolines. It is clearly visible that these represent the segmentation windows of the algorythm. Because of the processing time (20h for a small area) I shifted to v.to.points in combination with v.surf.rst and try to include also the fix height points for the interpolation. Can you tell me some suitable parameters to start with for v.surf.rst in context of using isolines as input. In areas with higher slope I have plenty of representation but I don't have data in flat areas like valleys and plateaus. Thanks in advance and greetings from Luxembourg, Christian Dipl. Geogr. Christian Braun Tel: +352- 425991-608 Mobil: +49-179-6845896 Mail: christian.br...@tudor.lu Resource Centre for Environmental Technologies, Public Research Centre Henri Tudor, Technoport Schlassgoart, 66 rue de Luxembourg, P.O. BOX 144, L-4002 Esch-sur-Alzette, Luxembourg ___ 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] Problem running r.terraflow
try: g.region -ap res=10 If my memory serves me correct. Mark On Wed, Feb 18, 2009 at 10:11 AM, Margherita Di Leo direg...@gmail.comwrote: Hi all, i have a problem using Grass 6.5 with a raster elevation map running the command 'r.terraflow'. I need to obtain the flow accumulation with MFD. The error is the following: 'cell file dem resolution differs from current region'. I ran the command 'g.region -ap rast=dem' and this is the result: projection: 1 (UTM) zone: 33 datum: wgs84 ellipsoid: wgs84 north: 6651087.53951495 south: 6541497.53951495 west: 500200.31922317 east: 649510.31922317 nsres: 10 ewres: 10 rows: 10959 cols: 14931 cells: 163628829 with 'r.info' the result is: Type of Map: raster Number of Categories: 255 | | Data Type:FCELL | | Rows: 10959 | | Columns: 14931 | | Total Cells: 163628829 | |Projection: UTM (zone 33) | |N: 6651087.53951495S: 6541497.53951495 Res:10 | |E: 649510.31922317W: 500200.31922317 Res:10 | | Range of data:min = 3.00 max = 402.930878 | | | | Data Description: | |generated by r.in.gdal | | Please can you help me? Any idea about what's wrong? Sorry if my question is trivial. Regards -- Ing. Margherita Di Leo Ph.D. Student Methods and Technologies for Environmental Monitoring Department of Environmental Engineering and Physics (DIFA) University of Basilicata Campus Macchia Romana 85100 - Potenza Italy Office: +39-0971205363 Fax: +39-0971205160 E-mail: dileomargher...@gmail.com Skype: dileomargherita URL: http://www.difa.unibas.it/A_Manager_PP.do?azione=visualizzaHomePageid=106 ___ 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] Re: understanding r.watershed
Since a lake stores water, it sounds reasonable to consider it a depression. That is what I used on an internally drained watershed, and it worked well. More or less a feature you determine will hold water, and not overland flow. The other areas of all have flow characteristics (e.g. accumulation,direction). Mark On Thu, Jan 29, 2009 at 10:49 AM, Georg Kaspar ge...@geofs.de wrote: On Thu, 29 Jan 2009 10:20:36 -0500, M S wrote: In short, r.watershed, without depression input, will route water in and *up* and out of depressions in the terrain to illustrate the complete downward path. This is why no DEM filling is necessary. By entering in known (substantial and impactful) depressions, the water does not route out of it. But in my case, providing known depressions leads to areas of null()s around those depressions (lakes by the way). ___ 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] [GRASSLIST:1216] Re: terrain modeling
It looks like it was exported in Z,Y,X or Z,X,Y coordinates. You will have to tell GRASS that on input; the order or the values. Its normally x,y,z format. have fun. Mark On Wed, Jan 28, 2009 at 3:22 PM, Frank Aragona fr...@agroinnovations.comwrote: Mark, I've attached the .csv file for the data set...if you have a chance, maybe you could take a quick look at it. The map coordinates are in New Mexico State Plane West Zone NAD 83. I do get some strange anomolies on the interpolated surface. Wondering what parameters I can feed into GRASS to clean that up. Thanks in advance, -- Franklyn B. Aragona Project Director Agricultural Innovations www.agroinnovations.com 505-292-7110 ext. 200 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Terrain Modeling on Small Areas
There are a lot of great hydro tools in GRASS. I would recommend at a minimum, some of these below. On Wed, Jan 28, 2009 at 2:08 PM, Frank Aragona fr...@agroinnovations.comwrote: What I'd really like to know, actually, is how to do terrain modelling and waterflow analysis on a small area. I have a .csv file with xyz coordinates. My approach has been: 1. Import this using v.in.ascii -z input=C:some_file.csv output=vector_xyz format=point fs=, skip=0 x=2 y=3 z=5 cat=1 Try using r.in.xyz http://grass.itc.it/grass62/manuals/html62_user/r.in.xyz.html to process the data, look at voids, use statistics to determine an appropriate cell size, etc. 2. Create an interpolated raster surface with v.surf.idw from the imported vector map. try too http://grass.ibiblio.org/gdp/html_grass63/v.surf.rst.html 3. R.contour for a contour map from the output of v.surf.idw 4. R.flow to determine flow lines of water on the map surface 5. r.terraflow for flow accumulation and dispersion 6 r.watershed and it's outputs. How good is your input data? Meaning what is rough horizontal spacing? Have Fun. Mark Do you all think this is a good approach? My area is very small, about 10 acres. I'm not quite sure about the quality of my outputs. If somebody is willing to give some tips here, would much appreciate it. Frank Aragona ___ 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] help me to learn GRASS
The 3rd edition GRASS book is really the way to go, perhaps after what Werner recommended. It is one of the best books I have read on GIS as it relates to concept and actual usage and implementation. It has lots of applicable examples. I cant recommend it enough. http://www.grassbook.org/ Mark On Fri, Dec 12, 2008 at 5:08 AM, sarath babu.mg sarathbabu...@gmail.comwrote: Dear Friends, Iam Sarath Babu M G from India, migrating towards FOSS GIS, I hav installed grass 6.3 in my fedora OS. Can u help to learn GRASS ___ 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] Generating Vector Data From Legal Description
Is there a way to plot legal descriptions in GRASS? Where one is provided with textual starting and end points, and then all the distances and angles in between to construct the parcel. For example, the legal may be point of beginning is at X,Y location. then the legal goes something like, then South 90 degrees West a distance of 900 feet; thence North 0.5 West a distance of 200 feet; etc, etc, etc. until back to the point of beginning I'm not a surveyor, so I dont know all the details of legal descriptions. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Generating Vector Data From Legal Description
Too good! Not sure how I missed that one. That is simply awesome. Mark On Mon, Jun 9, 2008 at 1:57 PM, Dylan Beaudette [EMAIL PROTECTED] wrote: On Monday 09 June 2008, M S wrote: Is there a way to plot legal descriptions in GRASS? Where one is provided with textual starting and end points, and then all the distances and angles in between to construct the parcel. For example, the legal may be point of beginning is at X,Y location. then the legal goes something like, then South 90 degrees West a distance of 900 feet; thence North 0.5 West a distance of 200 feet; etc, etc, etc. until back to the point of beginning I'm not a surveyor, so I dont know all the details of legal descriptions. Mark m.cogo ? 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
Re: [GRASS-user] Just a comment about the GRASS-book
I would be very interested in purchasing a supplemental book for the ~200 pages that needed to be excluded from the 3rd edition print. I am sure others would be as well. I cant read enough about GRASS, and I absolutely love the format and way information and examples are presented in the book. To anyone who has not purchased the book: I highly recommend it for people of all skill levels. It will help beginners get started, as as well as intermediate and advanced users gain a broader understanding of some of the great tools and modules available in GRASS. Mark On Thu, May 29, 2008 at 3:45 PM, Markus Neteler [EMAIL PROTECTED] wrote: On Thu, May 29, 2008 at 5:41 PM, Nikos Alexandris [EMAIL PROTECTED] wrote: Tom I have it (3rd ed.). I have also (from a friend) the 2nd edition in which I have seen for instance a detailed part about FFT. And I was wondering about the 1st book. I've read the contents of the 1st book and I have the impression that having the 2nd and the 3rd I am covered. We had to take out some content due to the 400 pages restriction from Springer (otherwise they have to do a more costly binding and such). Our draft was about 600 pages for the 3rd edition :) We can check with Springer if we can put out the omitted parts from the previous editions (esp. FFT, orthophoto). Maybe, once they are no longer sold they don't mind. We'll keep you posted. Best, 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] supervised classification - feature extraction
That would be great. Let's say for example that I only want to classify paved or dirt roads. So I setup two classes, one training area for dirt road, and one for paved road. Then a third outlier class of everything else that doesnt match the two inputted training classes. It almost seems like using an unsupervised classification could achieve this, and then only extract the features of interest, being types of roads or impervious features. I have lidar intensity data, but it is single band, and I am presuming that this 1 foot pixel multiband true color is better input for defining unique signatures. Mark On Fri, May 30, 2008 at 10:49 PM, Hamish [EMAIL PROTECTED] wrote: Mark: I realize one can use use a training map to cluster like features, but is there a way to have a leftover class that throws everything else that doesnt match a defined class into this leftover category? ie you want an outliers class? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] interpolating intensity points r.in.xyz
I have some lidar data, that has return strength or intensity values for an infrared beam. the lidar data points have a density to support at least a 3 foot cell size (thanks to the results of r.in.xzy using meth=n and r.report - a great tool!). Because I'm working with about a 10 square mile area of interest, I found 25 foot cells to work great for watershed delineation based on a time trade off on larger cells. Now I want to interpolate the intensity value from lidar for the 10 sq mile area, starting at a 25 foot cell size, then working down to smaller cells for greater detail to extract smaller sized features (still working towards extracting impervious features like roads and houses). I suspect the intensity data may be better for house extraction, because the roofs are mostly all uniform in intensity clusters values, where with RGB the roof shingles are far to varied for it to classify them cleanly without other classes of non-roofs appearing all over the map in scattered clusters. Using r.xyz.in, I am wondering which method is the most appropriate for getting an intensity value per cell. Then end result is image clustering/classification from this data (comparing to the multiband true color). Would method=mean make the most sense to use to assign intensity values to the cells with r.in.xyz? and which method of interpolation would be best suited to develop a high contrast 'intensity' map? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] supervised classification - feature extraction
I realize one can use use a training map to cluster like features, but is there a way to have a leftover class that throws everything else that doesnt match a defined class into this leftover category? I'm using i.gensig to generate a signature file from a training map, and then i.maxlik to classify the raster. It works very well, but I am seeming to find that by defining 7 classes, it wants to put something in every class, even if not a best match. It is quite possible I am missing something critical, or not using the proper module. It looks like I should give i.smap a try too. Can a class be setup that would hold all the signatures not defined by the training map? Also, in trying to extract houses, because of the wide variety of colors of roof shingles, it does not seem to work very well because of all the variance with in that class. I have lidar data for this area, and was thinking that for houses/buildings it might be a better approach to use lidar processing tools. Basically I'm looking to classify impervious features within a given watershed. there was a good link here about this ( http://www.perrygeo.net/wordpress/?p=104 ), but the watershed I'm working with has huge areas of residential development. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] RST - how does it chooses from near points?
I cant answer the question of how the v.surf.rst module choses points, but I can say that with the use of r.in.xyz you can control this quite well. For example, (and relating to the last question) you can use different methods to assign values to the cells from ASCII import. Meaning if you have multiple points in a cell, and you only want the values that are the minimum in the cell, use the 'method=min' option. Alternatively, you can use 'mean' and 'max' for other applications as well. then you would r.to.vect the data, as 3d points and then interpolate with v.surf.rst. If I recall right, by doing this r.in.xyz, it cut out about 35% of the processing time for v.surf.rst in my application. Especially for LiDAR data, I found the r.in.xyz module to be nothing short of spectacular. With the 'method=n' option, and an r.report raster unit=p, you can see the percent distribution of points per cell to help set cell size. These are some great tools! Mark On 5/27/08, Carlos Guâno Grohmann [EMAIL PROTECTED] wrote: It just came to me: if I have a vector map to be interpolated by RST, how does the algorithm chooses between points that are very close to each other? And if I have more than one point with the same coordinates, but different values? thks all Carlos -- +---+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +---+ _ Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive. --The winning entry in a What were HAL's first words contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke Can't stop the signal. ___ 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] syncing two locations
I completely agree to use your approach, with the shared location with multiple mapsets. Using something like Unison sync's the locations well, but has problems with single file reconciliation such as an sqlite.db file for all the vector attributes. Now I have some vector files that dont have attributes. :-( It seems to work fine for rasters, but cant say for absolute. I would stick with your approach, or use the linux clustering approach like you mentioned. thanks for the feedback, this will be a great help to distribute the processing load. Mark On 5/22/08, Markus Neteler [EMAIL PROTECTED] wrote: (I take liberty to cc the list again for discussion) On Thu, May 22, 2008 at 3:59 PM, M S [EMAIL PROTECTED] wrote: That is cool. I will definitely check out the wiki page. Perhaps I am not using locations or more specifically mapsets as efficiently as I could be. If I were to use a single location, but with different mapsets, would there be issues with changing the region boundary and/or the cell resolution? not at all, all mapsets are independent. For example, in my main area of interest (basin) there were areas I needed to do finer detailed analysis, going from 25 foot cells to 3 foot cells (r.in.xyz + r.report helped me find this optimal cell size, great stuff!), would this be an issue within the same location, but using a different mapset? I had thought that region settings applied to a location. no :) to a mapset! I have added http://grass.osgeo.org/wiki/Parallel_GRASS_jobs#Background I had (perhaps not the best choice, copied the location to another workstation) and changed the region resolution and boundary, and then ran more detailed analysis. If you do it serially, no problem. Otherwise it will conflict. Under this scenario, does it still make sense to use a single shared location? Most likely. One problem I foresee is with vectors using a single sqlite.db file, That's true. You cannot write simultaneously to the same sqlite.db file. http://en.wikipedia.org/wiki/SQLite A write access can only be satisfied if no other accesses are currently being serviced, otherwise the write access fails with an error code (or can automatically be retried until a configurable timeout expires). This concurrent access situation would change when dealing with temporary tables. But just use different names, so multiple sqlite.db files? in two different locations and then getting the vector database out of sync, and unable to rectify this with syncing the locations. It seems that reprojecting the data into the location is one way to deal with this single DB issue. I feel that it's making things worse. Most all of what I'm doing is time-consuming raster analysis though, and on the first sync, things seemed to work as expected. OK fine. Please let's collect ideas in the wiki how to deal with vector data and related DBs when processing in parallel. Markus Mark On 5/21/08, Markus Neteler [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 5:58 PM, M S [EMAIL PROTECTED] wrote: I have two GRASS workstations performing various lidar and basin operations. My idea was to distribute the processing on various machines. As new data gets created in each location on each computer, when all processes are done, I would like to re-sync the locations to be the same. I did massive MODIS map processing on a cluster and used one location only in a shared network directory. Therein multiple mapsets with a final g.copy job to the mapset keeping the results. I have documented it here: http://grass.osgeo.org/wiki/Parallel_GRASS_jobs#PBS Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] syncing two locations
The best solution does seem to be the multiple mapsets, from a single shared location. That is really a great way to distribute the processing, especially given the flexibility of mapsets in a location. Mark On 5/22/08, Markus Neteler [EMAIL PROTECTED] wrote: (I take liberty to cc the list again for discussion) On Thu, May 22, 2008 at 3:59 PM, M S [EMAIL PROTECTED] wrote: That is cool. I will definitely check out the wiki page. Perhaps I am not using locations or more specifically mapsets as efficiently as I could be. If I were to use a single location, but with different mapsets, would there be issues with changing the region boundary and/or the cell resolution? not at all, all mapsets are independent. For example, in my main area of interest (basin) there were areas I needed to do finer detailed analysis, going from 25 foot cells to 3 foot cells (r.in.xyz + r.report helped me find this optimal cell size, great stuff!), would this be an issue within the same location, but using a different mapset? I had thought that region settings applied to a location. no :) to a mapset! I have added http://grass.osgeo.org/wiki/Parallel_GRASS_jobs#Background I had (perhaps not the best choice, copied the location to another workstation) and changed the region resolution and boundary, and then ran more detailed analysis. If you do it serially, no problem. Otherwise it will conflict. Under this scenario, does it still make sense to use a single shared location? Most likely. One problem I foresee is with vectors using a single sqlite.db file, That's true. You cannot write simultaneously to the same sqlite.db file. http://en.wikipedia.org/wiki/SQLite A write access can only be satisfied if no other accesses are currently being serviced, otherwise the write access fails with an error code (or can automatically be retried until a configurable timeout expires). This concurrent access situation would change when dealing with temporary tables. But just use different names, so multiple sqlite.db files? in two different locations and then getting the vector database out of sync, and unable to rectify this with syncing the locations. It seems that reprojecting the data into the location is one way to deal with this single DB issue. I feel that it's making things worse. Most all of what I'm doing is time-consuming raster analysis though, and on the first sync, things seemed to work as expected. OK fine. Please let's collect ideas in the wiki how to deal with vector data and related DBs when processing in parallel. Markus Mark On 5/21/08, Markus Neteler [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 5:58 PM, M S [EMAIL PROTECTED] wrote: I have two GRASS workstations performing various lidar and basin operations. My idea was to distribute the processing on various machines. As new data gets created in each location on each computer, when all processes are done, I would like to re-sync the locations to be the same. I did massive MODIS map processing on a cluster and used one location only in a shared network directory. Therein multiple mapsets with a final g.copy job to the mapset keeping the results. I have documented it here: http://grass.osgeo.org/wiki/Parallel_GRASS_jobs#PBS Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] syncing two locations
I have two GRASS workstations performing various lidar and basin operations. My idea was to distribute the processing on various machines. As new data gets created in each location on each computer, when all processes are done, I would like to re-sync the locations to be the same. So far, unison seems to work quite well doing this, but it was only done once so far. Are there any things to consider when doing this, based upon GRASS location structures? Or is there a better approach to distribute the processing? Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.watershed and basins that are sinks
I've had good results with r.watershed, however, I'm seeking further clarification about the 'depression' input, specifically when the watershed of interest is an internally drained basin. I have a watershed that is an internally drained basin, where most of the surface water outflows as groundwater. The basin is in the order of about 13 square miles. If I don't input a depression dataset, I get a nice delineation of the sink basin, with (what appears to be only) one exception: At the lowest point along the ridge of the internally drained basin, r.watershed wants to bump out the divide delineation to another low point in the DEM. In other words, inside the large sink basin, I may have elevation as low as 15 feet. The highest point before overflowing the basin is around 31 feet. At this pop-off point for the sink, it seems logical that a divide should be there. Instead, it does not put a divide there, and swings the delineation out to encompass another low spot (about 15 feet elevation) on the other side of the 31 foot divide. It seems that, even with an internally drained basin, it wants to find and incorporate the lowest point to drain to, regardless of the fact that it needs filled about 15 feet before it would flow to that side of the divide. If I input data from the r.lake module as depression, I only get output maps from r.watershed that are all populated with zeros (black), although I am still trying various inputs for the depression map. I am not sure that this input parameter is applicable for defining an internally drained basin, as it is to define depressions that may retain water during a rain event. Even though the basin can be filled up to about 31 feet with r.lake before it pops-off, there are still dry spots in the internal basin that do not get totally flooded, meaning they are higher than 31 foot. Another trial will be to make sure the depression map that is inputted has no upland islands in it, but is all contiguous area for the depression. My questions are: Is it appropriate to use something like r.lake to fill the basin to the pop-off level, and then use that as input into r.watershed via the depression parameter? Are there any other special considerations I should be aware of to model basins that are actually real sinks? Are there other GRASS tools I should be looking at to aid in this internal basin delineation? Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] is it possible to import map without providing datum Projection..????(Urgent!!)
There is a location setup option for plain old X,Y coordinates, that are an undefined system. Mark On Tue, Apr 15, 2008 at 7:34 AM, Kunal Malik [EMAIL PROTECTED] wrote: Hi !! is it possible to import map without providing datum Projection.. and does datum wgs84 and lcc can co-exist at display. -- Thanks Regards Kunal Malik 09871147561 ___ 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.ascii - put1 of 4 columns to 3D point file attribute
On Mon, Apr 14, 2008 at 1:33 AM, Hamish [EMAIL PROTECTED] wrote: Mark wrote: The points are about 5 million per tile, and there are 23 tiles (about 115 million total). I'm not sure if this is considered a large amount of mass input points. Yes, it's a lot. The current vector engine allocates a small amount of memory per feature for topology. With the DBF as database and default v.in.ascii settings I've only ever managed to import about 3 million points before running out of memory. I am interested to hear that you could load 5 million into a SQLite DB, maybe that is more efficient. The SQlite setup was so easy (thanks to the book), and then able to start working with the tables was a breeze (literally as easy as db.connect driver=sqlite database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db.) I'm not a SQL expert, but learned enough to do some sweet tasks. SQlite was rather impressive in working with 5.2 million records. Through v.in.ascii, it did load all the data (4 columns) into the sqlite database without problem (about 7 minutes on a 64bit 2.0GHz 2GB ram system - no table and no topology) With the v.in.ascii -t and -b flags you should be able to load 25million+ points into a single vector map, but there is a limited number of modules that will be able to use a vector map without topology. (importantly v.surf.rst still works) Ayone know if the v.outlier, v.lidar.edgedetect, v. lidar.grow and v.lidar.correction need topology? If you are willing to abandon your code data column, you can strip off that column and import the rest as a 3D vector (-z z=), in which case no table is created (or just ignore it with -t -z). If you are just interested in the 3D coordinate, then a DB table is unneeded overhead and is best skipped. This approach turned out to be the best. You (Hamish) were right that the code was an intensity or strength of return signal. I made a nice intensity grayscale map, that was great. Since I dont need the intensity, or know how to use it to help separate the DEM from DSM features, the 3D point worked perfect. Thanks! Question: what do you want to do with the data? Simply create a raster DEM or do more fancy cleaning with v.lidar.*? If just creating a raster DEM you might skip v.in.ascii altogether and use the r.in.xyz module. I will definitely look more closely at the r.in.xyz module. I had used it for some binning and statistical analysis of the point distribution of the lidar. it is pretty tight data. I want/need to do fancy cleaning with the v.lidar.* tools. However, not having pulse return counts to work with like the example in the book, I am not sure how well it will work, because only having an intensity value, I'm not sure how that relates to first and last returns. What I would like to do with the data is create a bare earth DEM, and a DSM of the elevated surface features. Then perhaps add elevated surface features like solid objects (e.g. buildings, etc) that would block terrain for shallow overland flow or r.lake simulations for flooding. Since the application is for watershed analysis (feature building, and ultimately running hydrology models in GRASS), so my goal is to create the most realistic hydrologic surface model to properly route the water. In theory, it seems to me that water should not route through solid features like buildings (extrude as walls?), but should be able to (and often does) route through shrubby or forested areas. In these areas, where there is canopy, it seems that those canopy elevations should be replaced with bare earth elevations, but allow water to flow through these areas. This is the first time I have worked with raw LiDAR data to create features or do watershed analysis, so this is a fun learning experience. Typically, I had worked with contour data in the past. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.outlier and sqlite
Hi all: When I run v.outlier I get the following error. The data source is lidar data, created with v.in.ascii with no table or topology. Any suggestions? Here is the error message: GRASS 6.2.2 (SPWharnFT):~/gis/locations/SPWharnFT v.outlier input=lidar57697_3d output=lidar57697_clean outlier=outlier57967 qgis=qgis57697 --overwrite WARNING: The vector 'qgis57697' already exists and will be overwritten. WARNING: coor files of vector '[EMAIL PROTECTED]' is larger than it should be (12895143 bytes excess). DBMI-SQLite driver error: Error in sqlite3_prepare(): no such table: Auxiliar_outlier_table ERROR: Impossible to write in the database Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS sqlite
Hello list! I was importing lidar data into a 3D point with the sqlite dbase driver. While it was chugging on that, I tried to import some simple polygon data. I got a database locked message. Does this mean that database access in a mapset (when using sqlite) is limited to one vector at a time? Have a great friday! Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii - put1 of 4 columns to 3D point file attribute
Thanks for the various solutions. The points are about 5 million per tile, and there are 23 tiles (about 115 million total). I'm not sure if this is considered a large amount of mass input points. Perhaps the table size is OK. I havent reached a size problem yet, but I was trying to avoided it from the start. Only using the xyz fields seems like a good solution, and bringing in the 4th column attribute after the fact, if it is even necessary. Thanks much, Mark On Thu, Apr 10, 2008 at 2:39 AM, Hamish [EMAIL PROTECTED] wrote: Mark wrote: I have an ascii table of lidar data. The columns are x,y,z, and a fourth column containing an integer code of some sort. how many points are we talking about? millions? it the table becoming too huge? wc -l inputfile.txt I have looked at the example in the man page about how to select columns for importing via some shell manipulation of the input ascii file, but I do not think it is applicable to what I'm doing (or perhaps the caffeine boost is not in effect yet). I have also tried various combinations of parameters in v.in.ascii. I would like to import the XYZ to build the geometry for 3D points, and have only Cat and Code in the attribute table. (Code being a column name for the 4th column in the input ASCII). I cant seem to find the combination of column definitions and other parameters to achieve this. One option seems to import them all as x double, y double, z double, code int, and then after the import, drop the x,y,z columns. In GRASS 6.3: v.db.dropcol For GRASS 6.2.3 you can examine that script and do the SQLite trick by hand: http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.db.dropcol Is it possible to put the first 3 ASCII column values to the geometry, and use only the last column as an attribute? another idea is to crop the file to only include the cat and code columns, cut -f1,4 -d',' inputfile.txt outputfile.txt then use db.in.ogr (GRASS 6.3 only) to import the .csv file into SQLite, and then use v.db.connect to connect that database to your vector. (triple-check the cat+codes line up; is there a cat column or is that just sequential order? if so, use seq + paste to add that to the cut'ed code-only file) yet another idea is to do it like v.in.garmin/v.in.gpsbabel scripts, but that may be slow for many many points. I'm using GRASS 6.2.3 and sqlite database. Hamish __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] is it posible?
How about v.overlay? On Thu, Apr 10, 2008 at 8:13 AM, Isabel Alfaro Cardozo [EMAIL PROTECTED] wrote: i want to overlap a poligon layer with a line layer and have GRASS tell me wich lines are in a defined poligon, is it posible to do? wich comand do i have to use? thank you ___ 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.ascii - put1 of 4 columns to 3D point file attribute
Greetings GRASSers: First I'd like to say what a great book the Open Source GIS: A GRASS GIS Approach (3rd edition) is. It is full of great practical and conceptual examples. Well worth the money to anyone who has not purchased it yet! Also a big thanks to the developers and users of GRASS who make it a powerful and amazing GIS. I have an ascii table of lidar data. The columns are x,y,z, and a fourth column containing an integer code of some sort. I have looked at the example in the man page about how to select columns for importing via some shell manipulation of the input ascii file, but I do not think it is applicable to what I'm doing (or perhaps the caffeine boost is not in effect yet). I have also tried various combinations of parameters in v.in.ascii. I would like to import the XYZ to build the geometry for 3D points, and have only Cat and Code in the attribute table. (Code being a column name for the 4th column in the input ASCII). I cant seem to find the combination of column definitions and other parameters to achieve this. One option seems to import them all as x double, y double, z double, code int, and then after the import, drop the x,y,z columns. Is it possible to put the first 3 ASCII column values to the geometry, and use only the last column as an attribute? I'm using GRASS 6.2.3 and sqlite database. Thanks out to anyone with some feedback. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problems with db.execute
I just used this http://grass.gdf-hannover.de/wiki/Sqlite_Drop_Columnexample to drop a column with a SQL transaction in a file. It worked great. Mark On Wed, Apr 9, 2008 at 10:00 AM, Isabel Alfaro Cardozo [EMAIL PROTECTED] wrote: I cant get db.execute to work it seems to be a problem with the sql statement file, does someone has an example? thank you a lot ___ 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.ascii - put1 of 4 columns to 3D point file attribute
Sorry if the problem was unclear. I would like to:
1) use the first 3 columns to create the 3D point geometry, but not put XYZ
values into the table
2) use the 4th column to add a code attribute to the table, and populate
with values from the 4th column of the ascii file
3) have the cat field automagically populated.
4) the desired end result is a 3D point file, with only cat and code
attributes in the table.
Perhaps what I'm trying to accomplish is not necessary, but I'm trying to
keep the DB table small due to the volume of points. For now I'm just
working with 10 of the 5 million.
Here's the file head, there's no header (although it is X,Y,Z,some int
number)
480354.49,1539756.39,16.59,196
the v.in.ascii was:
v.in.ascii -z -n input=57697.txt output=lidar57697 format=point fs=, skip=0
{columns=code int} x=1 y=2 z=3 cat=0
which yeilds:
maximum input row length: 43
maximum number of columns: 4
minimum number of columns: 4
column: 1 type: double
column: 2 type: double
column: 3 type: double
column: 4 type: integer
ERROR number of columns defined (1) does not match number of columns (4)
in input.
Mark
On Wed, Apr 9, 2008 at 10:21 AM, Moritz Lennert
[EMAIL PROTECTED] wrote:
On 09/04/08 14:55, M S wrote:
I would like to import the XYZ to build the geometry for 3D points, and
have only Cat and Code in the attribute table. (Code being a column
name for the 4th column in the input ASCII). I cant seem to find the
combination of column definitions and other parameters to achieve this. One
option seems to import them all as x double, y double, z double, code int,
and then after the import, drop the x,y,z columns. Is it possible to put
the first 3 ASCII column values to the geometry, and use only the last
column as an attribute?
I'm not sure I really understand your problem. Maybe you could send us the
layout of your file (head -2) and the v.in.ascii command you tried.
You need to specify the _column number_ of your X,Y and Z columns with the
x=, y= and z= parameters, the _column number_ of you cat column with the
cat= parameter, and the attribute columns with the columns= parameter.
So if I understand your file correctly it would be something like this:
v.in.ascii -z [...] x=1 y=2 z=3 cat=4 columns=code int
You might also want to use the -b flag, as topology building can lead to
overload if the input data file is too large.
Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] A Note Of Gratitude
I just wanted to drop a quick note to say thanks to everyone for the great contributions to the open source GIS community via GRASS and QGIS and GDAL (and all other associated apps!). Thanks to the developers for building such a solid and useful product, and thanks to the users and community for always being so willing to help others, and provide feedback to developers for enhancements. It truly is a wonderful group to be a part of. For me, having come from another GIS world, open source GIS has been refreshing and most of all fun again. Just wanted to express my gratitude and say thanks for everyone's hard work and willingness to help other users. The advancements with these open source softwares have been completely amazing in the 5 years I have been involved. Thanks to everyone who has made open source GIS a viable and preferable option. These really are cool applications. Running them on Mac and Linux just make it all the more enjoyable. Sincerest thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
