On Wed, Aug 12, 2009 at 6:21 PM, Felix Schalck<felix.scha...@gmail.com> wrote: > 2009/8/12 Markus Neteler <nete...@osgeo.org>: >> On Wed, Aug 12, 2009 at 4:06 PM, Felix Schalck<felix.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 60000P x 36000L. > ERROR 6: A 60000 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.00000 +y_0=15.00000 +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
