Re: [Tagging] Benefits of namespaces

[Mateusz Konieczny]

19 Dec 2018, 22:24 by ricoz@gmail.com:

> 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. 
> If used extensively for attributes I would consider it polution of the 
> database.
>
There is nothing wing with using many
key names.

It may be a good idea to improve detection
of "top level" tags, but it is ok to use
tag chains before it happens.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

Good, thank-you!

I wasn't aware of that, but I'm not an EE and that's why I've asked to ask one: 
this kind of things are much better handled by experts in the field.

But anyway I have the strong feeling that that wasn't the meaning the person 
who described transformers had in is head: "/Tertiary, quaternary and further 
sides are intended for lower voltages auxiliary services inside power plants or 
substations/", which, in the description you pointed at, is _at most_ a 
"by-product" of using a tertiary .

Sergio


On 2018-12-20 14:05, Paul Allen wrote:
> On Thu, 20 Dec 2018 at 12:36, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> The definition of primary v.s. secondary is about which is the exciting 
> part and which is the excited part. "tertiary" is pure nonsense, AFAIK.
>
>
> Power transformers can have tertiary windings:
> https://www.electrical4u.com/tertiary-winding-of-transformer-three-winding-transformer/
> although it may not be sensible to map the ratings of a tertiary.
>
> Some transformer-isolated voltage converters may make use of a feedback 
> winding which is
> (at least informally) referred to as a tertiary winding.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Paul Allen]

On Thu, 20 Dec 2018 at 12:36, Sergio Manzi  wrote:

The definition of primary v.s. secondary is about which is the exciting
> part and which is the excited part. "tertiary" is pure nonsense, AFAIK.
>

Power transformers can have tertiary windings:
https://www.electrical4u.com/tertiary-winding-of-transformer-three-winding-transformer/
although it may not be sensible to map the ratings of a tertiary.

Some transformer-isolated voltage converters may make use of a feedback
winding which is
(at least informally) referred to as a tertiary winding.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

That's about windings, and of course in the primary of a 3 phase transformer 
you'll generally (/there are exceptions.../) have 3 windings, but those 3 
windings together make up the primary side of the transformer.

The definition of primary v.s. secondary is about which is the exciting part 
and which is the excited part. "tertiary" is pure nonsense, AFAIK.

Sergio


On 2018-12-20 13:27, Xavier wrote:
> On Thu, Dec 20, 2018 at 01:00:20PM +0100, Sergio Manzi wrote:
>> I *never *heard of a transformer's /tertiary/, thus: try asking an 
>> electrical engineer...
>
> In general, a transformer can have 1..N primary windings and 1..N secondary 
> windings:
>
> https://www.electronics-tutorials.ws/transformer/multiple-winding-transformers.html
>
> The most common is the 1:1 (single primary, single secondary) transformer, 
> followed next by a 1:N style (one primary, multiple secondary, this is 
> usually used to provide plural output voltages from the same single 
> transformer).
>
> But in the general case (which is what OSM would, at some point, want to be 
> able to cover), a transformer is N:N with each N being 1..X.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Xavier]

On Thu, Dec 20, 2018 at 01:00:20PM +0100, Sergio Manzi wrote:
I *never *heard of a transformer's /tertiary/, thus: try asking an 
electrical engineer...


In general, a transformer can have 1..N primary windings and 1..N 
secondary windings:


https://www.electronics-tutorials.ws/transformer/multiple-winding-transformers.html

The most common is the 1:1 (single primary, single secondary) 
transformer, followed next by a 1:N style (one primary, multiple 
secondary, this is usually used to provide plural output voltages from 
the same single transformer).


But in the general case (which is what OSM would, at some point, want 
to be able to cover), a transformer is N:N with each N being 1..X.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Martin Koppenhoefer]

Am Do., 20. Dez. 2018 um 11:53 Uhr schrieb Sergio Manzi :

> ... unless we start putting columns (":") into keys according to a
> different logic.
>


it really doesn't matter, unless we would actually need those namespaces
(i.e. they would collide by using the exact same string on the left side,
to express something different), it would not be a problem if some mappers
tag voltage:secondary and others secondary:voltage.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

... unless we start putting columns (":") into keys according to a different 
logic.


On 2018-12-20 11:44, Martin Koppenhoefer wrote:
> Am Do., 20. Dez. 2018 um 11:36 Uhr schrieb Claudius Henrichs 
> mailto:claudiu...@gmx.de>>:
>
> It feels like the two arguments are about stying true to how namespaces 
> are defined as a model in information technology and remaining economically 
> shorter to be readable to humans. And there's not much of a compromise to 
> make. It's either or.
>  
>
>
> actually not, you can do both in most cases, as they use different keys. It 
> isn't generally desirable to do it, but it would be possible.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Martin Koppenhoefer]

