Re: [GRASS-user] v.what.rast sampling cells 5 km to east
On Mon, Jul 8, 2013 at 6:43 PM, Michael Spencer spencer.mik...@gmail.com wrote: Hi, I've a problem with the v.what.rast tool. I imported a vector grid of points with a spacing of 5 km (v.in.ogr) to GRASS, along with 12 rasters (r.in.arc). There is a point in the centre of each raster cell, with some extra points as a buffer around the edge (still on a 5 km grid). Having added extra columns to the point vector file I ran v.what.rast to extract the value of the 12 rasters, in turn, at each point location. Checking the result in the GRASS viewer the tool has appended data from the raster cell 5 km to the east at all locations. It seems that the current region is not properly aligned to the raster and instead shifted by exactly half a cell in east-west direction, which would explain the observed results. Try to run g.region -p align=raster_to_query before using v.what.rast. HTH, Markus M Is this a bug? Has anyone else experienced it? And most importantly - does anyone know how to fix it?! Ta, Michael ___ 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] hydro-flatenning process ?
From a dem file (breaklines), i would like apply hydro-flatenning process. Is it possible to do that with grass? I would like define an hydrologic topology on my DEM. Each cellul of my raster should have a topologic component. My goal is to flatten waterway areas 's values. r.in.xyz http://grass.osgeo.org/grass64/manuals/r.in.xyz.html r.surf.idw http://grass.osgeo.org/grass64/manuals/r.surf.idw.html v.surf.bspline http://grass.osgeo.org/grass64/manuals/v.surf.bspline.html v.surf.rst http://grass.osgeo.org/grass64/manuals/v.surf.rst.html ? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/hydro-flatenning-process-tp5065095p5065707.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] GRASS GIS 6.4.3RC4 released
*Fourth (and last) release candidate of GRASS GIS 6.4.3 with improvements and stability fixes * A fourth release candidate of GRASS GIS 6.4.3 is now available. Source code download: - http://grass.osgeo.org/grass64/source/ - http://grass.osgeo.org/grass64/source/grass-6.4.3RC4.tar.gz Binaries download: - winGRASS 6.4.3RC4 standalone installerhttp://grass.osgeo.org/grass64/binary/mswindows/native/WinGRASS-6.4.3RC4-1-Setup.exe - winGRASS 6.4.3RC4 in OSGeo4W installerhttp://trac.osgeo.org/osgeo4w/wiki/pkg-grass - Arch Linux https://aur.archlinux.org/packages/grass64-rc/ - openSUSE One-Click installerhttp://software.opensuse.org/package/grass - Mac OS X 10.6 Snow leopardhttp://www.public.asu.edu/~cmbarton/files/grass_mac/OSX10.6-snowleopard/ - ... further packages will follow shortly. To get the GRASS GIS 6.4.3RC4 source code directly from SVN: svn checkout http://svn.osgeo.org/grass/grass/tags/release_20130710_grass_6_4_3RC4 *Key improvements* of this release include some new functionality (assistance for topologically unclean vector data), fixes in the vector network modules, fixes for the wxPython based portable graphical interface (attribute table management, wxNVIZ, and Cartographic Composer), fixes in the location wizard for Datum transform selection and support for PROJ.4 version 4.8.0, improvements for selecting the Python version to be used, enhanced portability for MS-Windows (native support, fixes in case of missing system DLLs), and more translations (esp. Romanian). See also our detailed announcement: http://trac.osgeo.org/grass/wiki/Release/6.4.3RC4-News First time users should explore the first steps tutorialhttp://grass.osgeo.org/documentation/first-time-usersafter installation. Release candidate management at http://trac.osgeo.org/grass/wiki/Grass6Planning Please join us in testing this release candidate for the final release. Consider to *donate pizza or beer* for the upcoming GRASS GIS Community Sprint in Prague: http://grass.osgeo.org/donations/ Thanks to all contributors! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] hydro-flatenning process ?
Helmut Kudrnovsky wrote r.in.xyz r.surf.idw v.surf.bspline v.surf.rst None of these, or any of GRASS's other surface interpolation tools that I'm aware of, consider breaklines. Although a feature request was filed 4 years ago: http://trac.osgeo.org/grass/ticket/793 You could probably generate hydro flattened surfaces separately and combine them with the DEM manually using the raster calculator, but unfortunately I don't think there is a one click button. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/hydro-flatenning-process-tp5065095p5065874.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] hydro-flatenning process ?
Jed wrote: None of these, or any of GRASS's other surface interpolation tools that I'm aware of, consider breaklines. Although a feature request was filed 4 years ago: http://trac.osgeo.org/grass/ticket/793 see the v.triangle addon module, http://grasswiki.osgeo.org/wiki/TIN_with_breaklines ticket updated. (breaklines in v.surf.rst would still be awesome :) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GIS 6.4.3RC4 released
Markus Neteler wrote: * ... further packages will follow shortly. if anyone needs .debs for Debian/Squeeze or Wheezy, just let me know. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] region issues using python multiprocessing.Pool()
Thanks again Pietro and Hamish. After looking at the code for use_temp_region(), I believe I was using it incorrectly--I should have called it after setting the region instead of before. With that change, out of 7 tiles (* 8 bands for 56 images to process in the test area), 50 of them completed successfully and the remaining 6 had pixel values ranging from +/- NaN. Since the NaNs sound like another region issue, I followed Hamish's advice and looked at how the mapcalc_start() function was implemented in i.oif module and modified the caclulateTOAR function to process all 8 bands of an image that have the same region at once. This method is nice for the multispectral imagery (56 images completed in under 30 seconds), but unfortunately it won't help when I need to do the pan imagery with its much higher resolution. I think Pietro's method will be helpful here but it will take more time to wrap my head around that implementation. :) Now I need to find out why some bands have reflectances that exceed 1.0 after fixing a bug in my mapcalc equation (forgot to divide by the effective bandwidth in the top of atmosphere radiance calculation)... Thanks, Eric On Thu, Jul 11, 2013 at 5:44 AM, Hamish hamis...@yahoo.com wrote: Eric wrote: Thanks for the responses, I'm looking forward to trying out your suggestion, Pietro. Pygrass looks interesting, but I'm a little confused about its relationship with grass.script. Pietro can certainly explain it better than me, but in general, grass.script works in the traditional way of calling grass modules to do what those grass modules do (think pythonized bash scripts), while pygrass abstracts a lot of that away and pythonizes the grass experience. See: http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction One of the reasons I'm trying to use multiprocessing is because it side steps the GIL issue by not using threads, according to the documentation (http://docs.python.org/2/library/multiprocessing.html). I didn't think the grass.start_command() would use all the available CPUs. I've used multiprocessing with the gdal python api and it made use of all my cpu cores. grass.start_command() will only start one command in one process at a time. For example, i.landsat.rgb starts three parallel processes: one for each of the Red, Green, and Blue bands. So maximum speedup for that part of the module is just under 3x. But it isn't hard to have that launch more to have it use all cores; see the r3.in.xyz.py script and v.surf.icw.py addon script for examples of that. That method only works well with a certain kind of problem, but it offers very low overhead cost when it fits. My worry with splitting up a single loop by rows is that the problem often becomes I/O bound, and the overhead costs are much much larger. But each module has its own characteristics, so by all means, use what works.. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
