
Hi, I've noticed some inconsistencies in the rendering of heights of peaks. In the default style file, the altitude is converted from meters to feet because Garmin likes that. natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24] Here are some examples where it goes wrong: Kahler Asten, near Winterberg, Germany http://www.openstreetmap.org/browse/node/83318818 GPS shows: 256m Mapsource: no height info osm tags: * ele: 840,8 * name: Kahler Asten * natural: peak Wetztstein, near Winterberg, Germany http://www.openstreetmap.org/browse/node/664200355 Gps shows 235m Mapsource: no info osm tags: * ele: 771 m * name: Wetzstein * natural: peak Example where it is rendered correctly: Bremberg near Winterberg, Germany http://www.openstreetmap.org/browse/node/316037203 Gps shows 809m Mapsource: 809m osm tags: * ele: 809 * name: Bremberg * natural: peak So only if the altitude is given in numbers (without decimal fractions or m) it is rendered correctly. I'm sure this can be improved in the style file by some kind of logical expression but how?

On 03.04.2011 11:39, Minko wrote:
Hi,
I've noticed some inconsistencies in the rendering of heights of peaks.
In the default style file, the altitude is converted from meters to feet because Garmin likes that. natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24]
Here are some examples where it goes wrong:
Kahler Asten, near Winterberg, Germany http://www.openstreetmap.org/browse/node/83318818 GPS shows: 256m Mapsource: no height info
osm tags: * ele: 840,8 * name: Kahler Asten * natural: peak
Wetztstein, near Winterberg, Germany http://www.openstreetmap.org/browse/node/664200355 Gps shows 235m Mapsource: no info that indeed should be an error. Are all values with "," considered incorrect? What about 840.8 meters (which is correct english). Basically any "," should be interpreted as not existent, even though the placement is not 3 from the right. So I would expect mkgmap to insert 8408 as height, as we are still using english standards throughout osm, and not some random local symbols. osm tags: * ele: 771 m That is incorrect tagging. mkgmap does not know what to do with the "m". Or differently said, mgkamp has no advanced converter to make use of units like km, m, miles, .... * name: Wetzstein * natural: peak
Example where it is rendered correctly:
Bremberg near Winterberg, Germany http://www.openstreetmap.org/browse/node/316037203 Gps shows 809m Mapsource: 809m
osm tags: * ele: 809 * name: Bremberg * natural: peak
So only if the altitude is given in numbers (without decimal fractions or m) it is rendered correctly. I'm sure this can be improved in the style file by some kind of logical expression but how?
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

It could be that those examples are not strictly according to the osm rules. However, on http://wiki.openstreetmap.org/wiki/Natural_peak there is nothing said about using of decimal fractions with comma or point, m(eters) behind the numbers etc. What I'd like to know is how to add a workaround in the styles to make those (incorrectly?) tagged values render correctly on my maps.

I found a better way to render the height, by just skipping the whole conversion height:m=>ft thing. natural=peak & ele=* {name '${name|def:} (${ele|def:})' | '${name}' } [0x6616 resolution 20] natural=peak & ele!=* {name '${name|def:}' } [0x6616 resolution 20] Now it renders on my maps as follows: Kahler Asten (840,8) Wetzstein (771 M) Bremberg (809) Poppenberg (the last peak did not contain elevation info) Of course you could refine this by adding m behind the digits (with a check if ele contains no m(eters)) but this is ok to me.
participants (2)
-
Felix Hartmann
-
Minko