Talk:Order of key parts

Generic Subkeys

What about :signed part? See https://taginfo.openstreetmap.org/search?q=%3Asigned Mateusz Konieczny (talk) 20:52, 3 January 2021 (UTC)

There are several of these, further examples are :wikidata, :wikipedia, :url... Unfortunately it seems these are not documented.

I think I'll add them as 'generic subkeys' after "subkey". --Mueschel (talk) 09:46, 4 January 2021 (UTC)

I edited your page before processing this reply - feel free to revert my edit.

Wiki Page location

Are you planning to move this page into public wiki space? Mateusz Konieczny (talk) 09:50, 4 January 2021 (UTC)

I think we should do this once it is "finished". Let's see how the RFC works out. --Mueschel (talk) 09:56, 4 January 2021 (UTC)

Examples

Maybe give some actual examples of tags? Such as turn:bus:lanes=*? Mateusz Konieczny (talk) 13:44, 4 January 2021 (UTC)

Additional syntaxes

Some additional syntaxes that come to mind:

• seamark:light:*=* keys are namespaced by an array index, which avoids the situation we have with destination:*=* where destination:ref:lanes=* and destination:lanes=* could be parallel lists of values that could get out of sync. The same approach has been proposed on the tagging list in the past for destination:*=*, but despite significant usage in some regions, it never gained traction on the relevant wiki pages. – Minh Nguyễn ^💬 10:31, 6 January 2021 (UTC)

  The seamarks are a good example for my remark on namespaces. Luckily this fits the scheme without modifications. The numbering of entries (up to 20 on one object...) I think is a specialty of this scheme, and not really universal. Sure there are many keys with numbers in them, but which are documented use cases and not just wild tagging? E.g. the use of numbers on multiple name tags is explicitly discouraged. --Mueschel (talk) 13:54, 6 January 2021 (UTC)

  It's related to the controversy over name_1=* etc. but not quite the same. The idea is that foo:1:bar=* and foo:1:baz=* apply to the same foo, and foo:3:bar=* and foo:3:baz=* also apply to the same foo even though foo:2:bar=* has no foo:2:baz=*. It isn't possible to express this situation using semicolon-delimited lists in values, unless we reinterpret the semicolon operator as an ordered operator and allow for consecutive ;; to indicate an empty slot. As far as I can tell, seamarks are the primary user of this numbering scheme (not only seamark:light=* but also seamark:notice=*), but it has been proposed for other schemes like destination=* (where it is endemic to some regions). I guess it's a question of whether we want to encourage or discourage that approach in the future. – Minh Nguyễn ^💬 19:42, 6 January 2021 (UTC)

• Speaking of destinations, there's a potential for multiple subkeys even before getting to the other parts in the table, such as destination:ref:to=* as opposed to destination:to:ref=*. Rarer, more extreme examples are destination:colour:int_ref:lanes:backward=*, destination:symbol:to:lanes:backward=*, and destination:ref:to:wikidata:lanes:backward=*. There seems to be an order within an order for that tagging scheme and perhaps others that heavily qualify keys, like railway:milestone:emergency_brake_override:*=*. – Minh Nguyễn ^💬 10:31, 6 January 2021 (UTC)

  Yes, there are plenty that have more than one subkey - should I make the entry on subkey in the table more explicit? Currently it says "potentially several of them in a row". Your examples are actually quite short with just 2 parts from the "subkey" category each. --Mueschel (talk) 13:54, 6 January 2021 (UTC)

  There are some other rare combinations, like destination:symbol:slight_right:upper=* (part of an experimental tagging scheme that tries to represent the layout of a destination sign). But my point is that the page could point out that some tagging schemes have their own standard sub-orders among the subkeys, which would be described on those tagging schemes' pages. The parking lanes tagging scheme is a pathological example of this: since it predates the conditional tagging and opening hours specifications, we wind up with keys like parking:lane:right:capacity:free:hourly:Sa:winter=*. But you did add a note about the parking lanes syntax being treated all as one giant chain of subkeys. – Minh Nguyễn ^💬 19:42, 6 January 2021 (UTC)

