[Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)
fl.infosreseaux at gmail.com
Thu Jan 9 00:08:20 UTC 2020
This proposal is still in RFC and may be voted in a couple of weeks as
evaluation shown no issue so far, at least on transmission power lines.
line_management tag is used carefully for testing.
Read more : https://www.openstreetmap.org/user/InfosReseaux/diary/391058
Nevertheless it's an opportunity to review the branch:type tag replacement
i'm still looking for an appropriate illustration for two values examples:
* line_management=cross (two or more lines with different directions
sharing the same support without connecting)
* line_management=loop (two or more lines coming from the same direction
are connected as to mock some of them)
Feel free to propose and complete if you find corresponding situations on
Thanks in advance
Le sam. 26 oct. 2019 à 20:59, François Lacombe <fl.infosreseaux at gmail.com>
a écrit :
> Hi all,
> After the review of line_attachment key this summer and Karlsruhe
> hackweekend at Geofabrik headquarters last week, let me introduce the
> second stage of tower:type key cleaning project for power lines. Great time
> has been spent on discussing and finding relevant situations.
> It's now about the arrangement of power lines around their supports: how
> the lines branch, split, transpose or terminate.
> As current tagging (without line_management) still collides with any tower
> building function, the line_management key may be a solution to strip
> unrelated values from tower:type.
> I've published a diary entry to give more explanations
> I'd draw your attention to the conclusion :
> "Mapping utility supports like power towers or telecom poles is a
> worldwide challenge. For instance in France, professionals including
> operators and contractors rolling out overhead telecom cables are currently
> looking for approx. 16 millions missing shared power poles that weren’t
> mapped in operational GIS. There’s no doubt updating OSM can help."
> There's no short term risk of importing massive data, at least.
> This proposal is a first try and may cause worries about some local
> concerns. RFC is here to solve this prior to vote anything.
> We have to focus on simple situations to begin with to adopt the right
> semantic. More complex cases will be added step by step.
> Feel free to open a topic in Talk page.
> All the best
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging