<div dir="ltr">Here is a mail that can be useful to see in ML.<br><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">François Lacombe</b> <span dir="ltr"><<a href="mailto:francois.lacombe@telecom-bretagne.eu">francois.lacombe@telecom-bretagne.eu</a>></span><br>
Date: 2013/7/27<br>Subject: Re: [Tagging] Feature proposal - RFC - Power transmission refinement<br>To: Bryce Nesbitt <<a href="mailto:bryce2@obviously.com">bryce2@obviously.com</a>><br><br><br><div dir="ltr"><br><div class="gmail_extra">
<div class="gmail_quote"><div class="im">2013/7/27 Bryce Nesbitt <span dir="ltr"><<a href="mailto:bryce2@obviously.com" target="_blank">bryce2@obviously.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>On Fri, Jul 26, 2013 at 3:43 PM, François Lacombe <span dir="ltr"><<a href="mailto:francois.lacombe@telecom-bretagne.eu" target="_blank">francois.lacombe@telecom-bretagne.eu</a>></span> wrote:<br></div>
<div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br><div class="gmail_extra"><div class="gmail_quote">2013/7/26 Bryce Nesbitt <span dir="ltr"><<a href="mailto:bryce2@obviously.com" target="_blank">bryce2@obviously.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But you're changing the definition of an existing tag,<div>over the objections of existing mappers. You can do better.</div>
</blockquote></div><br></div></div>Ok. What's your suggestion about that ?</div></blockquote><div><br></div><div><br></div><div><br></div></div><div>The basic suggestion is for you to show some public concern for matching <i>existing</i> tagging practice and harmonize. <br>
</div></div></blockquote><div><br></div></div><div>Thus you think that the proposal here isn't harmonizing enough ?<br></div><div>Have a look to man_made=pipeline model to see how power and pipeline will be closer if this proposal is accepted.<br>
<br></div><div>location is used by pipeline... not by power.<br><br></div><div>Pipeline include water distribution. Those networks are maybe longer than power ones. Let's think about it.<br><br></div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div></div>
<div>-----------------</div><div>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.</div>
</div></blockquote><div><br></div></div><div>I'm convinced into rendering is more blocked by mapcss than by the tagging model.<br></div><div>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.<br>
</div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote">
<div>------------------</div><div>The location tag is not usually used for visible vs. underground. That tag is layer=, well established:</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px">
<div class="gmail_quote"><div>power=line</div></div><div class="gmail_quote"><div>layer=-1 (for underground cable)</div></div><div class="gmail_quote"><div><br></div></div><div class="gmail_quote"><div>power=line</div></div>
<div class="gmail_quote"><div>layer=1 (for above-ground, the default)</div></div></blockquote></blockquote><div><br></div></div><div>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 them.<br>
</div><div>According to wiki, location seems to best describe what we're looking for : <a href="http://wiki.openstreetmap.org/wiki/Key:location" target="_blank">http://wiki.openstreetmap.org/wiki/Key:location</a><br>
<br></div><div class="im"><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And a single transmission line may span states, countries, mountains, tunnels, pylons... that can be tied together with a relation.<br>
</blockquote><div><br></div></div><div>Yes, but it's the next step, which is still draft : <a href="http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal" target="_blank">http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal</a><br>
<br></div><div>Refine power=* is a big need before doing anything with power lines and circuits.<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div>You can solve the stacking of equipment as:</div><div>
<br>
</div></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div class="gmail_quote"><div>power=pole</div></div><div class="gmail_quote"><div>power:transformer=PGE</div></div><div class="gmail_quote">
<div>power:cellular=Verizon</div>
<div>power:telephone=ATT</div><div>power:fiber=<a href="http://sonic.net" target="_blank">sonic.net</a></div><div>ref=A1235</div><div>operator=PGE</div></div></blockquote></blockquote><div><br></div></div><div>That's what I call "dirty tricks" : power:transformer isn't introduced at all, there's a weird relation between power & telephone with power:telephone.<br>
<br></div><div>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.<br></div><div>
<br>
</div><div>Why can't we move pole & tower to man_made=* and only use power for features which deserve it ?<br><br></div><div>man_made=pole<br></div><div>power=transformer<br></div><div>operator=PGE<br></div><div>
operator:telephone=ATT<br>
</div><div>operator:cellular=Verizon<br></div><div>operator:power=PGE<br></div><div>fiber=<a href="http://sonic.net" target="_blank">sonic.net</a><br></div><div>ref:power=A1235<br></div><div>ref:cellular=B7896<br></div><div>
<br></div><div>
There are many fields of knowledge which share a feature, but without any collision between them.<br></div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div>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.</div>
</div></blockquote><div><br></div></div><div>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.<br></div><div>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.<br>
</div><div>The main part of data about power networks must be avoided by common rendering to reduce map cluttering... Only aerial lines and towers should be shown.<br></div><div> </div></div><br></div><div class="gmail_extra">
Good night from France :)<br><br></div><div class="im"><div class="gmail_extra"><br><b>François Lacombe</b><br><br>francois dot lacombe At telecom-bretagne dot eu<br><a href="http://www.infos-reseaux.com" target="_blank">http://www.infos-reseaux.com</a><br>
</div></div></div>
</div><br></div></div>