• Some transliterations are tagged as :language:transliteration rather than :language-transliteration, such as name:kn:iso15919=*. – Minh Nguyễn ^💬 10:31, 6 January 2021 (UTC)

  Are there any others like this? I haven't seen this scheme before, and can't find any other examples. I'd think of this as a case of a colon being part of a (sub)key (which isn't great by design at all). --Mueschel (talk) 13:54, 6 January 2021 (UTC)

  You're right that it could be treated as a typographical quirk. It's possible that there were once other examples, but I can't find any anymore, so probably mappers have coalesced around :language-transliteration or :language_transliteration by this point. – Minh Nguyễn ^💬 19:42, 6 January 2021 (UTC)

• When a public transportation station has different names or refs depending on the network, the station is tagged with name:network. (That means the key can be ambiguous in terms of distinguishing one network from another or distinguishing a network from a country.) As with ref=*, this usage can be viewed as either an arbitrarily large set of subkeys or a more general syntax along the lines of :language. – Minh Nguyễn ^💬 10:31, 6 January 2021 (UTC)

  I think your example of names given by different organizations is one of the few legitimate use cases of this free-text parts in keys apart from the use in 'ref'. I would like to leave this to the individual tag descriptions (as you suggest as an infinite set of subkeys). I'll add note somewhere. --Mueschel (talk) 13:54, 6 January 2021 (UTC)

Responses ordered by item numbers:

--Mueschel (talk) 13:54, 6 January 2021 (UTC)

@Mueschel: I took the liberty of inlining your responses to keep the discussion clear. – Minh Nguyễn ^💬 19:42, 6 January 2021 (UTC)

potential exceptions: the [meta] information seems sometimes set as prefix and sometimes set as suffix

Thanks for the overview. See title, example lists for source / note are:

	source	note
prefix	source:*	note:*
suffix	*:source	*:note

--MalgiK (talk) 14:21, 28 January 2021 (UTC)

I would assume that tiger:source=* is TIGER-quality imported tag, generator:source=* is not meta information, maxspeed:source=* is not meta information (or not meta in this way as source usually is?), plant:source=* - not meta... Mateusz Konieczny (talk) 14:36, 28 January 2021 (UTC)

These are difficult cases. 'source' as a Subkey as in generator and plant tags are clearly not a problem, but the order used for tiger:source, addr:source, mapwithai:source is not easy to cover in this simplified scheme. Apart from noting it as exceptional, we could add source and note to the 'Generic' (and have it in both the Meta and Generic classes). On the other hand - I don't like to promote this order... --Mueschel (talk) 16:20, 7 February 2021 (UTC)

reservation:website <> website:reservation

wonderful analysis ! what's about reservation:website <> website:reservation ? is the key is reservation and with subkeys website phone email ? or the key is website with subkeys reservation map stock ? what could be the rule to determine it ? --Marc marc (talk) 06:33, 17 February 2021 (UTC)

This can get a bit complicated to define globally without a proper definition of the individual tag.

In this special case, I'd say the best key is 'reservation:url', because it follows the same scheme as for example opening_hours:url or lunch:menu:url. --Mueschel (talk) 11:03, 17 February 2021 (UTC)

Can we move it into main space?

Can it be treated as sort-of-ready? I just tried to search it in Order of key parts Key part order Segment order Order of elements in key Mateusz Konieczny (talk) 08:56, 24 July 2022 (UTC)

If you (and others) think this is ready to be made official, feel free to do so. It still contains quite a bit of personal view and preference , which I don't want to press onto others. --Mueschel (talk) 15:26, 24 July 2022 (UTC)

I moved it, with it being in the main space others are more likely to improve it Mateusz Konieczny (talk) 17:57, 24 July 2022 (UTC)

More precise advice on combination

It would be nice to more precisely describe how the key parts may be combined (e.g. after :wikidata no other key suffixes make sense). --Push-f (talk) 14:29, 24 July 2022 (UTC)

Well, if we can define such rules it might be helpful, but I doubt they are easy to define. Actually, we do have several hundred tags like destination:ref:wikidata:lanes=* - and I don't have arguments why this order needs to be changed - it's the wikidata link for the ref.

Actually this pointed me to an error in the list: We do have old_name:-2022:etymology:wikidata=*, which contradicts my order of putting 'Date' last and needs some additional work.--Mueschel (talk) 15:26, 24 July 2022 (UTC)