Am Do., 20. Dez. 2018 um 11:36 Uhr schrieb Claudius Henrichs <
claudiu...@gmx.de>:

> It feels like the two arguments are about stying true to how namespaces
> are defined as a model in information technology and remaining economically
> shorter to be readable to humans. And there's not much of a compromise to
> make. It's either or.
>
>



actually not, you can do both in most cases, as they use different keys. It
isn't generally desirable to do it, but it would be possible.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Claudius Henrichs]

It's not ideal, but I copied your replies over to the forum.

I've tried to move to my concrete example so we could test out the application of what each of you are suggesting in my reply: https://forum.openstreetmap.org/viewtopic.php?pid=730429#p730429

 

It feels like the two arguments are about stying true to how namespaces are defined as a model in information technology and remaining economically shorter to be readable to humans. And there's not much of a compromise to make. It's either or.

 

Best regards,

Claudius

 

Gesendet: Donnerstag, 20. Dezember 2018 um 04:01 Uhr
Von: "Sergio Manzi" 
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Benefits of namespaces



François,

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@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=2 + 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.

Cheers,

Sergio
___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

François,

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  > 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=2 + 
> 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.

Cheers,

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[François Lacombe]

Le mer. 19 déc. 2018 à 22:26, Richard  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=2 +
voltage:secondary=400
man_made=street_cabinet + street_cabinet=telecom + telecom=exchange +
telecom:medium=copper + operator=Orange

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

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Richard]

On Tue, Dec 18, 2018 at 10:20:35PM +0100, Claudius Henrichs wrote:
> I couldnt be happier to have the "Benefits of namespaces" discussion 
> happening right now on this ML.
> 
> I am about to finalize a tagging proposal for a new sub-tag. I am wondering 
> about the pros and cons of the traditional "OSM tag chain" (foo=bar + 
> bar=baz) versus "Laymans namespacing" (foo=bar + bar:type=baz). Ive laid 
> out what I found on the forum and would be curious to learn what your 
> recommendation be.

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. 
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.

Richard

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

Visible now! :-)

On 2018-12-19 03:30, Sergio Manzi wrote:
>
> Thank-you Claudius,
>
> I've posted an answer in the forum, but I'm afraid it is awaiting for 
> moderation (I'm new to the forum...).
>
> Cheers,
>
> Sergio
>
>
> On 2018-12-18 22:20, Claudius Henrichs wrote:
>> I couldn't be happier to have the "Benefits of namespaces" discussion 
>> happening right now on this ML.
>> I am about to finalize a tagging proposal for a new sub-tag. I am wondering 
>> about the pros and cons of the traditional "OSM tag chain" (foo=bar + 
>> bar=baz) versus "Laymans namespacing" (foo=bar + bar:type=baz). I've laid 
>> out what I found on the forum and would be curious to learn what your 
>> recommendation be. Particularly in regard to improved human readability 
>> versus "staying true to the definition of namespace":
>> https://forum.openstreetmap.org/viewtopic.php?id=64825
>>  
>> I am happy for you to reply here on the ML and I will try to summarize your 
>> input in the forum thread this coming weekend.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Claudius Henrichs]

I couldn't be happier to have the "Benefits of namespaces" discussion happening right now on this ML.

I am about to finalize a tagging proposal for a new sub-tag. I am wondering about the pros and cons of the traditional "OSM tag chain" (foo=bar + bar=baz) versus "Laymans namespacing" (foo=bar + bar:type=baz). I've laid out what I found on the forum and would be curious to learn what your recommendation be. Particularly in regard to improved human readability versus "staying true to the definition of namespace":

https://forum.openstreetmap.org/viewtopic.php?id=64825

 

I am happy for you to reply here on the ML and I will try to summarize your input in the forum thread this coming weekend.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Simon Poole]

Am 17.12.2018 um 13:01 schrieb Paul Allen:
> ..
>
> This isn't theoretical speculation.  The author of iD has, in the
> past, expressed unhappiness
> about such re-usability.
> ...

This is a specific to iD and not a general concern, and simply has to do
with that in a lot of cases iD doesn't actually have presets values for
specific keys and attempts to retrieve them from taginfo. This in turn
leads to a specific taginfo issue that taginfo can't differentiate
between say: the service key used on a highway=service and the service
key used of railway=service.

With other words: it is really not a preset issue.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

Thanks, me too! :-)

If you are interested in this kind of things, have a look at the following 
(/not an exaustive list of topics, just a random one.../):

  * https://en.wikipedia.org/wiki/Namespace
  * https://en.wikipedia.org/wiki/Uniform_Resource_Name
  * https://en.wikipedia.org/wiki/Lex_(URN)
  * https://en.wikipedia.org/wiki/LSID

