There’s widespread consensus that the name should be the name only for various good reasons, and I personally strictly adhere to this.
But on a few occasions I came across cases where experienced mappers seem to make allowances for descriptive names. I think it’s usually when all of these conditions are met:
The point of interest has no name.
There is no commonly accepted tag to describe the specific subtype in question (for example, an ancient Mikveh)
There aren’t enough instances of that subtype, and/or there isn’t enough interest in the POI to be worth the effort of creating a new tag, and/or even if it were standarized it would be unlikely that any existing renderer would use the new tag so the effort wouldn’t be very helpful in practice.
In such a case, the mapper may choose name=Mikveh or name=Ancient Mikveh, along with historic=archaeological_site
One could argue that it is a pragmatic choice as it helps the end user understand the subtype that they otherwise wouldn’t have seen on the map, and that there is little harm in it in this specific scenario.
What are your thoughts on this? Are there any practical downsides here? Would you do this differently? Are there other cases where it makes sense to let this slide?
archaelogical_site=baths have been mass-added mostly for non-ritual ones. You can add religion=jewish first.
baths= has 1 instance for the number of it. bath:type= in amenity=public_bath is a conflict mixing up different orthogonal aspect in the useless *:type= suffix. For uniformity, bath= can be used, and =baths discussed to become =bath to match it.
historic= has 6 =bath alongside =public_bath , and 1 =ritual_bath the most specific. Therefore both historic=bath and archaeological_site=baths can further be changed to =public_bath , to match the amenity= , and allow using =ritual_bath to clearly distinguish them
There can be some interest and usefulness in both historic= and amenity=
5 place_of_worship= (that being said above, again religion=jewish would indeed be what’s most easily usable by renderers and applications, as Carto can be seen rendering this when searching Nominatim)
As mentioned above, description= should be used. I would personally commandeer label= for a short text, if you need to describe individual ones in sentences.
This happens frequently but it does not mean it is good tagging. Whenever I come across such descriptive names I try to find a better way, using descriptions or ATYL tags or at least leave a CS comment for the mapper asking them to consider a better approach.
I agree, but in the given case the secondary Wikidata tag should not be historic:widata=Q211351 but archaeological_site:wikidata=211351 imo.
There isn’t such a thing as “the map” - there are a thousand different renderings in many different languages, routers, analysis tools, and so on. Adding descriptive names might conceivably look ok on osm-carto but break other uses that the mapper hadn’t considered. As mentioned above, description= is a good dumping ground if you want to add this sort of information.
That’s a fair point and such feedback is why I opened the discussion.
By “the map” I meant most end-user facing apps.
A mapper who’s oriented on doing whatever delivers value to people using apps, may reason that adding the description to the name tag makes it instantly accessible to the end user on most raster maps, on OsmAnd, Organic Maps, and so on. Whereas tagging solutions, such as adding archaelogical_site=baths and religion=jewish, actually bury the information in an inaccessible place in most of these apps.
They may then conclude that inventing a tagging scheme is more effort for less contribution.
While this is often easy to refute, I’m wondering if there’s a strong counter argument against this under the conditions I mentioned at the start of the thread.
For example, what other use cases may break when marking a Mikveh as name=Mikveh along with historic=archaeological_site?
This seems to be a very reasonable solution when one doesn’t have time/interest/energy in creating a tag or when it’s just not worth it because it’s just too little instances/too minute to be of interest for the mapper.
Not really - lots of consumers advertise that they use the second of those. At least a couple of “general purpose” maps (at least mine) consume the former, as do lots of specialist maps.
Indeed, OpenStreetMap is a database that aims to deliver data for a wide variety of map makers that have a wide variety of map users in mind. Suppose there is a mapper who wants to enable creation of a map of tree species distribution, and adds every single tree he can find to the map database with natural=tree + name=oak (/beech/birch/etc.). Another map maker wanting to create a map for tourist is probably interested in displaying trees on his map, and also wants to show names of streets. But if he wants to show both, the map will be cluttered with tree species names, something a tourist is probably not interested in. By adding the information that a tree is an oak in the form of species=*genus=* and taxon=* tags, a maker of tree distribution maps can display this information by choosing a different icon for each different tree species, while a tourist map maker can choose just to show all trees with one icon. A tourist map maker will be happy to show name=Ancient Mikveh but a tree distribution map maker will not want to show this text.
I see! Here’s a scenario connecting your example to the Mikveh use case:
Someone might want to make a list of all Archeological Sites, and the list would weirdly have “Mikveh, Mikveh, Ancient Mikveh” among the legitimate names of archeological sites.
I don’t think there is a good alternative today. A description tag is not displayed on most maps, and the description is often too long to read quickly.
You need a tag that describes the point in a word or two and no more, even if it’s not a name.
If there was a tag like summary, you could use that instead.
Until then, mappers have no choice but to use a name tag.
Using the name tag for something which is not the instance-specific name of the element would effectively allow anything to be used. The wording used for the examples demonstrate clearly that what is missing from the map is a description. For example “There aren’t enough instances of that subtype” demonstrates that the proposed name would not be instance-specific.
IMO, this is yet another case of mapping for the renderer, as was also clarified by “A description tag is not displayed on most maps, and the description is often too long to read quickly.”
There is clearly a need for adding descriptive information to the map for which there are no suitable tags, but to misuse the name tag for this is wrong. To fulfil the need, maybe we should encourage data users to show the content of description tags on their maps? It’s probably not a good idea to show such content by default, but a PoI with a description tag could be rendered in a slightly different way to indicate there is a description tag, and only tapping/clicking on it would reveal the text?
Map renderers can choose to display short description tag values when a name tag is missing. One may propose a new short_description tag for this purpose.
There are 14 pages of data consumers at taginfo (mostly editors, but some others).
When processing data for display (e.g. before adding to an osm2pgsql database or creating vector tiles) it’s also possible to truncate descriptions, or truncate after the space immediately before X characters, or similar.
note=ancient mikvah or fixme=ancient mikvah also may be a temporary solution: armchair mapper eventually can add archeological_site=ritual_bath + religion=jewish.
I guess the perceived gap is that no application would make the connection between this archaelogical_site=bathsreligion=jewish combination and the term “Mikveh”. If this is a good assumption, maybe we need to talk to software developers about hard-coding it. For starters, the term doesn’t appear anywhere in id-tagging-schema presets or their translations.
When we deconstruct a specific concept into a combination of less specific tags, the tradeoff is that more data consumers can provide basic support but fewer data consumers can provide the ideal user experience. (An infamous example is the highway=path scheme.) This is where Wikidata excels with its highly flexible subtype tagging.
Certainly it shows up as much as you’d expect for such a longstanding key, though I don’t think it’s much consolation if most of these data consumers only use the key trivially. Realistically, most data consumers would shy away from description=* for anything particularly user-facing because of all the cruft in it. It’s hard to distinguish SEO juice from an interesting history lesson across the whole planet. A developer could employ various heuristics or machine learning classification, maybe an LLM, but they might view it as overkill for something like this.
Ideally, if enough mappers resort to a similar description, something would flag it as a missing feature tag for us to consider. Does anyone know of a tool that could be useful for that?
