[Tagging] Fwd: Feature proposal - RFC - Power transmission refinement
francois.lacombe at telecom-bretagne.eu
Sat Jul 27 11:08:23 UTC 2013
Here is a mail that can be useful to see in ML.
---------- Forwarded message ----------
From: François Lacombe <francois.lacombe at telecom-bretagne.eu>
Subject: Re: [Tagging] Feature proposal - RFC - Power transmission
To: Bryce Nesbitt <bryce2 at obviously.com>
2013/7/27 Bryce Nesbitt <bryce2 at obviously.com>
> On Fri, Jul 26, 2013 at 3:43 PM, François Lacombe <
> francois.lacombe at telecom-bretagne.eu> wrote:
>> 2013/7/26 Bryce Nesbitt <bryce2 at obviously.com>
>>> But you're changing the definition of an existing tag,
>>> over the objections of existing mappers. You can do better.
>> Ok. What's your suggestion about that ?
> The basic suggestion is for you to show some public concern for matching *
> existing* tagging practice and harmonize.
Thus you think that the proposal here isn't harmonizing enough ?
Have a look to man_made=pipeline model to see how power and pipeline will
be closer if this proposal is accepted.
location is used by pipeline... not by power.
Pipeline include water distribution. Those networks are maybe longer than
power ones. Let's think about it.
> In support of your proposals you could seek support from the
> P2/JOSM/Mapnik communities to redefine the tag. If the rendering editing
> and wiki are all in harmony, then changing existing use is practical.
> Without that support the rendering is likely to lag for many years.
I'm convinced into rendering is more blocked by mapcss than by the tagging
I think that tagging is central instead of rendering which only is
peripheral. Tagging isn't only useful to render, according to what I write
at the bottom of this message.
> The location tag is not usually used for visible vs. underground. That
> tag is layer=, well established:
> layer=-1 (for underground cable)
> layer=1 (for above-ground, the default)
layer=* is mainly designed for render engines. Furthermore it introduce a
classification. The trick here isn't to know which feature is under another
but to know where each feature is without any vertical relation between
According to wiki, location seems to best describe what we're looking for :
> And a single transmission line may span states, countries, mountains,
> tunnels, pylons... that can be tied together with a relation.
Yes, but it's the next step, which is still draft :
Refine power=* is a big need before doing anything with power lines and
> You can solve the stacking of equipment as:
That's what I call "dirty tricks" : power:transformer isn't introduced at
all, there's a weird relation between power & telephone with
We can create as many nodes as many power features we have to map and link
them with power=line ways. It's also dirty but closer to official operators
diagrams even it's not perfect.
Why can't we move pole & tower to man_made=* and only use power for
features which deserve it ?
There are many fields of knowledge which share a feature, but without any
collision between them.
As for size of facility: the practice on paper maps is to show "major"
> power lines. The type that show up on air photos and are landmarks to
> hikers. The boundary may be fuzzy, but at the extremes it is clear. A big
> visible thing wants to appear on most renderings, and minor things don't.
> You need to find a way to replicate that, in order to make for good maps.
That's a key point : I aim to propose a robust and consistent tagging model
to share reliable data about power networks. Not especially fancy maps.
Rendering is only a single use out of many more allowed by OSM system. I
don't know and can't even imagine what would other users do with the data I
add to the map.
The main part of data about power networks must be avoided by common
rendering to reduce map cluttering... Only aerial lines and towers should
Good night from France :)
francois dot lacombe At telecom-bretagne dot eu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging