OSMAND - Why are some natural=peak not labeled w/ name=*

Help and support
1

I have noticed that in some cases OsmAnd (on Android) labels a natural=peak with the value of the name tag, for example:

Is labeled “Mount Sherman (4280)” (4280 is the value of the ele=* tag)
This is the behavior I would expect.

However:

Is simply labeled “4349.9” (4349.9 is the value of the ele=* tag)
I would expect that this be labeled “Quandary Peak (4349.9)” or
“Quandary Peak (4350)” (rounding of the ele=* value)

What doesn’t seem to matter:

  • The value of ele=, some lower peaks are labeled with the value of name=, while higher ones are not.
  • Whether the peak node is part of a way that is a trail.
  • The prominence of the peak (i.e. its ele=* relative to the peaks around it).
  • The presence or absence of wikidata=* and wikipedia=* tags.

I want to be clear that I am not attempting to “tag for the renderer”, but if there is some legitimate information missing, I would like to add it; if there is a bug with OsmAnd I would like to report it; and if I am using OsmAnd incorrectly, I would like to learn how to use it correctly.

Thanks

3 Likes
2

AFAICR JOSM and other QA validate ele on whole meters i.e. it would expect an ele value here of 4350.

I propose to test this value on quandary peak, wait a little, visit Carto standard map and hit Ctrl+F5 (Windows) to force a render refresh.

1 Like
3

It doesn’t seem matter if the value of ele=* has a fractional part or not, for example, Long’s Peak (Node: ‪Longs Peak‬ (‪358945272‬) | OpenStreetMap) is not labeled “Longs Peak (4346)”, but simply “4346”.

I should have been more clear, this question is about the app OsmAnd running on Android, not the standard carto style.

Thanks

4

Does changing your zoom level on OSMand effect it at all?

I’ve just done some playing & it appears that peaks don’t appear on OSMAnd at all till “fairly” close in (5km showing as the scale measure on my phone), & even then are just showing as a triangle. Then at 2km the height appears, followed by the name at 1km.

Unfortunately, OSMAnd is pretty useless for navigation by picking mountain peaks & identifying them e.g. driving down the highway & saying What’s that mountain?

1 Like
5

No matter how far I zoom in (I zoomed in until the scale bar is 10 feet long - which is as far zoomed in as I can get), the name for Longs Peak never shows on the OsmAnd Map.

When hiking and one is on top of one peak, it would be very interesting to see surrounding peaks with their names.

Thanks

6

As an orienteering instructor who uses OSMAnd’s peaks as reference points for navigation, I understand your frustration!

I have seen some cases where the map updates that OSMAnd downloads are not in good shape. Have you tried deleting the saved map data for the area and downloading fresh copies?

You might also check that you haven’t downloaded two different versions of the map data covering the same location, e.g., one data set for a local region and a second data set for the entire state. I have also seen that cause some problems.

1 Like
7

I am going on a big hike tomorrow and don’t want to risk totally messing things up prior to then, but after that I will try your suggestion.

I don’t think that is the case, but if I delete everything and download anew as you suggest, that should fix this issue if it exists.

Actually, until taking a look at Mount Sherman (Node: ‪Mount Sherman‬ (‪358915061‬) | OpenStreetMap) and the surrounding area, I had never seen OsmAnd label a peak with a name. I just figured that it wasn’t designed to do that.

8

Here is my current working hypothesis:
If the node representing the peak is also part of two (or more?) ways that represent trails (highway=path observed, but perhaps highway=footway, highway=track, or any highway=* would suffice), then OsmAnd renders the name as well as the ele in meters (once one zooms in sufficiently). Even here in Colorado US, not every peak is going to have a trail to its summit, let alone two trails, so very few peaks are labeled with the value of their name tag. I will submit a bug report to OsmAnd. Hopefully it will be an easy fix.

9

I’m getting labels in OSMAnd for Mount Sherman, Quandary Peak, and Longs Peak. All the named peaks near where I am have labels too, e.g., Table Mountain.

