[Tagging] Power tower and pole usefulness

François Lacombe francois.lacombe at telecom-bretagne.eu
Mon Oct 7 20:46:43 UTC 2013


Hi,

Please note the update of the power transmission proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement

1. Removing the man_made=pole / man_made=tower introduction
- Deeper work should be done both in power and telecommunication fields to
find a proper way to define supports (like tower, poles, trees, buildings,
whatever) in a consistent and sustainable way that proposal can't cover.
- The substation refinement proposal was accepted today and it was
important to be consistent with its "hosted features on poles"
recommendations.
- Things stay as now and this topic may be come back in debate in a couple
of months with a new proposal

2. Replacing cables=* and wires=* by bundles=* and conductors=* for power
lines phy description as suggested by polderrunner on talk.

3. Power line description is done as "strings of towers".
Numerical values to describe it are always given without any circuit
considerations.
Circuits (I.e. path used by power to from A to B) will be described as
relations in the power routing proposal (which is currently draft) and will
actually accept power=line ways as member.
This prevent us to put useless redundancy (and consistency errors not to
mention) in database.

4. power=cable deprecation remains here. power=line aims to be the only way
to describe a power line whatever its location.
Please keep in mind this big change is intended to improve the "system"
approach more than any rendering or local terminology particular case...
and it's hard work.

You can send me any formal and constructive suggestion about that.
Vote will begin shortly. Stay tuned.

Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2013/9/23 François Lacombe <francois.lacombe at telecom-bretagne.eu>

> Hi,
>
> I can't open voting right now since some other points are still incomplete
> (RFC outlined comments and it's time to find a solution).
> Moreover, substation refinement vote is currently opened, one thing at a
> time.
>
> Be sure I'm willing to propose a good solution to the multiple power
> instances on the same node.
> But it's hard work to look wide and time is currently missing for me.
> That's why it's not good to launch vote now too : proposal has 99% chances
> to be rejected regarding this point and I don't want to recap my investment
> to that.
>
> Sorry but the "consistency thread" was too big to follow it correctly :(
>
>
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
>
> 2013/9/23 Pieren <pieren3 at gmail.com>
>
>> On Sun, Sep 22, 2013 at 9:38 PM, François Lacombe
>> > Deprecating power=tower and power=pole was my first proposition.
>> > Many people goes against it and then I refined the proposal.
>> > For now I'm just introducing man_made=tower + tower:type=power to use it
>> > when power=* is needed to describe hosted devices.
>> > Thus, man_made=tower doesn't seem to be the perfect solution, so let's
>> try
>> > to find it but the topic isn't to deprecate power=tower because it
>> won't.
>>
>> François, another thread on this ML was opened about "consensus in
>> OSM" and raised some inconsistencyies in our taging documentation. And
>> now, you are creating a new inconsistency. You already got some advice
>> about how to fix the "power" tag issue when you need the key more than
>> once (use subtags). Please, open now a "vote" on your proposal to get
>> some feedback from a larger audience and see if you are in the right
>> direction or not.
>>
>> Pieren
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20131007/e37be064/attachment.html>


More information about the Tagging mailing list