[GRASS-user] Extract coordinates of vertices/nodes
Greetings, Being quite in Grass, I am trying to find a way to extract geographic coordinates of vertices and nodes (by the way I am struggling a little to understand the differences between those two concepts) for polygons or lines. Do you have any idea how to proceed? Cheers So.L. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Extract-coordinates-of-vertices-nodes-tp4973423p4973423.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] Re: Extract coordinates of vertices/nodes
Hi Sophie, v.out.ascii format=standard might help. Here is the manual: http://grass.itc.it/grass64/manuals/html64_user/v.out.ascii.html Afterwards you can write a simple script to extract the coordinates from the ascii-output. schorschli -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Extract-coordinates-of-vertices-nodes-tp4973423p4973771.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Extract coordinates of vertices/nodes
On 04/28/2010 12:12 PM, Sophie Leguedois wrote: Greetings, Being quite in Grass, I am trying to find a way to extract geographic coordinates of vertices and nodes (by the way I am struggling a little to understand the differences between those two concepts) for polygons or This might help: http://grass.osgeo.org/wiki/Vectordata lines. Do you have any idea how to proceed? Probably with v.to.points -v Cheers So.L. -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.vol.idw
Hi, I was wondering what happened to the above command in the new releases of GRASS. I am quite sure I did use it in GRASS 5 and possibly early versions of 6 but it seems it got lost somewhere along the road. Is there any reason for this? Does anyone remember in what version of GRASS for Mac it was last present? I am in desperate need to use it to interpolate 3d points of subsoil data for comparison with v.vol.rst. All best Stefania Stefania Merlo Department of Archaeology University of Cambridge United Kingdom sm...@cam.ac.uk “Mi piacerebbe che il mio viaggio fosse ancora lungo e costellato di smarrimenti, si mi piacerebbe vivere per molto tempo e commettere ancora mille errori, mille sbagli, ed anche un certo numero di peccati memorabili”! (Amin Maalouf, Il periplo di Baldassarre) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] osm import
Hamish, In a recent post [1], you said that to import OSM maps, one can use v.in.ogr, but I don't see a driver for OSM maps in ogr. Could you explain ? Thanks ! Moritz [1]http://lists.osgeo.org/pipermail/grass-user/2010-January/054253.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Problem after import using r.in.ascii
Greetings Herbivores, This is the first time that I've created a location and mapset fo my own and I'm trying to import TRMM precipitation data into GRASS using r.in.ascii. I have an existing CSV file that has the headers lat, long and precip. The precipitation is a floating point number to two decimal places. The coordinates in the CSV file define the centre of a quarter degree square. The first set of coordinates in the file is -19.625,15.875. Becuase the TRMM data defines the centre of the square, I subtracted 0.125 from the first set of coordinates to get the north-west corner of the raster. And I added 0.125 to the last coordinate in the CSV file, which is -34.875,34.125, to get the south-east corner of the raster. In the CSV file, the latitude stays constant for 74 rows while the longitude increments in quarter degree steps. The whole file contains 4588 rows, so a grid of the data should have 74 rows and 62 columns, right? So I reformatted the data to 74 rows and 62 columns and added the header: north: -19.5 south: -35.0 east:15.75 west:34.25 rows:74 cols:62 null:-319.99 The output of g.region -p is: projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 18S south: 36S west: 15E east: 35E nsres: 0:15 ewres: 0:15 rows: 72 cols: 80 cells: 5760 I then imported the reformatted file using the command: r.in.ascii -f input=3B42RT.2010032409.6.bin.sa.grass\ output=2010032409.6.precip \ title=Precipitation 2010032409.6\ mult=1.0 or read from header nv=* or read from header When imported, I get two thin strips of data on the sides of the image. The raster shouldn't contain any nulls (the text file doesn't contain the value -319.99), so something is wrong. r.info gives a very strange resolutions: | Type of Map: raster Number of Categories: 255 | Data Type:FCELL | Rows: 74 | Columns: 62 | Total Cells: 4588 |Projection: Latitude-Longitude |N: 19:30SS:35S Res: 0:12:34.054054 |E: 15:45EW: 34:15E Res: 5:30:29.032258 | Range of data:min = 0.00 max = 7.47 Can someone perhaps help me to see what's happening here? Thanks Hanlie ___ 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)
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
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
[GRASS-user] i.atcorr returns all NULL values
Hello, I'm using i.atcorr to perform atmospheric corrections on Landsat 5 TM data and something peculiar seems to happen arbitrarily to some of the data. For the most part everything works fine, but for some of the bands the result is a raster layer that is filled with nothing but NULL values. For example, I have images from 3 dates over the same area. All the layers are integer and scaled from 0 - 255, and the elevation layer I'm using is also integer. All bands from the first date and the last date run through i.atcorr with no problems, as do bands 3, 4, 5, 7 from the middle date. However, bands 1 and 2 from the middle date return all NULLs. I have tried many things, including running i.atcorr on a small subset of the band (same result), changing the date by a day or two in the* *icnd.txt file (same result), and changing the band to TM5 band 3 in the icnd.txt file (this ran normally). I can't figure out why bands 1 and 2 would run normally on two of my dates and why bands 3-5,7 would run on this particular date yet bands 1 and 2 result in the NULL values. Anyone else have this problem and any clues as to why i.atcorr is doing this? Any help would be greatly appreciated. Here is the text of my icnd.txt file for band 1: 7 6 23 15.966 -84.165 44.587 2 1 14.16 -0.262 -1000 25 The command I'm running: i.atcorr -r -o iimg=peak_b1_...@mich ialt=elevat...@michicnd=atcorr_paramfiles/atcorr_peak_B1.txt oimg=peak_B1_atm_corr I'm using GRASS version 6.4.0RC6 Thanks, Brian ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Extract coordinates of vertices/nodes
2010/4/28 Micha Silver mi...@arava.co.il On 04/28/2010 12:12 PM, Sophie Leguedois wrote: Greetings, Being quite in Grass, I am trying to find a way to extract geographic coordinates of vertices and nodes (by the way I am struggling a little to understand the differences between those two concepts) for polygons or This might help: http://grass.osgeo.org/wiki/Vectordata In short, vertices are all the points that make up a line, a line may consist of one or more vertices. In GRASS, nodes are the start and end points of a line, so each line is linked to two nodes. These nodes are used internally to maintain vector topology: http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Section: Vector model and topology lines. Do you have any idea how to proceed? Probably with v.to.points -v There is some useful information in the v.to.points manual about how to link the extracted points to the original lines. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] New version of the r.landscape.evol.py Landscape Evolution module uploaded to the GRASS Addons repository.
Isaac Ullah wrote: [The new r.landscape.evol.py] takes advantage of the advanced MFD flow routing capabilities of the newly updated r.watershed module, which produced more accurate stream networks, and flow accumulation values. Nice, but r.landscape.evol.py works only with the GRASS 6.5 version of r.watershed, otherwise r.terraflow must be used. Contrary to the 6.5 version, the 6.4 version of r.watershed only supports SFD (D8) and only integer DEMs, floating point DEMs are truncated to integer(, and it's slower and uses more memory). Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] New version of the r.landscape.evol.py Landscape Evolution module uploaded to the GRASS Addons repository.
Isaac Ullah wrote: Yes, this is certainly true. We have kept backwards compatibility with a flag to use r.terraflow if the user has GRASS 6.4 or less. GRASS 6.4 is the next stable release for some time to come, thus new addons for GRASS 6.x should IMHO be tailored for 6.4. Either you advocate the backporting of the 6.5 version of r.watershed to 6.4 ;-) or you make r.terraflow the default, with a flag indicating to use r.watershed. Anyway, IMHO, newly updated addons should run in 6.4 with the default settings. Markus M Markus Metz wrote: Isaac Ullah wrote: [The new r.landscape.evol.py] takes advantage of the advanced MFD flow routing capabilities of the newly updated r.watershed module, which produced more accurate stream networks, and flow accumulation values. Nice, but r.landscape.evol.py works only with the GRASS 6.5 version of r.watershed, otherwise r.terraflow must be used. Contrary to the 6.5 version, the 6.4 version of r.watershed only supports SFD (D8) and only integer DEMs, floating point DEMs are truncated to integer(, and it's slower and uses more memory). Markus M -- Isaac I Ullah, M.A. Archaeology PhD Candidate, ASU School of Evolution and Social Change Research Assistant, Mediterranean Landscape Dynamics Project *** isaac.ul...@asu.edu ul...@archaeologist.com http://www.public.asu.edu/~iullah *** ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem after import using r.in.ascii
Hanlie Pretorius wrote: I have an existing CSV file that has the headers lat, long and precip. The precipitation is a floating point number to two decimal places. The coordinates in the CSV file define the centre of a quarter degree square. The first set of coordinates in the file is -19.625,15.875. Becuase the TRMM data defines the centre of the square, I subtracted 0.125 from the first set of coordinates to get the north-west corner of the raster. And I added 0.125 to the last coordinate in the CSV file, which is -34.875,34.125, to get the south-east corner of the raster. This seems wrong; positive-X is east, positive-Y is north, so you should be adding to north and east, subtracting from south and west. In the CSV file, the latitude stays constant for 74 rows while the longitude increments in quarter degree steps. The whole file contains 4588 rows, so a grid of the data should have 74 rows and 62 columns, right? So I reformatted the data to 74 rows and 62 columns and added the header: north: -19.5 south: -35.0 east: 15.75 west: 34.25 Positive-X is east, so either east and west are the wrong way around, or they should both be negative, or this represents a span of 341.5 degrees. rows: 74 cols: 62 null: -319.99 The output of g.region -p is: projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 18S south: 36S west: 15E east: 35E Here, east and west have been swapped relative to what you say above. nsres: 0:15 ewres: 0:15 rows: 72 cols: 80 cells: 5760 I then imported the reformatted file using the command: r.in.ascii -f input=3B42RT.2010032409.6.bin.sa.grass\ output=2010032409.6.precip \ title=Precipitation 2010032409.6\ mult=1.0 or read from header nv=* or read from header When imported, I get two thin strips of data on the sides of the image. The raster shouldn't contain any nulls (the text file doesn't contain the value -319.99), so something is wrong. r.info gives a very strange resolutions: | Type of Map: raster Number of Categories: 255 | Data Type:FCELL | Rows: 74 | Columns: 62 | Total Cells: 4588 |Projection: Latitude-Longitude |N: 19:30SS:35S Res: 0:12:34.054054 |E: 15:45EW: 34:15E Res: 5:30:29.032258 The west edge is east of the east edge, resulting in a span of 341.5 degrees. 341.5 / 62 = 5.508064516129032 = 5:30:29.032258. | Range of data:min = 0.00 max = 7.47 Can someone perhaps help me to see what's happening here? East and west are swapped. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] New version of the r.landscape.evol.py Landscape Evolution module uploaded to the GRASS Addons repository.
Le 27/04/2010 23:59, Isaac Ullah a écrit : Dear GRASS users/developers, I'm happy to announce that the Mediterranean Landscapes Dynamics Project has released a brand new version of our landscape evolution script r.landscape.evol.py. It can be downloaded from the GRASS ADDONS SVN Repository in the LandDyn directory ( http://trac.osgeo.org/grass/browser/grass-addons/LandDyn). r.landscape.evol.py calculates erosion and deposition values for a region (DEM) given climactic (rainfall) and environmental (vegetation and soils) conditions. It can iteratively calculate these values over multiple time-steps, and will produce new surface DEM's for each time step (using the previous DEM as input in the next time step). r.landscape.evol.py uses process-based transport equations to calculate erosion/deposition differently for different parts of the landscape (ie. flat areas, hillslopes, mass movement, small channels, streams). Hi, Could you give me more precisions on the recursive aspect and its limits, for exemple do you think that your model could be applied to a nord europe hydrologic setting ? The testcase shown on your website is a wadi bordering the Jordan rift valley which is quite a different beast. I'm also curious about how far back in time you did push your experiment and on the way you did extrapolate the neolithic period settings. Regards, MORREALE Jean Roc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] New version of the r.landscape.evol.py Landscape Evolution module uploaded to the GRASS Addons repository.
The reality is that this kind of modeling works well and is accurate for the new MFD routine in r.watershed but does not work nearly as well with r.terraflow or with SFD in r.watershed. Helena originally proposed this for r.flow, which is how we started out several years ago. However, as we developed this modeling script, we learned that a full hydrology model worked better than the flow lines information generated by r.flow. So we switched to r.terraflow. However, the routines of r.terraflow produced numerous 'artifacts' in the way of anomalous spikes and pits that could self-amplify over multiple iterations. We used smoothing routines to get rid of these. This worked OK, but affected both accuracy of estimating erosion/deposition and the speed of calculation (median smoothers take awhile to run). We have a paper coming out that uses this version of r.landscape.evol (the previous version that is still in addons and downloadable). The old version does what it can to work around the limitations of the watershed routines that are now standard in GRASS 6.4 Running with the new r.watershed and MFD, however, does not create the kind of artifacts we saw with r.terraflow and does not require post facto smoothing. This makes it much faster and more accurate in its erosion/deposition estimates. Also, the smoothing never was able to completely eliminate the terraflow artifacts, but these simply don't exist with r.watershed and MFD. I guess I don't see the point of dumbing down the new version of the script to work with GRASS C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Apr 28, 2010, at 12:02 PM, Isaac Ullah wrote: I suppose that is true from a programmatic point of view, but from scientific point of view, the fact is that MFD makes the module so much more useful that it's pointless to run it with r.terraflow (or SFD r.watershed). Actually, I imagine that including the flag to run r.landscape.evol.py with SFD terraflo/r.watershed is actually being disingenuous, as I'm not even sure that the stream erosion equation can even make valid output using SFD (I need to test this, but my feeling is that it will produce overly-large estimates). I guess that means, then, that I am advocating for backporting of 6.5 version of r.watershed to 6.4. Why put out the next stable version of GRASS with clearly inferior capabilities? This IMO is simple guaranteeing the quick obsolescence of the stable GRASS version for anyone actually interested in doing state-of-the-art, cutting-edge, robust research with it. It would make much more sense to me (as a scientist who uses GIS as a tool) to include the best available version of modules in a new release. I understand that one does not want to break any dependencies (and thus one should generally try to avoid changing the number/arrangement of module inputs), but surely this can be done for situations where the benefits so greatly outweigh these costs? I imagine that only myself and perhaps a few other scripters will have dependencies on r.watershed, and we can easily amend our scripts to be compatible... Cheers, Isaac On Wed, Apr 28, 2010 at 11:30 AM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Isaac Ullah wrote: Yes, this is certainly true. We have kept backwards compatibility with a flag to use r.terraflow if the user has GRASS 6.4 or less. GRASS 6.4 is the next stable release for some time to come, thus new addons for GRASS 6.x should IMHO be tailored for 6.4. Either you advocate the backporting of the 6.5 version of r.watershed to 6.4 ;-) or you make r.terraflow the default, with a flag indicating to use r.watershed. Anyway, IMHO, newly updated addons should run in 6.4 with the default settings. Markus M Markus Metz wrote: Isaac Ullah wrote: [The new r.landscape.evol.py] takes advantage of the advanced MFD flow routing capabilities of the newly updated r.watershed module, which produced more accurate stream networks, and flow accumulation values. Nice, but r.landscape.evol.py works only with the GRASS 6.5 version of r.watershed, otherwise r.terraflow must be used. Contrary to the 6.5 version, the 6.4 version of r.watershed only supports SFD (D8) and only integer DEMs, floating point DEMs are truncated to integer(, and it's slower and uses more memory). Markus M -- Isaac I Ullah, M.A. Archaeology PhD Candidate, ASU School of Evolution and Social Change Research Assistant, Mediterranean Landscape Dynamics Project *** isaac.ul...@asu.edu