Another thing that can go wrong with OSMAnd is that the data for the rendering styles can get messed up. You have to delete the app and all its data and reinstall to clear that. But you might try switching to a different profile with a different map style to see if that makes a difference.

10

Please do link to that bug report here when you do, so interested parties can follow.

Also, have you tried Configure map / POI overlay / Search / type peak and select Mountain peak, click Show mountain peak on the map. Do they show? What if you click on that orange icon and then details, does it show the name?

What is you also enable Configure map / Point Labels (POI, Favourites) ? Do names show? Do they show twice?

1 Like
11

Thanks for your interest. I will do that.

I had not tried that prior to your suggestion. I now have tried, and they do show as a symbol without a name label.

Yes it shows the name!

Yes - Great idea!

In some cases. The cases that showed the name before following your excellent suggestions.

General update:
I haven’t had much time to work on this, but here is what I have found. If I edit a natural=peak (I found many that have legitimate reasons to be edited), then the next time OSMAND updates its data, the peak names show (without doing the things @Matija_Nalis suggested). However, obviously this is not a workable solution as there are not legitimate reasons to edit all natural=peaks. I did try deleting the map data through OSMAND and re-downloading, but that didn’t fix the issue. Next, I will uninstall the app from my phone and start all over.

12

I was able to “fix” the issue by editing default.render.xml
was:

<case minzoom="12" tag="natural" value="peak" textOrder="80">
	<case maxzoom="12" nameTag="ele" textSize="11" intersectionMargin="15"/>
	<case minzoom="13" maxzoom="13" nameTag="" nameTag2="ele" textSize="11"/>
	<case minzoom="13" maxzoom="13" nameTag="ele" textSize="12"/>
	<case minzoom="14" maxzoom="14" nameTag="" nameTag2="ele" textSize="12"/>
	<case minzoom="14" maxzoom="14" nameTag="ele" textSize="12"/>
	<case minzoom="15" maxzoom="16" nameTag="" nameTag2="ele" textSize="13"/>
	<case minzoom="15" maxzoom="16" nameTag="ele" textSize="13"/>
	<case minzoom="17" nameTag="" nameTag2="ele" textSize="15"/>
	<case minzoom="17" nameTag="ele" textSize="15"/>
	<apply_if maxzoom="14" engine_v1="true" textDy="-2"/>
	<apply_if minzoom="15" engine_v1="true" textDy="-1"/>
</case>

Is:

<case minzoom="12" tag="natural" value="peak" textOrder="80">
	<case maxzoom="12" nameTag="ele" textSize="11" intersectionMargin="15"/>
	<case minzoom="13" maxzoom="13" nameTag="" nameTag2="ele" textSize="11"/>
	<case minzoom="14" maxzoom="14" nameTag="" nameTag2="ele" textSize="12"/>
	<case minzoom="15" maxzoom="16" nameTag="" nameTag2="ele" textSize="13"/>
	<case minzoom="15" maxzoom="16" nameTag="" nameTag2="ele" textSize="13"/>
	<case minzoom="17" nameTag="" nameTag2="ele" textSize="15"/>
	<apply_if maxzoom="14" engine_v1="true" textDy="-2"/>
	<apply_if minzoom="15" engine_v1="true" textDy="-1"/>
</case>

If I understand how the rendering xml works, in the original each zoom level matched two lines, with the second overriding the first, thus nameTag is always ele and the value of name=* doesn’t get rendered.

However, I don’t understand why editing a node tagged natural=peak (and name=*) in OSM and waiting for OsmAnd to update its data would cause the name to be rendered with the original default.render.xml

Note, I have not uninstalled OsmAnd and reinstalled. It is possible that if I did, default.render.xml would have modifications that would address the issue of the names of peaks not rendering.

1 Like
13

It would be good to open OsmAnd issue with your problem and workaround; as others could benefit if they were added.

Those duplicate zoom entries indeed look confusing; I wonder if there was a specific reason they were added

3 Likes