[GRASS-user] Very high resolution topographic map of Europe: need help and advices

[Markus Neteler]

On Wed, Aug 12, 2009 at 6:21 PM, Felix Schalck<felix.schalck at gmail.com> wrote:
> 2009/8/12 Markus Neteler <neteler at osgeo.org>:
>> On Wed, Aug 12, 2009 at 4:06 PM, Felix Schalck<felix.schalck at 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