Re: [GRASS-user] surface interpolation with breaklines
Thanks you Antonio, in my present case, half a cell offset did not matter in any way, but I notice your modification. Your script might be well appreciated in the community My suggestion was to complete the v.to.rast module so it could handle 3d geometries (3d polylines and faces), unfortunately I am only good at scripting in bash (my knowledge of python and C are too poor to pretend doing that). Bye, Vincent. Le mardi 11 février 2014 à 09:05 +0100, antonio...@libero.it a écrit : Hello Vincent, Excuse me for my bad English. Certainly you can cite me and my job. Attention: the program considers as reference the angle in low at left of the cell and not the central point. Reading the documentation of Grass found in net, I don't understand what reference is used for the cells. If the reference of the cell is its central point, the lines 115 and 116 of the script become: x = xref + j * xres + 0.5 * xres y = yref + i * yres + 0.5 * yres If you find useful information on the matter, please update me. Good job, Antonio Alliegro Le dimanche 09 février 2014 à 16:24 +0100, Vincent Bain a écrit : Le dimanche 09 février 2014 à 15:55 +0100, Maciej Sieczka a écrit : W dniu 09.02.2014 13:17, Vincent Bain pisze: Perhaps a wiser solution would be to v.to.point (i) contour lines, (ii) breaklines, then merge them in a single raster an run r.surf.nnbathy. There is no need to v.to.points isolines before rasterizing them for nnbathy. Unless you want to generalize the contour lines on purpose, e.g. to minimize the staircase artifacts in the output raster map. oops, sorry you are right : I forgot to say I first turn isolines to points (v.to.points, with the vertices option). As to breaklines, if these are linear features that indicate surface discontinuity and have no elevation attribute, nnbathy has no use of them (which you know already). If they are vector isolines, just rasterize them straight away. If these are vector 3d lines, you'd need to rasterize them interpolating their elevation at each cell of the output raster map, which v.to.rast can't do. Here is my mistake. I have a 3d breaklines vector, and I expected v.to.rast being able to (i) get vertices z values and (ii) interpolate z between vertices... At least it couldn't a few years ago when I tried it. This could probably be approximated with something like v.to.points -v -i dmax=raster DEM resolution + v.to.rast, but that's suboptimal. Finally I found on the web a custom solution based on a nice little python script named tin2raster, you can find it at the address bellow. I tried to contact Antonio, the guy who wrote it, but did not get a reply : http://digilander.libero.it/antonioall/python_tin2raster.html That tool utilizes Vect_tin_get_z (http://grass.osgeo.org/programming6/tin_8c.html), which claims to be able to perform such interpolation, not only along a linear 3d feature, but on faces as well. Nice. I don't know, but I'd like v.to.rast to provide such feature too. understanding c libs content is definitely beyond my skills ! but in the end, having a v.to.rast module able to handle 3d polylines and faces would be really nice. Best, Vincent. ___ 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] Hydrology modules in GRASS 6/7
Dear all, In a little watershed-project, some of my colleagues and I are testing and experimenting with the hydrological modules in GRASS 7 at the moment. In general we are very satisfied. Amazingly, r.watershed in GRASS 7 managed to calculate flow accumulation and drainage direction for very big data (150,000x120,000 pixels) in a few days processing. In that context I had a look on the available documentation and tutorials on the hydrological modules in GRASS. There are some nice tutorials on how to perform certain watershed analyses (http://grasswiki.osgeo.org/wiki/Creating_watersheds) or an overview over existing modules (http://grasswiki.osgeo.org/wiki/Hydrological_Sciences). Especially promising looked: http://grasswiki.osgeo.org/wiki/R.stream.* and http://geomorphometry.org/system/files/promo_rstream.pdf (for the latter unfortunately only a promo-version is available). However, what I was missing a bit was, the rationale behind the different modules and recommendations on how to chain them or choose between possible alternatives (especialy since GRASS offers so many hydrological modules). For example: In what cases should I use r.carve, and if I use it, do I have to fill the terrain model in advance (given that a stream for example crosses a sink) When would it be advisable to use r.water.outlet and when r.stream.basin or r.basin (what module performs better for what purpose / analysis context)? Are there possibly deprecated/outdated modules (e.g. r.fill.dir)? Are there reasons for using r.terraflow (and not r.watershed, given that r.watershed is capable of analyzing bigger datasets than r.terraflow) and what are they? I am not sure if the project I am working on has enough budget for testing the effect of (some) different approaches systematically and updating the GRASS wiki in that direction. If you consider it useful and appropriate (and if we find something useful) I should try to allocate some resources in that direction. Still, I guess developers and more experienced users of the hydrology tools already know quite a lot about pros and cons of the different modules (and approaches for using them). Therefore I would like to ask if a) I overlooked important documentation, b) others are interested in updating / improving the wiki in that direction too, and c) who can and would like contribute to collecting existing experience / conducted projects in this regards... What do you think? Cheers Stefan P.S.: Maybe there is also a difference if one uses GRASS6 or GRASS7? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRIB2 r.in.gdal problem
I’m trying to import some GRIB2 data into GRASS (6.4.3 on a Mac) and am having a problem with the range of the latitude coordinates. I’m working with the following file: http://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2014021112/gfs.t12z.master.grbf72.10m.uv.grib2 I used gdal_translate to create a GeoTiff file, but when I try to import it into a lat/lon location I get the following: GRASS 6.4.3 (GFS_from_grib):~ r.in.gdal input=gfs.t12z.master.grbf72.10m.uv.tif output=gfs WARNING: Datum unknown not recognised by GRASS and no parameters found Projection of input dataset and current location appear to match WARNING: G_set_window(): Illegal latitude for North Here is the output from gdalinfo: lees-mbp:GFS Lee$ gdalinfo gfs.t12z.master.grbf72.10m.uv.tif Driver: GTiff/GeoTIFF Files: gfs.t12z.master.grbf72.10m.uv.tif gfs.t12z.master.grbf72.10m.uv.tif.aux.xml Size is 720, 361 Coordinate System is: GEOGCS[Coordinate System imported from GRIB file, DATUM[unknown, SPHEROID[Sphere,6371229,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-0.250,90.250) Pixel Size = (0.500,-0.500) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( -0.250, 90.250) ( 0d15' 0.00W, 90d15' 0.00N) Lower Left ( -0.250, -90.250) ( 0d15' 0.00W, 90d15' 0.00S) Upper Right ( 359.750, 90.250) (359d45' 0.00E, 90d15' 0.00N) Lower Right ( 359.750, -90.250) (359d45' 0.00E, 90d15' 0.00S) Center ( 179.750, 0.000) (179d45' 0.00E, 0d 0' 0.01N) Band 1 Block=720x1 Type=Float64, ColorInterp=Gray Description = 10[m] HTGL=Specified height level above ground Metadata: GRIB_COMMENT=u-component of wind [m/s] GRIB_ELEMENT=UGRD GRIB_FORECAST_SECONDS=259200 sec GRIB_PDS_PDTN=0 GRIB_PDS_TEMPLATE_NUMBERS=2 2 2 0 96 0 0 0 1 0 0 0 72 103 0 0 0 0 10 255 0 0 0 0 0 GRIB_REF_TIME=139212 sec UTC GRIB_SHORT_NAME=10-HTGL GRIB_UNIT=[m/s] GRIB_VALID_TIME=1392379200 sec UTC Band 2 Block=720x1 Type=Float64, ColorInterp=Undefined Description = 10[m] HTGL=Specified height level above ground Metadata: GRIB_COMMENT=v-component of wind [m/s] GRIB_ELEMENT=VGRD GRIB_FORECAST_SECONDS=259200 sec GRIB_REF_TIME=139212 sec UTC GRIB_SHORT_NAME=10-HTGL GRIB_UNIT=[m/s] GRIB_VALID_TIME=1392379200 sec UTC So it’s showing the north and south bounds of 90.25 N and -90.25 S. I’m almost positive that this would be the values of the edges of the cells and that the cells are centered at 90 N and 90 S. Is there a way to import this data? Thanks, Lee ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
