Control tag-mapping in OM?

[Off-Track1234]

Is there any way to alter tag-mapping in the OM Mapsforge or VTM engines?

It is normally set in a tag-mapping XML file (presumably somewhere hidden from the user?).
My understanding is that zoom-min in a theme XML file will be invalid if it is set below the zoom-min set for that tag in the (hidden?) tag-mapping XML file.

By way of explanation I am trying to get a specific feature type (tag) to show on the map at a lesser zoom level than is apparently defined in the default tag-mapping XML file. This cannot be done by editing the rendertheme XML file. (I tried).

[LaurentG]

Yes, what you did is the right way of doing (change the zoom-min in theme XML file)... but is not enough.
It would be efficient... if the tag is present in the mapsforge file at this level.

But obviously, all tags and features are not present in the mapsforge map at all levels.

As a result, changing zoom-min and zoom-max in theme XML file, you can change at which level a feature appears or not in the rendered map, provided this feature exist in the mapsforge map at these levels.

In your case, you could only ask the provider of the map (OpenAndroMaps, I presume ?) to add this tag at a lower level than currently. If you have good arguments to do so, he could accept to do so. But only if your arguments are really valuable...

[Off-Track1234]

Thanks Laurent G.

So if I understand, the tag-mapping XML file that determines minimum-zoom for a feature (even when we ask for a lower level in a rendertheme) is set by the maker of the Mapsforge map and is not accessible for alteration later (even by the rendering engine such as that in OM?)

[LaurentG]

Correct.

To summarize, there are two different concepts :
- Which tags,features, etc.. exist in the map itself, depending on which zoom level
- among existing tags, feature, etc.. present in the map, which ones are displayed at which zoom level.

The first one is under control of map maker himself, and only him/her
The second one is under control of theme XML file, and can then be modified by end user.

But this modification can change what is shown at which zoom level only for tags, features, etc... present in the map. It cannot "invent" what is not in the map...

[Off-Track1234]

Thanks again LaurentG.

I think I understand now. I would say that the features are indeed in the map, the map-maker has simply chosen to hide them below certain zoom levels, and the user can do nothing about it. But that is probably just semantic, it is certainly not the fault of the rendering engine (in OM) or the user.

To carry on a bit, this seems to me like a lost opportunity. Whoever decided to embed the tag-mapping XML file so deeply in (binary) code for Mapsforge maps must have given very little weight to ease of adjustment by the user. Surely if it is indeed based in a simple XML format it could be implemented differently (like rendertheme XMLs) for ease of adjustment?

[LaurentG]

I would say that the features are indeed in the map

No, they are NOT.
If all features were present at all level of zoom, Mapsforge maps would be a lot and a lot and a lot larger ! And not really usable.

[Off-Track1234]

Thanks again LaurentG. I think I understand (at last). The tag-mapping.XML file is used to help create the .map file, not contained within it. The decisions of the map-creation software makers and the map makers are sensible, considering map file sizes. The effect is that the features are indeed present in the map, but they are not present at all zoom levels. The map user cannot get around that (except by convincing the map maker to include the feature at another zoom level in another [therefore larger] version of the map, as you have explained).

It is interesting that a feature listed in OAM tag-mapping.xml as zoom-appear="15" appears in OM with the VTM engine at zoom levels like100@15 or 50@16, but not at lower digital zoom levels like 50@15 or 25@16. So the OAM Mapsforge map is interpreting OM VTM digital zoom (top Menu > Global Settings >Maps >Zoom settings >Volume keys) like analogue zoom. But in OM with the default Mapsforge engine it shows the feature at lower digital zoom levels, so with this viewer the OAM Mapsforge map is interpreting OM digital zoom as digital.

[Off-Track1234]

In case other OM or Mapsforge users come here, I will try to explain it better. I am just a map user, expert map makers can correct anything I get wrong. Alas there seems to be very little documentation for users in the volunteer map world. Places like Github are generally more pitched at other developers. Open Street Maps often tries hardest. Then there are knock-offs (like Mapforge from Mapsforge) with pretty front ends but no better explanations. In any case, I could not find the explanations elsewhere.

A Mapsforge .map file (or designations like ---.osm.map from places like OAM) is not really one vector map like some georeferenced pdf maps. Rather it is a series of maps at contiguous zoom levels, each with its own feature content and each behaving like a vector map within its own zoom level. The maps are ultimately displayed by a rendering engine that uses a render theme (more software) to determine whether and how each feature included at each zoom level is displayed on screen. This has several advantages for the user:
1.   It allows very compact maps, so large areas can be covered in a single manageable file.
2.   The maps at each zoom level can be clear and uncluttered. (Users can tailor render themes if so desired)
3.   It preserves 'ways' and 'nodes', so a street navigation engine can be used (if beaten paths are your thing).

Typically the features come from Open Street Maps. Which features get included at each Mapsforge zoom level is determined (using a map-tagging.xml file) by the map maker (with an eye on map size and user demand). Once the map is compiled, a render theme (even a custom one) can only display a feature if it is in a particular map zoom level.

Overall this works very well (though some users may wish for a particular feature in another zoom level). There are a few odd effects like the digital zoom responses in OM mentioned above, but most users will probably never notice these.

It also explains why street navigation engines (like BRouter or GraphHopper) do not work on WMTS raster maps or georeferenced pdf vector maps. Their streets are not mapped as ways and nodes, just raster or vector elements. This is a separate function from navigation of a saved or imported track within OM. One day, OM may even provide assistance through reliable 'straight-line navigation' of an imported GPX route.

[Off-Track1234]

It looks as though I have oversimplified OM routing on the beaten track (I don't use it). GraphHopper routing now requires a subscription. BRouter must be installed in advance. Either way, you need downloads beforehand to use the router offline later. OAM Mapsforge maps and these routers all use Open Street Maps data, but the routers do not work directly from the Mapsforge maps.