New man_made=utility_pole preset

[flacombe]

Dear maintainers

Following the recent approval of the man_made utility poles proposal, a new preset to use man_made=utility_pole with the following combinations could be useful
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dutility_pole

• utility=* The purpose for which the pole was design or installed
• operator=* Name of the company that operates the pole
• material=* The material composing the pole
• line_attachment=* Attachment mean for lines connected to that pole
• line_management=* Particular topology situations around the pole
• ref=* The reference of the pole as read on ground

A similar icon of one used for power=pole can be used.

A few validation rules also applies

• utility=* should have only one value, ;-lists are discouraged
• power=pole remains the standard to map power poles. when utility=power, man_made=utility_pole should be replaced by power=pole

Let me know if you consider including it in the iD tagging schema

All the best

[Adamant36]

utility=* should have only one value, ;-lists are discouraged

I don't think that's actually a thing. Even if the Wiki says it is. As there's plenty of uses of the tag with multiple values and utility poles IRL often times aren't confined to a single type of utility. In the meantime, I'd be interested to know where the sentence about it in the article came from and why it was added.

[flacombe]

As there's plenty of uses of the tag with multiple values and utility poles IRL often times aren't confined to a single type of utility

That's not the meaning of utility=*
Despite a given pole can carry many different stuff, it was designed for a main purpose. Side business comes... aside.

A power pole, operated by the power system operator, carrying telephone wires remains a power pole.

Furthermore, some features supported by such a pole don't refer to utilities (surveillance camera, traffic signs, advertisement...). Wiki also gives an extensive list of strategies to get what a pole actually supports
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dutility_pole#Logical_link_between_poles_and_supported_features

In the meantime, I'd be interested to know where the sentence about it in the article came from and why it was added.

Reviewed proposal can be found here: https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal

[Adamant36]

Despite a given pole can carry many different stuff, it was designed for a main purpose

Cool, I didn't ask what your personal opinion was though. In the meantime, where does anything besides the Wiki article say "it was designed for a main purpose?" Just repeating what the article says doesn't answer my question of where it came from.

Reviewed proposal can be found here

I'm talking about the utility key, not man_made=utility_pole. Their different tags and don't have anything to do with each other. Except that utility=* is used on utility poles sometimes, among many other things.

That said, from what I can tell neither of the proposals say that utility=* should only be to tag a single value. All Proposed_features/Utility_markers_proposal says is that utility=* is used to "state at which activity they refer to" and the last time I checked that can be multiple things. The proposal for man_made=utility_pole just specify either. So again, where besides the utility article does the idea that it's only supposed to be a single value come from?

[flacombe]

Cool, I didn't ask what your personal opinion was though. In the meantime, where does anything besides the Wiki article say "it was designed for a main purpose?"

It's part of several state of the art data models.

At least in France, you can find such similar tagging in gov's official documentation of utility networks data standard
http://cnig.gouv.fr/?page_id=17429

http://cnig.gouv.fr/wp-content/uploads/2019/11/CNIG_STAR-DT_v1.0.pdf
Page 26 you find the inheritance diagram for poles (among other features). It inherits an abstract class PCRS::AffleurantPCRS defined in a more high level standard.
See page 71 http://cnig.gouv.fr/wp-content/uploads/2019/02/CNIG_RTGE_PCRS_v2.0_r1.pdf for this class definition.
See the reseau field on page 72, typed as NatureReseauPCRSType, with a multiplicity of 0..1 which is equivalent to expect only one value for utility=* in OSM.

It has to be said we don't plan to import any data from anywhere. It's only about equivalency of data models here.

Their different tags and don't have anything to do with each other.

I disagree: tags are combined with usage guidelines. It was explicitly reviewed to use utility with a single value for utility poles.

It wasn't stated so explicitly for markers proposal (which introduced utility=* as well) but it should had been.
You barely find a single marker involved in several utilities, because several different companies are responsible of them and they will install their own marker, even in very close spots.

That said, from what I can tell neither of the proposals say that utility=* should only be to tag a single value

I may not get you well on this particular point.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal#Proposale
utility=* will be combined with it to give the main or original purpose of the pole. This key is expected with one unique value for a given pole, according to rationale downside.
Isn't this clear?

[Adamant36]

It's part of several state of the art data models.

That I assume have nothing to do with OSM. It should be obvious that how the French government and OSM tag things might converge in some places and that the standards in OSM override the later. Unless of course you do a proposal and get community buy in to adopt it. Which it doesn't seem like you have. Otherwise, we probably wouldn't be having this discussion right now.

It has to be said we don't plan to import any data from anywhere. It's only about equivalency of data models here.

OSM isn't suppose to be a 1/1 equivalent of government maps. Although, there's no reason you can't make it that way for utility poles if it's your personal preference to do so. But that's completely different from expecting there to be a preset that forces other people, who aren't mapping wrong by not including the operator, into it.

