[FEATURE] Option to include selected tags other than those permitted by com.onthegomap.planetiler.util.LanguageUtils.VALID_NAME_TAGS?

[ejschoen]

Is your feature request related to a problem? Please describe.
I really hate to bring this up... We unfortunately have a requirement to deal with tags from OSM for node labels that are other than the name:* tags. In particular, official_name:* and nat_name:*. I don't see an option to specify additional tags.

Describe the solution you'd like
Command line option to specify a list of tags to include in the mbtiles output beyond those implied by the --languages option.

Describe alternatives you've considered
We're using MapLibre GL JS to render mbtiles, and we're using standard styles for it (OSM Bright, etc). We've got some logic that can load a style and then substitute more flexible rendering for feature names beyond the "text-field": "{name}" that comes standard with these styles. However, we need the tags for certain features beyond translation and transliteration tags.

Additional context
Add any other context or screenshots about the feature request here.

[msbarry]

Hello! I think your best bet would be to fork planetiler-openmaptiles to get full customization over what name tags it passes through, or open up a discussion in openmaptiles repo if you think there's a solution that would be useful to all consumers and it will eventually get ported over to planetiler-openmaptiles.

That being said, it could make sense to change LanguageUtils.VALID_NAME_TAGS regex to just verify a valid language tag suffix, but make Translations take a set of prefixes that it passes through. There are a few issues with that regex that need to be fixed anyway (see #1162). That would let you run with --languages=en,en_us,de,... --name_tag_prefixes=name,official_name,... which would pass through a lot of extra tags. Alternatively we could add an explicit argument --extra-name-tags=official_name:en-us,short_name:de to allow passing through any name tag from input to output? Minh - any thoughts on either of these options?

[ejschoen]

I had been thinking about the latter approach: --extra-name-tags=.... I've been looking at the code for a couple of days, dealing with getting it runnable in IDEA, etc. There's a lot to understand about how to implement the feature while keeping with the existing application architecture. I've got it sitting in a breakpoint right now on the call to LanguageUtils.isValidOsmName and am looking back on the stack to see if any of the classes make sense as places to support extra name tags. Poi.setupPoiFeature stands out, or looking further back in the stack, arranging for org.openMapTiles.OpenMapTiles to add a new handler to RowDispatch.

[1ec5]

In OSM, the language subkey syntax is generalizable to a large number of base keys, not only name:* and *_name:* but also brand:*, destination:lang:*, and species:*, to name a few. I suspect a name_tag_prefixes option would be more broadly useful than one that deals with both the prefixes and suffixes at the same time. I could imagine a use case for exposing the internationally recognized names of features based on int_name but not bothering with its subkeys.

[msbarry]

OK great thanks for the input!

Looks like it would be possible to do entirely within planetiler by changing VALID_NAME_TAGS to only validate language subkey suffixes, changing Translations class to take an additional set of name prefixes and/or a set of full language keys to pass through, then update getTranslations or addTranslations to incorporate those as well. I think this would be preferred to decouple that regex from the name: prefix and so anyone can control via command-line args.

To do it in a planetiler-openmaptiles fork, you should only need to update OmtLanguageUtils.getNames, not any of the RowDispatch classes.

[ejschoen]

Many thanks. I'm still not sure I understand the processing flow, but I took a stab at a change.

In view of the fascinating discussing here (really appreciate @1ec5's commentary in that thread!), I've a question in my mind as to whether what I'm looking for is properly a translation or just extra name tags. However, since OmtLanguageUtils.getNames is used in many places, I've concluded that it makes the most sense to modify it to handle extra name tags. Since it's a static class, I've had to add:

• a private static field to hold the list of desired extra name tags,
• a public static method to set the list of desired name tags, invoked right now from org.openmaptiles.Generate.main,
• and a new private static method invoked from OmtLanguageUtils.getNames that copies in non-empty extra name tags from the source.

[msbarry]

That makes sense. If you don't need it to be configurable, you could just add one line to OmtLanguageUtils like putIfNotEmpty(result, "official_name:en-US", string(tags.get("official_name:en-US")));. The right way to make it configurable would be the change I described in planetiler's Translations class since that is created based on CLI args and passed into these static methods. That would give a lot more flexibility to consumers across a broad range of use-cases, but it's definitely more work to set up.

[ejschoen]

I've got it working. I'll make a PR. Result with a custom tweak to the Americana map style's text-field expression for water_name_point: