[Tagging] Feature Proposal - RFC - Power utility office

[François Lacombe]

Hello,

Le lun. 21 nov. 2022 à 08:15, Warin <61sundowner at gmail.com> a écrit :

> Some offices are involved in the sale and administration of the utility.
>
It's true, and not in operation.
utility=* was designed with technical stuff in mind and it would not cause
so much harm to extend it to administrative facilities *with appropriate
building=* or office=* values* as proposed.
I just want to encourage to do it with caution.

> Buried utilities here were legally required  to be in separate trenches,
> that has changed so that one trench can be used for multiple utilities, so
> it may be required for the key 'utility' to accept multiple values.
>
utility=* covers ducts, not trenches (a single trench for several ducts,
indeed its better to do so).
The only situation where a single duct host several different utilities is
in utility tunnels. Here utility=multi would be more valuable than
utility=power;telecom;heating;whatever
https://www.nationalgrid.com/electricity-transmission/network-and-infrastructure/london-power-tunnels-project
=> utility=power
https://ceriu.qc.ca/system/files/2020-01/D3.5_Carolina%20Puig%20Gimeno_V2.pdf
(2000s utility tunnels) => utility=multi


> The key 'utility' has evolved over time from only  the key 'marker' to
> also accepting the tags 'man_made=utility_pole' and 'building=service'.
> Further evolution might take place.
>
Agree with this, if and only if we're able to always distinguish offices
from operational stuff and if we keep a single value in it.
Offices in building=service would be a mess for instance.
Allowing several values may encourage unwanted usage.

Le lun. 21 nov. 2022 à 08:43, stevea <steveaOSM at softworkers.com> a écrit :

>
> While I regret not doing simple wiki research that would have revealed a
> collision with my “out loud imagining” clearly-stated to be just that (an
> IMAGINED tagging scheme for utility=*), I do stand by my post as an
> exercise in potential (not necessarily actual, again, clearly stated)
> key=value pairs.
>

No offense intended and finally it may lead to a viable solution with using
existing tagging so it will be fine.

All the best

François
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20221122/8bea1a3e/attachment-0001.htm>