t wasn't stated so explicitly for markers proposal (which introduced utility=* as well) but it should had been.

Maybe it should have been, but the important thing was it wasn't. Although, I don't think it should have been just because the French governments GIS department does something a certain way. Since tags are suppose to be universally usable and I can guarantee places outside France don't do it how they do.

I may not get you well on this particular point.

Sure, I get that point. But like you say it's not in the original proposal and I'm not sure how much a proposal for an unrelated tag can override it. Like just because there's a proposal for something like shop=whatever that includes mention of another approved tag, it doesn't mean that the shop=whatever proposal can totally reinvent the other tagging scheme that it mentions. Let alone restrict it's usage. Otherwise, your overruling the original proposal/consensus and likely without involving the same people. If there was a specific proposal to modify the utility tag to only use one value I'd be cool with that though.

Also, the sentence you quoted is contradicted further down where it says "A pole can support several networks and different utilities." If a pole supports several utilities, then we should be able to tag that. There's no way to tell that "some side business come afterwards" either. Nor should it matter.

[flacombe]

This is definitely not a place to challenge what was previously voted, on which a consensus has been reached.
Utility poles proposal clearly define combination guidelines between man_made=utility_pole and utility=*. It doesn't redefine utility=* at all.

Current usage shows it's pretty always used with a single value.
https://taginfo.openstreetmap.org/keys/utility#values

just because the French governments GIS department does something a certain way

I'm not happy with the way you turn things. I'll stop providing explanations as they are used against valuable, discussed and reviewed work done by several contributors.

If a pole supports several utilities, then we should be able to tag that

Can you point me a proper resource stating this apart of your personal opinion please?

[Adamant36]

Utility poles proposal clearly define combination guidelines between man_made=utility_pole and utility=. It doesn't redefine utility= at all.

If the original utility=* proposal didn't specify that it should only have one value, but the proposal for man_made=utility_pole does then how is that not redefining how the utility=* tag can be used?

Current usage shows it's pretty always used with a single value.

There's a difference between "pretty always" and "always." I don't really care what the current usage is anyway. I care about what the original proposal said about how to use the tag or not. For all I know there's a small amount of multiple values because someone with a personal opinion that they were wrong did an un-discussed mass edit.

I'm not happy with the way you turn things. I'll stop providing explanations as they are used against valuable, discussed and reviewed work done by several contributors.

I don't know why your being defensive. It's just a fact that OSM and local governments will have different ways of tagging things. Every GIS department/website/whatever serves different needs and does things differently. It's just reality and it's not an insult to the French government to state there isn't going to be a 1/1 fit between how they do things and OSM.

Can you point me a proper resource stating this apart of your personal opinion please?

I'm sure your aware of the whole "Ground truth" thing. If the "ground truth" of a utility pole is that it serves multiple utilities then people should "Map what's on the ground" by tagging it that way.

[flacombe]

but the proposal for man_made=utility_pole does then how is that not redefining how the utility=* tag can be used?

It brings precision on how to use it in this particular context.
Many proposals involve existing generic tags like location=*, usage=*... keys and sometimes complete them with additional values or so. It didn't cause any harm to existing practices as far as I remember.
People involved in RFC or voting are fully aware of that. How would it be possible to define keys like location=* with a single proposal to cover all possible situations on a large diversity of knowledge ?

I care about what the original proposal said about how to use the tag or not

Experience, tests, admit to be wrong and lessons learnt are more important than what wasn't part of a proposal written with less knowledge in mind, aren't you?

I don't know why your being defensive. It's just a fact that OSM and local governments will have different ways of tagging things.

Because the point isn't to enforce local SIG practices in OSM but to get inspired by what is currently working elsewhere.

If the "ground truth" of a utility pole is that it serves multiple utilities then people should "Map what's on the ground" by tagging it that way.

Tagging isn't the only informational mean in OSM. Topology is a good one as well.
It is well described how this should be achieved in a more efficient way than tagging only: https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dutility_pole#Logical_link_between_poles_and_supported_features

Practical example: a power pole (operated by the power distribution operator) supports a minor power line, a fibre to the home cable and a surveillance camera.
You may expect utility=power;telecom;surveillance

• First problem: surveillance isn't an utility, intending to describe all features supported by the pole with utility=* is vain.
• Second problem: Adding a telecom line on a pole designed for power doesn't make it a telecom pole
  Finally, utility=power remains the only valid option here.

There is a difference between what the pole actually is and what it supports. utility=* only focuses on the first.

[Adamant36]

Many proposals involve existing generic tags like location=, usage=... keys and sometimes complete them with additional values or so. It didn't cause any harm to existing practices as far as I remember.

Sure, but your assertion from the start of this has been that the utility=* was designed for a single purpose. Not that there is just an exception made for utility poles. Nor is that how the utility Wiki article edited to make it sound. From what I can tell the standard was changed in the utility_pole proposal and then post hawk applied to the utility tag more general. Not just in cases of utility poles. Which is why I have a problem.

