[mkgmap-dev] [PATCH] Creating contour lines from DEM data

Sat Jul 4 11:33:34 BST 2009

Nop schrieb:
>
> Hi!
>
>
> I am very much interested in your work as I used srtm2osm, which is no 
> longer working, and now I am looking for alternate techniques.
>
> Christian Gawron schrieb:
>> Nop schrieb:
>>> Sounds interesting. Does it also distinguish minor and major 
>>> elevation lines? 
>> Currently the types are still hard-coded as follows:
>> multiples of 200m: 0x22
>> multiples of 50m: 0x21
>> 0x20 for all others
> > This should of course be configurable (as well as a "feet" mode).
>
> Should not be too difficult to make this configurable and also turn 
> off  the elevation texts for each level. No need to label each 10m-line.
Maybe I should use the styling engine here - I will have a look at it.
>>> What determines the area in which the contour lines are calculated? 
>> The bounding box of the tile.
>
> So each map tile must have a bounding box? What happens if there is 
> none? Currently I am not generating  them, but that's no problem.
AFAIK the mapper generates a bounding box, but this may be too large.
>
>>> Is there a way to avoid an overload with contours e.g. when 
>>> processing the whole of Germany inclduing very flat country as well 
>>> as the the alps?
>> You may split the map and use diffeent settings for each tile.
>
> This is still a problem. When creating a map of Germany, I have 440 
> tiles, but I cannot tell in advance which of them are too mountaineous 
> too show with all altitude lines. Even if nothing crashes, if you show 
> 10m lines for the whole of the alps, the map size will explode and the 
> map consists mostly of altitude lines.
>
> In the past, I have handled it by first creating the contour line .osm 
> with srtm2osm and 10m lines. When the size of the output .osm was too 
> large, I doubled the base distance to 20m lines and tried again, until 
> the output size was within limits. Can you think of a way to integrate 
> an upper limit for elevation lines and a try-and-error fitting against 
> this limit to your calculations? Or even better, is there a way to 
> predict the outcome without doing all calculations first?
>
I could add a feature which looks at the difference between minimum and 
maximum height in a tile and chose the interval based on this.

Best wishes
Christian