[Tagging] Structured vs. duck tagging tendency

John Willis johnw at mac.com
Wed Jan 6 20:55:38 UTC 2016

> On Jan 5, 2016, at 8:32 PM, Tom Pfeifer <t.pfeifer at computer.org> wrote:
> structured vs. duck tagging.

I don't think that structured vs duck tagging in general is incompatible. As with most things, it is a bell curve of where people would like to stop and segment things, which is why getting feedback (and deciding to stick with a compromise in some situations) is important. 

Martin brought up a good example of the information tag - and is a beautiful example of "scope creep" - just as OSM was envisioned to define roads and town level amenities, the scope of tagging now handles individual trees, lanes, and kerbs. The scope of the project changed to be much more detailed: 1-2 orders of magnitude more detail. Someday in the future, we will be defining the height and mounting method of a fire extinguisher in a hallway on a floor in a building. We're getting there. 

As Martin said - tourism=information was made for information offices / desks - but as detail on the map expanded, this was put into information as a subkey because tourism=map and tourism=guidepost was "harder" to get approved or adopted rather than a single subkey - and using the main tag as a category feels like it makes everything relate to information, rather than to tourism. 

While This does mean the top_level key does mean "nothing" - it is the artifact of the growth of OSM. It may not be ideal, but it might be the best way to expand OSM in a way where consensus can be reached - the the complexities of tagging can easily be hidden in presets. 

I think the pushback against the structured tagging is when the "duckiness" is expected to be defined via many tags - we have all kinds of width, access, lane, surface, and other ways of describing a road - down to the point where we could define everything about a road to say it is a motorway - but saying "this is a motorway" via a single tag value *in some manner* - either via a single tag or a subtag - feels so much better. Almost all road values above residential are describing their duckiness - not their width or whatever - we are defining their importance above residential and below motorway - which is very fuzzy in some instances. 

This is the biggest reason I want a trail tag. I know a "trail" when I see one - but I have no way to define one via some tag that feels "ducky" 

I currently use highway=trail because there is no other way that feels right to define one - as there is some way to define all other non-car ways to show their duckiness in OSM - either highway=cycleway for a cycleway or highway=footway+footway=sidewalk for a sidewalk. Either tagging method is fine with me. 

This lack of duckiness also is driving the aquatics_centre tag as well - it just doesn't feel right including them with gyms and collections of baseball diamonds.

I like the information= subkey, it feels like the shop= subkey or navigationaid= subkey - a place for very detailed descriptions of what a thing is, while the top level key gives you a category - not great for data providers, but better than having everything jumbled into tourism= or aeroway= for newer taggers. 

It is a way to remove options in tagging to make it easier for newer taggers - but still have the values available for proper tagging, and handles "scope creep" in OSM, pretty well - as long as we accept that that main tag gets "broken" in the process. 


More information about the Tagging mailing list