I likely wouldn't care if the utility pole proposal wasn't applied more broadly though and just stuck to utility poles where it was intended. No one tagging pipelines, substations, or any other utility besides utility poles had a say in it being applied to their use case though.

Because the point isn't to enforce local SIG practices in OSM but to get inspired by what is currently working elsewhere.

I disagree that presets equate to inspiration. I think your reading to much into their effect at the cost of other, probably better, avenues to get what you want done. That's all.

You may expect utility=power;telecom;surveillance

I wouldn't expect utility=surveillance for the reason you gave. I don't think there's a clear difference between what a pole was designed for and what it supports either. It would be weird to continue tagging a utility pole as utility=power if it is converted to only carry telecommunications wires just because of what it's original use was.

If you want a better example, there's utility poles in my area that both carry power and serve as street_lighting. So in that case should I revert someone if they add utility=power;street_lighting just because the pole was originally made for transferring power? Personally, I'd like to think the power infrastructure and street lighting infrastructure mappers can coexist.

[flacombe]

From what I can tell the standard was changed in the utility_pole proposal and then post hawk applied to the utility tag more general. Not just in cases of utility poles.

It indeed went beyond the extent I wanted to give. I've adjusted the guidelines and removed the need of a single value in utility documentation.

I disagree that presets equate to inspiration.

It's not about presets but tagging model there. Existing practices can inspire us to propose new tags or adapt existing ones, nothing more.
It sounds different to me.

I don't think there's a clear difference between what a pole was designed for and what it supports either

A pole may last ~50 years and usage may evolve since its installation. We roll out fibre to the homes while it wasn't even an idea when electricity came years ago.

It would be weird to continue tagging a utility pole as utility=power if it is converted to only carry telecommunications wires just because of what it's original use was.

In such situations it depends if the pole remains a power operator asset or being sold to another company instead. Local signage will change, local policy could also be adapted. It's anyway a mean to raise quality error and encourage to check what happen in details because it's unusual (and local practices influence a lot)

So in that case should I revert someone if they add utility=power;street_lighting just because the pole was originally made for transferring power?

yes
It's a power pole supporting a street lamp, not the opposite.

Personally, I'd like to think the power infrastructure and street lighting infrastructure mappers can coexist.

They actually coexist since you'll find a power pole member of a power (minor) line and completed with highway=street_lamp.

This could finally change if the power line is removed, the street lamp will remain and utility will change to street_lighting.

[Adamant36]

It indeed went beyond the extent I wanted to give. I've adjusted the guidelines and removed the need of a single value in utility documentation.

Thanks. I appreciate your willingness to listen to feedback and adjust things.

Existing practices can inspire us to propose new tags or adapt existing ones, nothing more.

True. I don't disagree.

hey actually coexist since you'll find a power pole member of a power (minor) line and completed with highway=street_lamp.

I mostly agree with that. Except I think the existence of a physical street lamp is different from street lighting infrastructure more generally. Which, if I am reading the Wiki correctly, is what the utility tag is meant to convey. I don't know how things work in France, but in a lot of countries street lighting utilities are different departments then general power is.

Semi-related, but likely off topic. where I live power poles are owned and maintained by PG&E, but leased by them to the local governments electric utility for their power lines to be ran on. So the whole thing is pretty convoluted. I don't know how it would be reflected in tagging. I guess different operators for the poles and powerlines or something. A lot of the power poles have multiple reference numbers (PG&E, local utility, closest address, Etc. Etc.). I usually just leave all of them out when I'm mapping except the local utilities 🤷‍♂️

[flacombe]

I don't know how things work in France, but in a lot of countries street lighting utilities are different departments then general power is.

Exactly and that's why street lightly is mostly out of power=* key in OSM.

I don't know how it would be reflected in tagging. I guess different operators for the poles and powerlines or something. A lot of the power poles have multiple reference numbers (PG&E, local utility, closest address, Etc. Etc.)

Interesting situation
If the poles are actually rented, PG&E remains the operator on the power=pole feature and then lines could have different operator=* on their own.

In France we have different ref:FR:* keys to store reference which allows to combine several on the same object
For instance ref:FR:RTE (transmission), ref:FR:gdo (distribution).

It's sometimes better to only map geometries and leave operational knowledge for further contribution when it will have been solved.

[Dimitar5555]

The preset has been added.

[flacombe]

Hello @Dimitar5555

What was the PR related to this preset please?

[Dimitar5555]

@flacombe There doesn't seem to be a PR. See https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/man_made/utility_pole.json.

[flacombe]

This file was created by the end of 2020

But the proposal was voted in June 2021: https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal
It needs an update and it is what this issue asks for.

[Dimitar5555]

You are right. I though that all of the fields were added. I've created a PR which will resolve this issue.

[flacombe]

So nice!

I'll have a glance at it shortly