[Tagging] Benefits of namespaces

Sergio Manzi smz at smz.it
Thu Dec 20 03:01:48 UTC 2018


The discussion about this has also been brought to the forum, here: https://forum.openstreetmap.org/viewtopic.php?id=64825

I'm unsure if it is better to continue it here in the ML, there in the forum, or in both places...

On 2018-12-20 01:04, François Lacombe wrote:
> Le mer. 19 déc. 2018 à 22:26, Richard <ricoz.osm at gmail.com <mailto:ricoz.osm at gmail.com>> a écrit :
>     the OSM tag chain should be imho used only for very common things because each member
>     of the chain will turn up as a "top level" tag in the database and taginfo.
> We are using such chains in Power, Pipeline and Telecom groups. It works well :
> power=transformer + transformer=distribution + voltage:primary=20000 + voltage:secondary=400
> man_made=street_cabinet + street_cabinet=telecom + telecom=exchange + telecom:medium=copper + operator=Orange

"Transformers" is a perfect example of "namespacing done backward". Why "voltage:secondary=220"? In a correctly namespaced world it would be "secondary:voltage=220".

I understand that in spoken English you can say "the **voltage** of the *secondary *is *220 *Volt", and that's probably why those keys have been built with the terms in that particular order. (/BTW, logic and wording is very different in different cultures and languages. I think it wouldn't had been in that order in, say, German: can a german speaker please confirm that?/)

Transformers can have and very often have more than one secondary: you have dealt with that using things like "voltage:tertiary=*" and the likes (windings:tertiary=*, I suppose...). And what if the transformer has 3 secondaries? Or 4?

Isn't "secondary:1:voltage=200" better? Don't you see that's more logical and expandable? Don't you see that here we assign a quantity (220) to something that has the correct dimensions (voltage), like in the previously globally defined key "voltage=*"? Don't you see how with that syntax everything related to the first (/second, third, fourth,... nth/) secondary (/wingdings, current, whatever.../) would be grouped under "secondary:n:*="?

And if transformers weren't  meant to be a "/namespaced thing/", why using the columns? Why not voltage_secondary=* ?

Don't you see that with the transformers a *new first level keyword*, "rating=*" have been implicitly defined and documented in the transformers page and how that keyword can be useful in other contexts... or namespaces, if you prefer?

BTW, what is that telecom:medium=copper thing (https://wiki.openstreetmap.org/wiki/Key:telecom:medium)? /"Telecoms" /do not have a medium:  local loops have.  Is that meant to be a namespaced thing? Have this being debated/approved? I have seen it applied to buildings: what is the meaning of that?

> Adding power: and telecom: prefixes would be seriously bad to encourage for contribution and extremely redundant.

To the contrary! Please read in the forum my rationale explaining exactly how that would be beneficial...

> Furthermore, refining of well used tags often get discouraged because of their usage.
> This dosn't include the redundancy in namespaces' prefixes which is worse.
>     If used extensively for attributes I would consider it polution of the database.
>     It is also much less flexible as you can specify only one attribute at a time.
> If you have to define more than one attribute with the same name it may be the attribute isn't weel defined.
> Have you examples please?
> All the best
> François

Sorry, I'm really now on the verge (/less than 24 hours.../) of a small journey, so I would probably be unable to answer/contribute anymore until January, 6.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181220/e2edbf10/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3675 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181220/e2edbf10/attachment-0001.bin>

More information about the Tagging mailing list