Re: [GRASS-user] passing raster map to Python object
Hi Hamish, Thanks for your encourager's email. I started to play with numpy for other purposes, but I will give a look in deep for this. If I get success I will be happy report it here. bests milton 2009/8/12 Hamish hamis...@yahoo.com Milton Cezar Ribeiro wrote: I am building a simulation python code that read a raster maps on grass mapset. As my maps is not so large (512x512 pixels) I dump it on a text file (using r.out.ascii), after I read the text file on python, parse it using a function that I wrote, and after create a matrix-like object on Python. I would like to know if I can read my raster map on python wihout save it on external text file. Case yes, a short example are welcome. you might look at NumPy http://numpy.scipy.org/ + NumPtr python extension. NumPtr can be found in the swig/python/ dir in the grass source code. (also examples/m.distance + rasteraccess.py there) NumPy is also used by the wxGUI profile tool. SciPy is another thing to check out. please post back to the list with what you learn :) if you succeed maybe add a page to the grass wiki with steps? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] passing raster map to Python object
Milton Cezar Ribeiro wrote: Thanks for your encourager's email. I started to play with numpy for other purposes, but I will give a look in deep for this. If I get success I will be happy report it here. it should work. one thing, be sure to translate NULL cells to numpy.nan, e.g. import numpy as np x = np.array([[1, 2, 3], [4, 5, 6]], np.float64) x array([[ 1., 2., 3.], [ 4., 5., 6.]]) x[0,1] 2.0 x[0,1] = np.nan x array([[ 1., nan, 3.], [ 4., 5., 6.]]) see swig/python/examples/rasteraccess.py for reading raster row by row. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interactive flood simulation
Thanks everyone for replies. Markus Neteler, Will post a screen-shot and a small description today. On Tue, Aug 11, 2009 at 8:38 PM, Markus Netelernete...@osgeo.org wrote: On Tue, Aug 4, 2009 at 2:21 PM, Pavel Iacovleviacovlev.pa...@gmail.com wrote: Good day, I wrote a simple web flood simulation application. Posting here the source code, maybe it will be useful for someone who wants to use GRASS from PHP. Example: http://flood.iap.md/ Source code: http://code.google.com/p/grass-flood/source/browse/#svn/trunk PHP Class for connecting to grass application: http://code.google.com/p/grass-flood/source/browse/trunk/Grass.php The example features GRASS, PHPMapscript, OpenLayers, PHP and how they can work together, based on http://grass.osgeo.org/wiki/GRASS_and_PHP Very nice! Please submit a screenshot plus short explanation to http://gallery.osgeo.org/ Markus -- http://iap.md, The future is open ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.select relate
Hi, does anyone know, how the operator relate is meant in v.select (grass6.5)? Only explanation in module description is: relate - feature A is spatially related to feature B And a parameter relate is required, which isn't in description too. Cheers, Achim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.li help
Markus Neteler ha scritto: My result, upper left corner only, is attached (Mandriva Linux, 64bit). Visually it looks ok to me. I'm also having problems with r.li: r.li.shannon map=uso conf=latignano_5 output=provaln WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1954]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1953]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1952]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1951]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1950]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1949]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1948]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1947]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1946]: unable to open mask ... continue without!!! WARNING: Unable to open header file for raster map @(null) CHILD[pid = 1945]: unable to open mask ... continue without!!! Segmentation fault Debian ustable, 64 bit. Any hint appreciated. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE:re: [GRASS-user] Very high resolution topographic map of Europe: need help and advices
Dear Markus, Thank you s much for your response; it provided me with valuables hints - but also with new questions. First, following your avice, I finally decided to compile the new GRASS6.4rc5. Having an amd64 cpu, there war no binary available; so I had to do the job myself. Let's face it: manual configuration is a pain for a newcommer like me, but once the ./configure script shows the long awaited final recap, the make command - although quite long - runs withouth a hitch. I reminds me of good ol' freebsd days, although we had a lot more troubles finishing compilation without errors: great job guys ! But the resulat was worth it; I don't know if it is the work you've done for the last few years, or the gcc optiomization flags (or perhaps both of it), but the resulting grass64 runs like a fireball compared to my old 6.2 bin provided by the Ubuntu repos. Again: great job ! Only now I fully understand what you meant by it is so far the only convincing software for GIS number crunching. But let's go back to the topic: my high-resolution topographic map of Europe. Thanks to your advices, the production outline has changed to this: 1. Merge the cgiar TIFs (AND NOT THE GRASS RASTERS IF I GOT THIS CORRECTLY) thanks to gdalwrap command. In what projection does this command work ? Is it possible to wrap the TIF directlly in my lcc projection ? 2. Add image pyramids with gdaladdo ( I frankly do not underdand this one at all; what does it mean ?) 3. Shaded relief: I don't know your gdalhillshade command at all. Does it produce the same results as the r.shaded.relief I was planning to use ? Can you set the illumination angle with gdalhilshade ? 4. Re-gdaladdo for the shaded tif. 5. Import in GRASS and checkout results. If I'm right, I will have two layers at this point, one with the relief colors, one with the shadings. 6. Coastlines and Rivers. I was planning to use SWBD(coastlines and main rivers) and VLMAP0 Data (for the secondary rivers). Here again, you provide me with a complete new set of tools: r.external/r.terraflow/r.mapcalc/. What is the general idea behind ?I checked the man pages, but I don't really understand how to use them for my purpose. My plan was to import the shapefile into the right projection with rvin.ogr, and than export svg files for rework BEFORE joining the river layer and the topographic layers; but perhaps your way, once I understand it, is more efficient. 7. Export the shaded topography with r.out.png in one big png. Do I need two files (one containing the shadings, one with the relief colors) ? 8. Merge topography and hydrography layers in GIMP. Could you (or anyone interested) please have a look a this ? Again: thanks you very much for your time, regards, Felix For some time now, I'm following sort of a personal objective to create the most precise (=high resolution) topographic map of Europe allowed by my comp (Xubuntu 9.04, AMD64, 3Gb RAM, 300+ HD space). Starting from the very scratch, I had to learn about DEMs and GIS/maptools - and I'm still not confortable with all the technicy behind. Fact is that the best data set available to serve my purpose seems to be the cgiar interpolated srtm3 geodata (no license problem here, since it is aimed for pure personal use) which has to somehow be translated into a big jpeg or png file. Here you can use gdalwarp to merge all files into a big one. Enjoy wildcards to do that in one line: gdalwarp srtm_*.tif cgiar_srtm3_LL.tif A big file is created. Then don't miss to add image pyramids: gdaladdo srtm3_LL.tif 2 4 8 16 32 64 and you can open a file of several GB in no time with QGIS for example. I posted some GDAL tricks here: http://gfoss.blogspot.com/2008/06/gdal-raster-data-tips-and-tricks.html (if you want OGR for vectors, check: http://gfoss.blogspot.com/2008/06/ogr-vector-data-tips-and-tricks.html ) ... The big problem happened to be the river data, since GSHHS provides only limited amount and precision of side-rivers, which resulted in chains of straight lines scattered all over a giant map, even after vectorization: it was a no-go. No idea, I didn't try GMT so much. And then, a few days ago, I discovered nasa SWBD data and WMAP0, which seem to be of much higher resolution, linked to a nice GRASS GIS tutorial on the french wikipedia. I immedialely dug into this new software, quite complicated I must admit, but very powerful. We hope you took the GRASS 6.4 version - even if still called release candidate it is used by many in production. Myself, I am doing heavy computations with it and it is so far the only convincing software for GIS number crunching :-) I figured out how to import GeoTiff data into GRASS Raster files, Hint: from GRASS 6.4 onwards you can use r.external to avoid import but to just link an external file into GRASS. Nice when registering 30GB of orthophotos in a few minutes... For newcomers QGIS is a nice interface to GRASS, too, since it comes with
Re: re: [GRASS-user] Very high resolution topographic map of Europe: need help and advices
On Wed, Aug 12, 2009 at 4:06 PM, Felix Schalckfelix.scha...@gmail.com wrote: Dear Markus, Thank you s much for your response; it provided me with valuables hints - but also with new questions. Sure: things at that level aren't naturally obvious. First, following your avice, I finally decided to compile the new GRASS6.4rc5. Having an amd64 cpu, there war no binary available; so I had to do the job myself. Let's face it: manual configuration is a pain for a newcommer like me, You mean to find all dependences? We have collection some help in the Wiki: http://grass.osgeo.org/wiki/Compile_and_Install but once the ./configure script shows the long awaited final recap, the make command - although quite long - If you have a dual/multi-core CPU, you can use make -j2 make -j4 or so to be much faster (I always use make -j4). runs withouth a hitch. I reminds me of good ol' freebsd days, although we had a lot more troubles finishing compilation without errors: great job guys ! But the resulat was worth it; I don't know if it is the work you've done for the last few years, or the gcc optiomization flags (or perhaps both of it), but the resulting grass64 runs like a fireball compared to my old 6.2 bin provided by the Ubuntu repos. Again: great job ! Fantastic! Only now I fully understand what you meant by it is so far the only convincing software for GIS number crunching. But let's go back to the topic: my high-resolution topographic map of Europe. Thanks to your advices, the production outline has changed to this: 1. Merge the cgiar TIFs (AND NOT THE GRASS RASTERS IF I GOT THIS CORRECTLY) thanks to gdalwrap command. In what projection does this command work ? Is it possible to wrap the TIF directlly in my lcc projection ? I tried that yesterday and did NOT have luck. I would do it two-pass, even if it consumes twice as much space temporaneously: a) gdalwarp: all into one file, keeping the projection (mosaicking) b) gdalwarp: reproject to LCC (note that there are EU LCC and others). Use your preferred resampling method (gdalwarp offers several). Perhaps I got something wrong and you can do it in one step as well. 2. Add image pyramids with gdaladdo ( I frankly do not underdand this one at all; what does it mean ?) OK, it means that map copies at lower to much lower resolution are stored in the GeoTIFF (or different format which supports pyramids) file. When then opening with QGIS, Mapserver etc, it takes advantage of that and speeds up in an impressive way the visualization. Of course the file size increases. Example: I take world natural earth 250m which is huge; to cover Europe you need to download 4 tiles = 8 GB. I added pyramids with gdaladdo and now I am able to open these huge 4 tiles in no time in one step with QGIS. It's a convenience. 3. Shaded relief: I don't know your gdalhillshade command at all. Does it produce the same results as the r.shaded.relief I was planning to use ? Can you set the illumination angle with gdalhilshade ? Yes. I realise that it is called gdaldem now. http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdaldem.cpp http://gdal.org/gdaldem.html 4. Re-gdaladdo for the shaded tif. yes. 5. Import in GRASS and checkout results. If I'm right, I will have two layers at this point, one with the relief colors, one with the shadings. Right (say, one is the relief [colors are optional], the other the shadings). You can use d.his or r.his to make a nice shaded colorized terrain map, something like this: http://grass.osgeo.org/grass60/screenshots/images/etopo2_grass_laea_9_48N_0E.jpg 6. Coastlines and Rivers. I was planning to use SWBD(coastlines and main rivers) and VLMAP0 Data (for the secondary rivers). Here again, you provide me with a complete new set of tools: r.external/r.terraflow/r.mapcalc/. What is the general idea behind ? r.external you would use in step 5. Instead of r.in.gdal. r.terraflow/r.mapcalc you may forget since I didn't understand that you would take the rivers as vector maps (I thought you wanted to extract them from the DEM). I checked the man pages, but I don't really understand how to use them for my purpose. My plan was to import the shapefile into the right projection with rvin.ogr, v.in.ogr (or v.external). and than export svg files for rework BEFORE joining the river layer and the topographic layers; but perhaps your way, once I understand it, is more efficient. Not sure (since I was confused :). 7. Export the shaded topography with r.out.png in one big png. Do I need two files (one containing the shadings, one with the relief colors) ? If you do the color shading in GRASS, then you need to export only one file. 8. Merge topography and hydrography layers in GIMP. Yes, sounds reasonable. Please consider to document your steps in the GRASS Wiki, it could be useful in future for others. Good luck Markus ___ grass-user mailing list
Re: [GRASS-user] r.li help
I did a little crude debugging yesterday (G_message) and found it
failed for me in daemon.c, line 626 / nextArea()
else {
return next(g, m);
}
But all this tells me is that at this point the mask name is missing,
not where it was lost.
I didn't have more time to poke around more.
Note: bug report at http://trac.osgeo.org/grass/ticket/718
On Aug 12, 2009, at 9:34 AM, Markus Neteler wrote:
On Wed, Aug 12, 2009 at 3:38 PM, Paolo
Cavallinicavall...@faunalia.it wrote:
Markus Neteler ha scritto:
My result, upper left corner only, is attached (Mandriva Linux,
64bit).
Visually it looks ok to me.
I'm also having problems with r.li:
r.li.shannon map=uso conf=latignano_5 output=provaln
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1954]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1953]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1952]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1951]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1950]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1949]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1948]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1947]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1946]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map @(null)
CHILD[pid = 1945]: unable to open mask ... continue without!!!
Segmentation fault
Debian ustable, 64 bit.
Any hint appreciated.
I see three options:
- use the debugger
http://grass.osgeo.org/wiki/GRASS_Debugging#Using_GDB
- otherwise fill the source code with G_debug() statements to figure
out
where it fails (needs recompilation obviously)
- grant access to a machine where it fails, hoping that a GRASS
developers tracks it down for you :)
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/
[Trillian] What are you supposed to do WITH a maniacally depressed
robot?
[Marvin] You think you have problems? What are you supposed to do if
you ARE a maniacally depressed robot? No, don't try and answer, I'm
50,000 times more intelligent than you and even I don't know the
answer...
- HitchHiker's Guide to the Galaxy
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: re: [GRASS-user] Very high resolution topographic map of Europe: need help and advices
2009/8/12 Markus Neteler nete...@osgeo.org: On Wed, Aug 12, 2009 at 4:06 PM, Felix Schalckfelix.scha...@gmail.com wrote: Dear Markus, Thanks to your advices, the production outline has changed to this: 1. Merge the cgiar TIFs (AND NOT THE GRASS RASTERS IF I GOT THIS CORRECTLY) thanks to gdalwrap command. In what projection does this command work ? Is it possible to wrap the TIF directlly in my lcc projection ? I tried that yesterday and did NOT have luck. I would do it two-pass, even if it consumes twice as much space temporaneously: a) gdalwarp: all into one file, keeping the projection (mosaicking) b) gdalwarp: reproject to LCC (note that there are EU LCC and others). Use your preferred resampling method (gdalwarp offers several). Perhaps I got something wrong and you can do it in one step as well. I immediately tried this, and ran into following problem: $gdalwarp srtm_*.tif europe_all_srtmV4_cgiar_default.tif Creating output file that is 6P x 36000L. ERROR 6: A 6 pixels x 36000 lines x 1 bands Int16 image would be larger than 4GB but this is the largest size a TIFF can be. Creation failed. If I understand this correctly, I don't have a choice here, and must reproject the whole thing while pasting it. So I computed this command: $gdalwarp -s_srs epsg:4326 -t_srs +proj=lcc +lat_1=47 +lat_2=41 +lat_0=53 +lon_0=12 +x_0=22.0 +y_0=15.0 +ellps=WSG84 +units=m +no_defs -tr 93 93 -r bilinear srtm_*.tif europe_all_srtmV4_cgiar_93m_LCC.tif It seems to work (at least a 3.6Gb TIF file is created in the right directory), but takes FOREVER (eg. the 2 first tiles took about 50min, and I have 56 tiles to be merged...). Strange thing is that neither the cpu nor the RAM is being used at full extend. The r.patch tool provided by GRASS went much faster. Any idea here to speed up things ? Would lowering the resolution (186m would be an option) help ? 2. Add image pyramids with gdaladdo ( I frankly do not underdand this one at all; what does it mean ?) OK, it means that map copies at lower to much lower resolution are stored in the GeoTIFF (or different format which supports pyramids) file. When then opening with QGIS, Mapserver etc, it takes advantage of that and speeds up in an impressive way the visualization. Of course the file size increases. Example: I take world natural earth 250m which is huge; to cover Europe you need to download 4 tiles = 8 GB. I added pyramids with gdaladdo and now I am able to open these huge 4 tiles in no time in one step with QGIS. It's a convenience. Thank you very much for the clear explanation. Indeed, this seems a very nice option. 3. Shaded relief: I don't know your gdalhillshade command at all. Does it produce the same results as the r.shaded.relief I was planning to use ? Can you set the illumination angle with gdalhilshade ? Yes. I realise that it is called gdaldem now. http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdaldem.cpp http://gdal.org/gdaldem.html 4. Re-gdaladdo for the shaded tif. yes. 5. Import in GRASS and checkout results. If I'm right, I will have two layers at this point, one with the relief colors, one with the shadings. Right (say, one is the relief [colors are optional], the other the shadings). You can use d.his or r.his to make a nice shaded colorized terrain map, something like this: http://grass.osgeo.org/grass60/screenshots/images/etopo2_grass_laea_9_48N_0E.jpg Nice one: leads to a lot of graphical ideas concerning the final map... 6. Coastlines and Rivers. I was planning to use SWBD(coastlines and main rivers) and VLMAP0 Data (for the secondary rivers). Here again, you provide me with a complete new set of tools: r.external/r.terraflow/r.mapcalc/. What is the general idea behind ? r.external you would use in step 5. Instead of r.in.gdal. r.terraflow/r.mapcalc you may forget since I didn't understand that you would take the rivers as vector maps (I thought you wanted to extract them from the DEM). Didn't even think such things were possible, but now that you mention it, what would be your advice ? Using wmap0 set - with its errors - to get the rivers, or try to extract them from the DEM ? Which one would produce the best results (=at 93 or 186m resolution) ? I checked the man pages, but I don't really understand how to use them for my purpose. My plan was to import the shapefile into the right projection with rvin.ogr, v.in.ogr (or v.external). and than export svg files for rework BEFORE joining the river layer and the topographic layers; but perhaps your way, once I understand it, is more efficient. Not sure (since I was confused :). 7. Export the shaded topography with r.out.png in one big png. Do I need two files (one containing the shadings, one with the relief colors) ? If you do the color shading in GRASS, then you need to export only one file. 8. Merge topography and hydrography layers in GIMP. Yes, sounds reasonable. Please consider
[GRASS-user] Compiling addons - description.html
Hi, When compiling addons, how do I make the description.html file that comes with the addon be installed as the help page that loads with g.manual? Currently, I am getting a short page with just the commands as generated by g.parser. e.g. in grass-addons/raster/r.denoise, or r.surf.volcano sudo make MODULE_TOPDIR=/usr/local/grass-6.5.svn sudo make MODULE_TOPDIR=/usr/local/grass-6.5.svn install Cheers John -- Dr John Stevenson Postdoctoral Research Associate School of Earth, Atmospheric and Environmental Sciences Williamson Building University of Manchester Manchester M13 9PL UK tel. +44(0)161 306 9360; fax. +44(0)161 306 9361; john.steven...@manchester.ac.uk ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] troubles with pgAdmin ver 1.8.2
Hi everybody, i'm trying to use the DBMS pgAdminIII ver 1.8.2, but i cannot connect to any server... i'm really wondering about what should be inserted in the New Server registration form...(name, host , port...). I tried smthing but it answers me ident authentication failed, and the tip is to edit the pg_hba.conf file with an entry that looks like: host all all 192.168.0.0/24 md5. Is this ip address the right one for any machine, or should i find mine??? I'm running it under linux 8.04, and i would like to know how can i add a new server. Thanks a lot ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Fwd: [OSGeo-Discuss] Request for Abstracts: Fall 2009 AGU Session IN18: Open Source Remote Sensing Software and Applications for Earth and Environmental Science
FYI - perfect to showcase GRASS in research! -- Forwarded message -- From: pilant.d...@epamail.epa.gov Date: Wed, Aug 5, 2009 at 9:11 PM Subject: [OSGeo-Discuss] Request for Abstracts: Fall 2009 AGU Session IN18: Open Source Remote Sensing Software and Applications for Earth and Environmental Science To: disc...@lists.osgeo.org Dear Colleagues and Open Source Remote Sensing practitioners and developers, Please consider submitting an abstract for the Fall American Geophysical Union meeting December 14-18, 2009 in San Francisco: Session IN18: Open Source Remote Sensing Software and Applications for Earth and Environmental Science Please note: abstracts are due online on September 3, 2009. Abstract Submissions: http://www.agu.org/meetings/fm09/program/abstract_submissions.php Link to AGU Session: http://www.agu.org/meetings/fm09/program/scientific_session_search.php?show=detailsessid=604 Abstract: Satellite and airborne remote sensing imagery is integral to geospatial research in earth and environmental sciences. The synoptic bird’s eye view helps us see relationships among landscape elements in their spatial context, the continuum of nature and human infrastructure. There are increasing amounts of satellite and aerial remote sensing imagery of the earth available for free and low cost (e.g., Landsat; USGS and USDA aerial photography), via convenient online data portals and virtual earths. However, for some user communities, licensing costs for commercial image processing and analysis software may present barriers to scientific use of free remote sensing imagery. The goal of this session is to present examples of application and development of free and open source remote sensing and image processing software for use in the earth and environmental sciences. Of particular interest are abstract submissions highlighting open source software applied to the following: high resolution imagery (0.5-5 m pixels) for detailed landscape mapping, LIDAR, plugin image processing algorithms for virtual earths, operational web-based remote sensing, and web processing services (WPS). Conveners: Drew Pilant, US Environmental Protection Agency; Peter Fox, Rensselaer Polytechnic Institute Thank you for your kind consideration. Please forward as appropriate. Sincerely, Drew Pilant, Ph.D. Remote Sensing Research Scientist US Environmental Protection Agency Office of Research and Development Landscape Characterization Branch tel: 919.541.0648 fax: 919.541.9420 pilant.d...@epa.gov ___ Discuss mailing list disc...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: re: [GRASS-user] Very high resolution topographic map of Europe: need help and advices
On Wed, Aug 12, 2009 at 6:21 PM, Felix Schalckfelix.scha...@gmail.com wrote: 2009/8/12 Markus Neteler nete...@osgeo.org: On Wed, Aug 12, 2009 at 4:06 PM, Felix Schalckfelix.scha...@gmail.com wrote: Dear Markus, Thanks to your advices, the production outline has changed to this: 1. Merge the cgiar TIFs (AND NOT THE GRASS RASTERS IF I GOT THIS CORRECTLY) thanks to gdalwrap command. In what projection does this command work ? Is it possible to wrap the TIF directlly in my lcc projection ? I tried that yesterday and did NOT have luck. I would do it two-pass, even if it consumes twice as much space temporaneously: a) gdalwarp: all into one file, keeping the projection (mosaicking) b) gdalwarp: reproject to LCC (note that there are EU LCC and others). Use your preferred resampling method (gdalwarp offers several). Perhaps I got something wrong and you can do it in one step as well. I immediately tried this, and ran into following problem: $gdalwarp srtm_*.tif europe_all_srtmV4_cgiar_default.tif Creating output file that is 6P x 36000L. ERROR 6: A 6 pixels x 36000 lines x 1 bands Int16 image would be larger than 4GB but this is the largest size a TIFF can be. Creation failed. If I understand this correctly, I don't have a choice here, We are lucky, you have a choice :) http://www.gdal.org/frmt_gtiff.html - BIGTIFF=YES/NO/IF_NEEDED/IF_SAFER: Control whether the created file is a BigTIFF or a classic TIFF. and must reproject the whole thing while pasting it. So I computed this command: $gdalwarp -s_srs epsg:4326 -t_srs +proj=lcc +lat_1=47 +lat_2=41 +lat_0=53 +lon_0=12 +x_0=22.0 +y_0=15.0 +ellps=WSG84 +units=m +no_defs -tr 93 93 -r bilinear srtm_*.tif europe_all_srtmV4_cgiar_93m_LCC.tif It seems to work (at least a 3.6Gb TIF file is created in the right directory), but takes FOREVER (eg. the 2 first tiles took about 50min, and I have 56 tiles to be merged...). Strange thing is that neither the cpu nor the RAM is being used at full extend. This is best asked on the gdal-dev list (I am currently running a mosaicking of 1700 DEM tiles, it runs for 10 days already...). The r.patch tool provided by GRASS went much faster. Cool! Any idea here to speed up things ? Would lowering the resolution (186m would be an option) help ? Perhaps but still all input data have to be read. Still best asked on the GDAL mailing list. Maybe someone else here knows more. ... 6. Coastlines and Rivers. I was planning to use SWBD(coastlines and main rivers) and VLMAP0 Data (for the secondary rivers). Here again, you provide me with a complete new set of tools: r.external/r.terraflow/r.mapcalc/. What is the general idea behind ? r.external you would use in step 5. Instead of r.in.gdal. r.terraflow/r.mapcalc you may forget since I didn't understand that you would take the rivers as vector maps (I thought you wanted to extract them from the DEM). Didn't even think such things were possible, but now that you mention it, what would be your advice ? Using wmap0 set - with its errors - to get the rivers, or try to extract them from the DEM ? Which one would produce the best results (=at 93 or 186m resolution) ? Good question. I am afraid that you need to experiment (but you can do that in a small map portion). Please keep us informed about your results. I recently used the rivers from OpenStreetMap for making a map, in my current study area they are quite complete. You can grab OSM as SHAPE file from http://download.geofabrik.de/osm/europe/ ... Please consider to document your steps in the GRASS Wiki, it could be useful in future for others. Do you mean writing a tutorial about creating my map ? Never though it would be able catch readers... But if you seriously think Its worth it, why not. It is moreover to document you experience - since it is a Wiki, more ideas may come in over the time. cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] python script: grass.list_grouped for other mapset
Dear all,
I am building some codes on python that read grass informations.
If I start msys - grass - select my location mapset, I am able
to both get the list of rasters or read a raster map.
To get the list of raster maps I use something like:
landscape_list=grass.list_grouped('rast')['PERMANENT']
This works fine. But my application will need to read information
for more than one mapset at same time, and the are not stored
on PERMANENT.
As I am working with landscape simulations,
for each landscape (I have about 30,000 landscapes with 512x512 pixels)
I generated about 5 new maps, and for convenience (including backup)
echo set of maps are stored on different mapsets.
I really need to stay conected on one mapset and get the list of rasters
as well as the raster maps from other mapsets, and this need to be done
on the fly of my script.
Any hint are welcome.
cheers
milton
brazil=toronto
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.ogr to SDE
Hi I have grass installed using the osgeo4w. Am trying to use the v.in.ogr command to import some vector data from an ESRI SDE data source. I have successfully used the OGR2OGR utility that came installed with the ogeo4w to extract vector data from SDE to a shapefile. When I open op a osgoe4w command prompt and query the formats supported I get the following list: C:\Windows\system32ogrinfo --formats Supported Formats: - OCI (read/write) - SDE (readonly) - ESRI Shapefile (read/write) - MapInfo File (read/write) - UK .NTF (readonly) - SDTS (readonly) - TIGER (read/write) - S57 (read/write) - DGN (read/write) - VRT (readonly) - REC (readonly) - Memory (read/write) - BNA (read/write) - CSV (read/write) - GML (read/write) - GPX (read/write) - KML (read/write) - GeoJSON (read/write) - Interlis 1 (read/write) - Interlis 2 (read/write) - GMT (read/write) - SQLite (read/write) - ODBC (read/write) - PGeo (readonly) - OGDI (readonly) - PostgreSQL (read/write) - MySQL (read/write) - AVCBin (readonly) Yet when I try to use the v.in.ogr command with the following syntax I get the error: Unable to open data source. The following is a summary of the syntax that I am using: v.in.ogr dsn=SDE:habs.ca,5153,ordb1,oraUserName,password,MYSCHEMA.LOCATIONS output=LOCATIONS Is there any way I can verify that the grass is using the same GDAL/OGR versions as I am using on the OSGEO4W command line? Any help would be appreciated. Thanks Fran ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