Cheers!

On 2018-12-17 15:24, François Lacombe wrote:
> By the way I apreciate the discussion and this certainly improve the 
> knowledge about tagging possibilities and principles.
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[François Lacombe]

Le lun. 17 déc. 2018 à 14:26, Sergio Manzi  a écrit :

> Sorry, I didn't meant to be rude in any way: I just assumed you were the
> one who introduced the switch=* key for power lines (*and apparently I
> was wrong, you just "expanded" the information about those...)*
>

Me neither, switch=* was firstly de facto used and then documented on wiki
with a proposal.


> Bingo. Now try substituting the "=" sign with the ":" sign
>

This would be redundant with railway=switch and power=switch :)
Be sure I'll be blamed for that just like I'm blame to don't use namespaces.


> If you do the same inside an objects description, an editor or data
> consumer could instantly "*route*" you to the relevant documentation when
> you are inspecting that particular object (*either a railway switch or a
> power switch*).
>
Editors like JOSM have context=x" concept to make the distinction.
https://josm.openstreetmap.de/wiki/TaggingPresets#Attributes
JOSM maintainers told me they prefer actuator=* as it's more simpler to
type and users don't have to be annoyed with that.
I understand that editors have more work to do to deal with such generic
keys, but editors should help users and not the contrary shouldn't you ?


> Yes, the context (*either we find the "switch" keyword inside the
> definition of a power line, a railway or a network*) can imply the
> lexical scope of the keyword, and most of the times that's self-evident for
> us humans, but it is a lot more difficult to *teach *to a program.
>
That's not so clear depending on which editor maintainer you ask.
Processors have to deal with tags associations, namespaces won't prevent
them to be smart anyway i'm affraid.


> Then actuator is an attribute of several kind of objects (pipeline=valve
> and eventually railway=switch), just like location.
> I don't get where I confuse something between actuator=* like tags and
> location=*
>
> Here is where I think you make the mistake.
>
> The actuator is *not an attribute* of the things (pipeline=valve and
> eventually railway=switch), but a *part/element* of them.
>
> Someone someday may be wishing to further describe actuators in their own
> details/attributes, like now you are doing for valves which are
> parts/elements of a pipeline.
>
Currently it is an actual attribute for sake of simplicity for contribution
and inventory, because we consider the system {valve + actuator}.

Then in eventual future, we will need another node to separate the actuator
from the valve and a way connecting the valve and the actuator to map the
mechanical link.
That should be done for transformers on top of poles, antennas on top of a
mast, windows on a given house and so on...
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

By the way I apreciate the discussion and this certainly improve the
knowledge about tagging possibilities and principles.

François
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

Bonjour François,

On 2018-12-17 11:50, François Lacombe wrote:
> I own no switches.
Sorry, I didn't meant to be rude in any way: I just assumed you were the one 
who introduced the switch=* key for power lines (/and apparently I was wrong, 
you just "expanded" the information about those...)/

> Separated documentation between railway switches and power switches is done 
> on two pages, *railway=switch* and *power=switch*,

Bingo. Now try substituting the "=" sign with the ":" sign.

If you do the same inside an objects description, an editor or data consumer 
could instantly "/route/" you to the relevant documentation when you are 
inspecting that particular object (/either a railway switch or a power switch/).

The same could happen tomorrow for a network:switch if/when we decide to map 
them too.

Yes, the context (/either we find the "switch" keyword inside the definition of 
a power line, a railway or a network/) can imply the lexical scope of the 
keyword, and most of the times that's self-evident for us humans, but it is a 
lot more difficult to /teach /to a program.

> Then actuator is an attribute of several kind of objects (pipeline=valve and 
> eventually railway=switch), just like location.
> I don't get where I confuse something between actuator=* like tags and 
> location=*

Here is where I think you make the mistake.

The actuator is _*not an attribute*_ of the things (pipeline=valve and 
eventually railway=switch), but a *part/element* of them.

Someone someday may be wishing to further describe actuators in their own 
details/attributes, like now you are doing for valves which are parts/elements 
of a pipeline.

Weight, dimensions, color, location, etc., are general attributes of whatever 
object.

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Paul Allen]

On Mon, Dec 17, 2018 at 1:25 AM François Lacombe 
wrote:

>
> I still think that actuator=* is better than two pipeline:valve:actuator=*
> and railway:switch:actuator=* because the first is really more concise and
> reusable between valves and railway switches.
> Like I don't like fire_hydrant:position instead of simpler location=*.
>
> Can someone brings benefits from using namespaces in this particular
> situation please?
>

There is a benefit to the authors of editors such as iD and JOSM when the
set of values for the two
different use cases is not identical.  So if valve actuators take the
values A, B, and C, whilst
railway actuators take the values A, X,  and Y, this causes code complexity.

