Yeah, I agree it might be better to remove it. Even the nodes definition is problematic — for example, individual tree nodes that are connected to each other via a tree_row way would not be considered standalone elements, whereas the tree row would (which is the opposite of what one might intuitively expect). Surely there are many other cases like this. So I don’t think the way nodes, ways and relations are connected to each other is the defining feature that makes them standalone (arguably the tagging might, but this is already covered elsewhere in the page).
Removed in diff 2822885. A better place for such consideration would be the Elements page anyway.
2 Likes
First of all. Good to see that the topic of top-level tags has received some discussion. Comparing with the impact this concept has OSM, it was a bit on the sideline. I hope something good comes out of it.
I allowed myself to add to the wiki page a few keys which were missing from the list (some with >1M uses!). And I’ve noticed an issue emerging, which I believe was already discussed here somewhat. That is – there are some keys which can be certainly considered as constituting top-level tags, but not necessarily top-level features. For example entrance=* or traffic_calming=* are enough to tag a node as a distinct feature, but that feature cannot exist without a buidling=* or highway=* way…
For some keys this may or may not be true depending on the precise tag, eg. public_transport=* – public_transport=stop_position needs to be on a way, while public_transport=platform is “attached” to that way only logically (by being close) and not topologically, just like a shop=* would.
Should we split the table into two sections or make some other distinction between these cases?
For this reason, iD and id-tagging-schema distinguish between node and vertex geometry types, just as it distinguishes between line and area despite both being formed by ways. The wiki often talks about areas but not as often about vertices as features in their own right.
2 Likes
For now I’ve extracted “top-level” tags applying only to vertices, elements-inside-elements etc. into a separate table which I’ve dubbed “dependent elements”, as for now I can’t recall if they have any commonly used name? Anyone feel free to refine that.
After this decluttering, the “main” table looks better now. So it seems to me that the only “legit” top-level keys I’ve managed to find that were missing from the initial list are advertising, club, landcover, piste:type (wonder why that is not simply piste). Also technically traffic_sign as that is a node beside a way. May be worth adding them all as sections to Map features - OpenStreetMap Wiki. Also type as that’s technically a top-level tag for some/most relations. Also, oddly enough, departures_board??? Maybe it would be worth to mandate using that only together with public_transport=departures_board when used as a stand-alone feature?…
1 Like
I don’t know of another term for this off the top of my head. There are other kinds of dependencies too: in some regions, a shop=chemist generally must contain an amenity=pharmacy, though this is the kind of stuff that a regional wiki page should be responsible for suggesting. And some keys are commonly dual tagged, making it difficult to decide whether it’s one feature or two.
I gather from your question marks that this exercise is giving you as much of a headache as it has given me in the past. Unless we make some significant reforms to the tagging scheme, some keys will just have to live in a weird “it depends” state.
1 Like
Not wanting to get into tagging debates here, but it’s worth pointing out that for some tags there is substantial disagreement in the community whether the tag can be used as a standalone top-level tag or not (example). Maybe as part of a paragraph about how the concept of a top-level tag doesn’t exist on the database level, but does in mappers’ “mental models” of how OSM tagging works, and various editors and data consumers have come up with their own lists for practical reasons (e.g. to decide which icons or templates to present to users). And therefore no list of top level tags is authoritative or exhaustive.
6 Likes
There’s a discussion precisely about the possibility of adding a highway=* tag to these in the wiki talk page. There is already a highway=piste tag, but its description is a bit unclear (“Piste segments that do not exist without snow.”). I suppose that’s meant to complement pistes that become other highway types when the snow melts? That seems to be the case based on the description at the piste:type page:
It may be added to existing ways, like for example a highway=track or highway=path if they can be used in winter for skiing, sledding, or winter hiking. Or it may be used on its own if the piste only exists in winter (i.e. does not follow the route of an existing road or trail).
So for this case perhaps I’d suggest syncing the piste:type page with the highway=piste one (and Pistes as well), so that piste:type would no longer be considered a top-level tag, but rather a subtype of highway (be it =piste, =track, etc.).
I was going to suggest precisely adding links to such lists (several of which have been offered in this thread) in the External links section. Maybe we could even add yes/no columns to the table to indicate which of these lists include which of those keys 
With 175 uses and no proposal discussion, highway=piste is looking like a nice example of wiki fiddling to me, and really not something to be discussed as a “top level” anything.
From the start, the piste:* namespce indicates a kind of layer that can live independently of the rest of the highway, or not, when there’s snow.
2 Likes
While it’s off-topic here (and probably deserves a separate thread), I agree that having piste:type as a (kind-of) top-level tag is an abomination. Normally, skiing and sledding pistes are either
- standalone features, used over otherwise vacant alpine slopes and meadows, or
- minor highways (typically
trackorpath) used as pistes (cross-country, alpine or sledding) during winter months.
So, I think that we should introduce leisure=piste (akin to leisure=track), which could used either as a top-level tag for the first type, or as a dual tag (accompanying highway=*) for the second type.
1 Like
This is exactly why I don’t like the concept of “primary tags” or “top level tags”. It introduce this kind of hierarchy and finally some would like to add highway=piste to each and every way tagged with piste:type for the only pleasure of having QA tools complaining because it lacks.
OSM tags have grown organically and this makes the richness of it. Better embrace it once and for all and make better use of our time than absolutely try to sort everything in its “right” place.
1 Like
The concept of primary/top-level/whatever tags flows naturally out of OSMs data model. It doesn’t really matter if you like them or not, or what you call them.
Any kind or processing or, fwiw mapping in the 1st place, needs to know which set of tags define a specific real world object and which are further refinement / attributes that differ between instances of the same “thing”.
In a classical GIS model this would be layer based, but the concept would still exist.
Now in the real world there is a lot of fuzziness in categorisation so there will never be just -one- definitive way of determining such tags, think parking lots with blue lines vs. white, noise barriers vs city walls, and so on. But for purely practical reasons we need at least some rough consensus, see above.
PS: BTW I did a talk at SOTM Milano that touched on some of these issues.
2 Likes
this is how the data is codified (and it is not uniform, there are competing tagging structures), you can also have your own classification and translate from the OSM tags (and combinations of them). E.g. you can decide that you don’t want to distinguish the kind of source that provides drinkable water, the class of things you are interested in are all objects with drinking_water=yes or amenity=drinking_water (i.e. your class in OpenStreetMap is tagged either as a feature or as an attribute).
Or you may want to have classes at the same level where in OSM some instances are distinguished as “subclasses” and others as classes.
It is a question of translation, and depends on your question / usecase, which kind of classes you want to distinguish.
Retrieving all objects with drinking_water=yes gives you all objects with that property, it would be far fetched to claim all those objects are the same type of rwo (just as you are unlikely to claim that for all objects that have color=blue).
it would be far fetched to claim all those objects are the same type of rwo (just as you are unlikely to claim that for all objects that have color=blue).
as I wrote, this depends entirely on you, classes are what we want to see, everything that is blue, why not