The reason is that a key like pipeline:valve:actuator can be handled as a
list of values A, B, C
and a key like railway:switch:actuator can be handled as a list of values
A, X and Y.  But if it's
just actuator=* for both then the editor needs extra code to present
whichever values are valid
for the appropriate primary key.  It's not much for any one key, but it
starts to add up when there
are several keys like that.  Alternatively the editor just presents a list
of A, B, C, X and Y in both
cases and then people end up accidentally using values that are
inappropriate simply
because they're in the list.

Even if the values are of one are a subset of the other, it means that
extra code is needed to
distinguish between the two primary keys to decide whether to present a
limited list or a full
list of values.  Throw in potential complications with associated keys that
may differ between
the two types of actuator (do railway actuators have "turn to open"?) then
the code can get
messy.

This isn't theoretical speculation.  The author of iD has, in the past,
expressed unhappiness
about such re-usability.

I'd also guess that such re-use also causes similar problems on the carto
side if, for example,
railway actuators get different rendering from pipeline actuators.

Although my first instinct would be to minimize the number of keys in the
database that turns
out to be a premature optimization.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[François Lacombe]

Hi Sergio,

Le lun. 17 déc. 2018 à 02:38, Sergio Manzi  a écrit :

> Now, for the reasons for namespacing and just as an example (*it is not
> the only good reason...*), think about documentation: the documentation
> for describing a power switch should not be intermixed with the
> documentation describing power switches. The railways people got that and
> they did what I think they had to do: to namespace their switch. You didn't
> (*if that was you...*). Big mistake, IMHO: not all the switches are your
> switches..
>

I own no switches.
Separated documentation between railway switches and power switches is done
on two pages, railway=switch and power=switch, pictures and examples are
This does not prevent *at all* them to share some common aspects, which can
be grouped on a third page like actuator=electric_motor as to gather
different situations linked to that same concept.
My point isn't to make railway=switch look the same as power=switch, but to
not waste time defining more keys than required and "meet" railway people
who can bring useful insight for power mapping also.

Le lun. 17 déc. 2018 à 03:07, Sergio Manzi  a écrit :

> BTW, if that's not clear:
>
>- railway:switch describe/is an *object*
>- fire_hydrant:position describe/is an *attribute *of the fire_hydrant
>object
>
> Then actuator is an attribute of several kind of objects (pipeline=valve
and eventually railway=switch), just like location.
I don't get where I confuse something between actuator=* like tags and
location=*

All the best

François
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

BTW, if that's not clear:

  * railway:switch describe/is an *object*
  * fire_hydrant:position describe/is an *attribute *of the fire_hydrant 
object, for which, you are right, location=* would had been correct.

On 2018-12-17 02:36, Sergio Manzi wrote:
>
> You are mixing correct namespacing (like railway:switch) with... mistaken 
> namespacing (like hydrant:position).
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

Sorry, I meant to say:

the documentation describing *railway switches* should not be intermixed with 
the documentation describing power switches


On 2018-12-17 02:36, Sergio Manzi wrote:
> the documentation for describing a power switch should not be intermixed with 
> the documentation describing power switches


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Sergio Manzi]

Hello,

You are mixing correct namespacing (like railway:switch) with... mistaken 
namespacing (like hydrant:position).

Now, for the reasons for namespacing and just as an example (/it is not the 
only good reason.../), think about documentation: the documentation for 
describing a power switch should not be intermixed with the documentation 
describing power switches. The railways people got that and they did what I 
think they had to do: to namespace their switch. You didn't (/if that was 
you.../). Big mistake, IMHO: not all the switches are your switches...

Sergio


On 2018-12-17 02:24, François Lacombe wrote:
> Hi
>
> Interesting thread about namespacing in tag names.
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pipeline_valves_proposal#Use_namespace_or_not
> Spoiler: no consensus shows up at the end.
>
> I still think that actuator=* is better than two pipeline:valve:actuator=* 
> and railway:switch:actuator=* because the first is really more concise and 
> reusable between valves and railway switches.
> Like I don't like fire_hydrant:position instead of simpler location=*.
>
> Can someone brings benefits from using namespaces in this particular 
> situation please?
>
> Al the best
>
> François
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Benefits of namespaces

[François Lacombe]

Hi

Interesting thread about namespacing in tag names.
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pipeline_valves_proposal#Use_namespace_or_not
Spoiler: no consensus shows up at the end.

I still think that actuator=* is better than two pipeline:valve:actuator=*
and railway:switch:actuator=* because the first is really more concise and
reusable between valves and railway switches.
Like I don't like fire_hydrant:position instead of simpler location=*.

Can someone brings benefits from using namespaces in this particular
situation please?

Al the best

François
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging