Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[David Marchal via Tagging]

Jan,

I see you have done much work on this topic on your page 
(https://wiki.openstreetmap.org/wiki/User:Mueschel/DestinationTagging); why 
didn't you include these informations on the general Wiki pages instead of your 
user pages?

Regards.
--
Nouvelle adresse mail : penegal...@protonmail.com

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
Le samedi 1 août 2020 17:03, David Marchal  a écrit :

> To Jan Michel (I did not have your mail, as I unsubscribed of the list mails 
> to avoid cluttering my mailbox): the goal of my request is not to assist 
> routing software in finding a route, but to help navigation software to 
> display the destination signs as they are on the ground. If a destination is 
> restricted to some vehicles, for instance the ones below 12 tons, the 
> navigation software should have access to the restriction, to allow it to 
> display the restriction on the screen, or to not display the destination if 
> the routed vehicle is not concerned, i.e. if the routed vehicle is over 12 
> tons.
>
> I agree with the fee/toll part, I had the wrong tag in mind.
>
> Concerning weight, french tonnage signs indeed concern weight rating, not 
> actual weight, but, as maxweight is often used for such signs, I kept it for 
> my question.
>
> Concerning the documentation, I agree it is not well structured and could 
> largely be improved. In my case, the proposal is more a way to formalise the 
> reasoning and interpretation for the suggested tagging scheme. I am not 
> willing to publish a brand new tagging scheme as if I was documenting 
> something already well established. That would be confusing: it is something 
> new, currently used nowhere, and I feel the proposal process is there for 
> that: to allow suggestions to be discussed and approved, thus limiting 
> tagging and wiki disorganization.
>
> Regards.
> --
> Nouvelle adresse mail : penegal...@protonmail.com
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> Le vendredi 31 juillet 2020 15:53, David Marchal  
> a écrit :
>
>> Hello, there.
>>
>> I'm wondering, there are destination signs which only apply to some kind of 
>> vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 12t… 
>> How would I tag such destinations? The simple way would be to use, 
>> respectively, destination:hgv=*, destination:bicycle=*, destination:foot=*, 
>> destination:conditional="* @ weight<12". Am I right to assume these?
>>
>> If so, some examples:
>>
>> - in this example (https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), 
>> the road ahead would be tagged (regardless of direction), 
>> destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and 
>> destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare 
>> S.N.C.F.;Gare"
>> - in this example (https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), 
>> the link would be tagged 
>> destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel du Mᵗ Blanc"
>> - in this example (https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), 
>> the road exiting the turnaround would be tagged 
>> destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles" 
>> and 
>> destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
>>  sud;Zones industrielles) @ weight>3.5 AND hgv"
>> - in this example (https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), 
>> the road exiting the turnaround would be tagged destination="La Voivre", 
>> destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"
>>
>> Is that correct? Can I edit the Wiki destination tag page to give these 
>> informations, or maybe should I submit a RFC to formalize this?
>>
>> Awaiting your answers,
>>
>> Regards.
>> --
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[David Marchal via Tagging]

To Jan Michel (I did not have your mail, as I unsubscribed of the list mails to 
avoid cluttering my mailbox): the goal of my request is not to assist routing 
software in finding a route, but to help navigation software to display the 
destination signs as they are on the ground. If a destination is restricted to 
some vehicles, for instance the ones below 12 tons, the navigation software 
should have access to the restriction, to allow it to display the restriction 
on the screen, or to not display the destination if the routed vehicle is not 
concerned, i.e. if the routed vehicle is over 12 tons.

I agree with the fee/toll part, I had the wrong tag in mind.

Concerning weight, french tonnage signs indeed concern weight rating, not 
actual weight, but, as maxweight is often used for such signs, I kept it for my 
question.

Concerning the documentation, I agree it is not well structured and could 
largely be improved. In my case, the proposal is more a way to formalise the 
reasoning and interpretation for the suggested tagging scheme. I am not willing 
to publish a brand new tagging scheme as if I was documenting something already 
well established. That would be confusing: it is something new, currently used 
nowhere, and I feel the proposal process is there for that: to allow 
suggestions to be discussed and approved, thus limiting tagging and wiki 
disorganization.

Regards.
--
Nouvelle adresse mail : penegal...@protonmail.com

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
Le vendredi 31 juillet 2020 15:53, David Marchal  a 
écrit :

> Hello, there.
>
> I'm wondering, there are destination signs which only apply to some kind of 
> vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 12t… How 
> would I tag such destinations? The simple way would be to use, respectively, 
> destination:hgv=*, destination:bicycle=*, destination:foot=*, 
> destination:conditional="* @ weight<12". Am I right to assume these?
>
> If so, some examples:
>
> - in this example (https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), 
> the road ahead would be tagged (regardless of direction), 
> destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and 
> destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare 
> S.N.C.F.;Gare"
> - in this example (https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), 
> the link would be tagged destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel 
> du Mᵗ Blanc"
> - in this example (https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), 
> the road exiting the turnaround would be tagged 
> destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles" 
> and 
> destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
>  sud;Zones industrielles) @ weight>3.5 AND hgv"
> - in this example (https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), 
> the road exiting the turnaround would be tagged destination="La Voivre", 
> destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"
>
> Is that correct? Can I edit the Wiki destination tag page to give these 
> informations, or maybe should I submit a RFC to formalize this?
>
> Awaiting your answers,
>
> Regards.
> --
> Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[David Marchal via Tagging]

Hm, it seems a smart way to manage such cases; I could add the restrictions on 
the relation, like hazmat:water=no or maxweight=12. I assume that, in such 
cases, I must create a destination_sign relation for unrestricted destinations, 
and one for each destination restriction (if there are several restrictions, 
one relation for each restriction).

Is it widestream to have several destinations in one single relation, or is it 
necessary to add a relation per destination? Having one relation per 
destination would be a pain in the ass.

What about application support? Are destination_sign relations widely 
supported, or are they mostly ignored by software like Osmand?

I would like to add this possibility on the Wiki; do you think it would be 
necessary to fill a proposal, or could I just add it, as it is a simple, 
self-explaining, combination of preexisting tags?

Awaiting your answers,

Regards.
--
Nouvelle adresse mail : penegal...@protonmail.com

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
Le samedi 1 août 2020 11:12, Andrew Harvey  a écrit :

> While you're talking about the destination tag, I think when using a 
> destination_sign relation it's best to apply the mode as eg. 
> bicycle=designated, eg 
> https://www.openstreetmap.org/relation/11345354#map=18/-33.82573/151.21308 
> for https://www.mapillary.com/map/im/VIq-OPTiw0BVI7gqdLR-iA
>
> On Fri, 31 Jul 2020 at 23:55, David Marchal via Tagging 
>  wrote:
>
>> Hello, there.
>>
>> I'm wondering, there are destination signs which only apply to some kind of 
>> vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 12t… 
>> How would I tag such destinations? The simple way would be to use, 
>> respectively, destination:hgv=*, destination:bicycle=*, destination:foot=*, 
>> destination:conditional="* @ weight<12". Am I right to assume these?
>>
>> If so, some examples:
>>
>> - in this example (https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), 
>> the road ahead would be tagged (regardless of direction), 
>> destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and 
>> destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare 
>> S.N.C.F.;Gare"
>> - in this example (https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), 
>> the link would be tagged 
>> destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel du Mᵗ Blanc"
>> - in this example (https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), 
>> the road exiting the turnaround would be tagged 
>> destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles" 
>> and 
>> destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
>>  sud;Zones industrielles) @ weight>3.5 AND hgv"
>> - in this example (https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), 
>> the road exiting the turnaround would be tagged destination="La Voivre", 
>> destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"
>>
>> Is that correct? Can I edit the Wiki destination tag page to give these 
>> informations, or maybe should I submit a RFC to formalize this?
>>
>> Awaiting your answers,
>>
>> Regards.
>> --
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[David Marchal via Tagging]

No, such restrictions are typically not applied directly on the road indicated 
by the sign; they are present on other road segments along the indicated route, 
or may not be present at all, because the road network manager wants to 
encourage some kinds of vehicles to use a specific route, without explicitly 
forbidding them on the other roads.

--
Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
Le vendredi 31 juillet 2020 15:59, Paul Johnson  a écrit :

> On Fri, Jul 31, 2020 at 8:53 AM David Marchal via Tagging 
>  wrote:
>
>> Hello, there.
>>
>> I'm wondering, there are destination signs which only apply to some kind of 
>> vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 12t… 
>> How would I tag such destinations? The simple way would be to use, 
>> respectively, destination:hgv=*, destination:bicycle=*, destination:foot=*, 
>> destination:conditional="* @ weight<12". Am I right to assume these?
>
> access=destination, bicycle=destination, foot=destination, 
> access:conditional=destination @ weight<12___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[David Marchal via Tagging]

Hello, there.

I'm wondering, there are destination signs which only apply to some kind of 
vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 12t… How 
would I tag such destinations? The simple way would be to use, respectively, 
destination:hgv=*, destination:bicycle=*, destination:foot=*, 
destination:conditional="* @ weight<12". Am I right to assume these?

If so, some examples:

- in this example (https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), 
the road ahead would be tagged (regardless of direction), 
destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and 
destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare 
S.N.C.F.;Gare"
- in this example (https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), 
the link would be tagged destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel 
du Mᵗ Blanc"
- in this example (https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), 
the road exiting the turnaround would be tagged 
destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles" and 
destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
 sud;Zones industrielles) @ weight>3.5 AND hgv"
- in this example (https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), 
the road exiting the turnaround would be tagged destination="La Voivre", 
destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"

Is that correct? Can I edit the Wiki destination tag page to give these 
informations, or maybe should I submit a RFC to formalize this?

Awaiting your answers,

Regards.
--
Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging forest parcels

[David Marchal]

Mateusz,

The first thing is that this tagging scheme is mainly used in Poland, so that 
sounded like a local, not widely approved, tagging scheme.

The second thing, which is the real problem to me, is that I don't see how to 
link these with the forest, as a parcel number is valid only in a given forest. 
With a relation? What kind?

Awaiting your answer,

Regards.


De : Mateusz Konieczny 
Envoyé : mercredi 9 octobre 2019 21:29
À : Tag discussion, strategy and related tools 
Objet : Re: [Tagging] Tagging forest parcels

boundary=forest_compartment?

Is there anything wrong with this tagging
scheme (except that mapping this
kind of info seems a bit dubious to me).

All problems that you mention are
about tagging for renderer.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging forest parcels

[David Marchal]

There may be a misunderstanding here: what I mean about forest parcels is a 
piece of forest which is numbered and whose number is displayed on site, with a 
plate or a painted text. Such data can be useful for orientation in a forest 
and, until some years ago, these numbers were displayed on maps, at least in 
France.

Regards.

> Le 10 oct. 2019 à 10:11, Martin Koppenhoefer  a écrit 
> :
> 
> I agree the parcels should not get the same tag as the trees, because not all 
> parcels will be covered 100% by trees. I would not use the "landuse"-tag for 
> these. Maybe "boundary" could be an acceptable key. (there are for example 
> around 175 boundary=parcel according to taginfo). 
> 
> Generally, we are not mapping parcels as such at all, neither in built-up 
> areas nor in natural areas. There seems to be a consensus against it 
> (personally, I have different priorities for now, but I would not stop others 
> from mapping parcel boundaries if they can be verified) and in the past, the 
> parcels/propery boundaries that had been imported in the past (somewhere in 
> the US, AFAIR from PD data) have been removed afterwards, I think by the Data 
> Working Group. Questions of verifiability have been raised. In my area, many 
> parcel boundaries (at least effective parcel boundaries) can be surveyed, 
> there are fences, hedges, walls and buildings. For forest parcel boundaries. 
> I could imagine it would be more difficult, or are these fenced off? 
> 
> In some areas I have seen there are place=locality nodes in the forest to 
> store the names of small areas, and while these are not really comparable to 
> parcel boundaries, they may be an alternative method if you are mostly 
> interested in names.
> 
> Cheers
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging forest parcels

[David Marchal]

Hello, there.

My question is simple: how do we tag such things? The 
boundary=forest_compartment relation is not rendered, and what is rendered is 
tagging as landuse=forest both the forest and its parcels, which leads to 
rendering it twice, as you can see here: 
https://www.openstreetmap.org/relation/6086515 Besides, such forest are often 
mistagged for the renderer: as the contributor wants the parcel number 
rendered, he puts it in the name tag, not in the ref tag, to which I assume it 
should belong.

So, is there an "official"/recommended/widespread way to tag forest parcels, 
their number and them belonging to a forest?

Awaiting your answers,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Multipolygon (several outers) forest with different leaf_types: mapping strategy?

[David Marchal]

Hello, there.

I mapped a forest made of several pieces of woodland, some contiguous and some 
isolated, with differents leaf_types. I mapped this 
(https://www.openstreetmap.org/relation/9393253) with a landuse=forest 
multipolygon, with common tags such as name and operator on the relation, and 
with leaf_type tags on the outer members, as each has a different value. It 
seemed a good way to model the fact that these woodlands were considered part 
of the same forest but had differents leaf_types, but I am unsure now: the JOSM 
validator claims that contiguous outer members is an error, and 
openstreetmap.org renders a misplaced name and no leaf_type. Is it a modelling 
failure or a renderer and validator error? In the first case, how should I map 
this?

Awaiting your answers,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[David Marchal]

Paul,

Your landuse=forestry proposal seems good to me: it is clear enough, and the 
transition process you describe here seems consistent with what I know about 
such transitions which already happened. If I understand you, the main problem 
for landuse=forestry is to include it in the standard style to not discourage 
its use, but style devs rejected adding its rendering before its use spread a 
bit. Some sort of vicious circle, in fact?

Awaiting your answer,

Regards.

> Le 21 janv. 2019 à 21:44, Paul Allen  a écrit :
> 
> Ideally, if we get landuse=forestry and it eventually renders, landuse=forest 
> would be
> deprecated and slowly replaced when a mapper encounters it.  It's a 
> misbegotten tag
> that has been used inconsistently.  It was intended to mean what the suggested
> landuse=forestry means, but has largely been used to mean what natural=wood 
> means.
> 
> landuse=forest is wrong two ways.  A forest is not landuse.  You might be 
> able to justify
> landcover=forest but that's already dealt with by landcover=trees.  You might 
> be able to
> make an argument for natural=forest (a big wood) in the same way we draw a 
> distinction between rivers and streams.  The only way it can be considered 
> landuse is
> if the land is used for forestry, but then we have the mismatch with natural 
> English which
> is part of the reason it was misused and part of the reason people keep 
> proposing
> landuse=forestry.
> 
> Any migration would have to be on a case-by-case basis.  If land used for 
> forestry is
> tagged as landuse=forest it should (eventually) be migrated to 
> landuse=forestry.
> If not used for forestry then landcover=trees or natural=wood.
> 
> But all that requires that this list and the carto people manage to get all 
> our shit in the
> same sock.
> 
> Maybe it's worth a formal proposal for landuse=forestry suggesting 
> dual-tagging as
> an interim workaround for it not being rendered, with a later clean-up.  
> Because we're
> going to keep coming back to this one until we finally do something about it.
> 
> -- 
> Paul
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

[David Marchal]

Hello, there.

All is in the title: when hiking in a forest (I mean, an area considered as a 
forest by authorities), I often encounter other landcovers, like scrubs in 
recently teared down parcels, or scree in the mountains. These area, although, 
clearly and morphologically, not a forest, are still mapped as such, as they 
are considered to be part of the forest and are treated this may, but they are 
morphologically not the forest: the forest is the area administratively 
regarded as such, but it is not always the case; if I want, for instance, to 
map them as a scrub area of the forest, as the polygons overlapped, they are 
rendered in a mixed way. Is there a recommended way of handling such cases 
without broking display? If so, what are they? The landcover tag? 
boundary=forest_compartment? Another?

Awaiting your answers,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Highways going through military camp: access=private or access=military?

[David Marchal]

Hello, there.


All is in the title: when access to a road is restricted to military, as it is 
running through a base, should I tag it access=private or access=military? The 
first gives the right restriction, but the second is more precise, although not 
documented (about 1.8k uses according to taginfo).


Awaiting your answers,


Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=motorway_junction : what about primary, secondary or tertiary ways?

[David Marchal]

Ok, thanks for your answer. That would help routing planners to use the correct 
"Take exit to…" sentence instead of "Turn right to…", which is a nonsense for 
an exit.


Regards.


De : Philip Barnes 
Envoyé : jeudi 12 juillet 2018 09:11
À : Tag discussion, strategy and related tools
Objet : Re: [Tagging] highway=motorway_junction : what about primary, secondary 
or tertiary ways?

It is commonly used on non-motorway grade separated junctions. So the answer is 
yes.

Phil (trigpoint)

On 12 July 2018 07:34:06 BST, David Marchal  wrote:

Hello, there.


Is highway=motorway_junction also applicable to non-motorway roads? There are 
primary, secondary… roads where there are exits, but can these be tagged with 
this one?


Awaiting your answers,


Regards.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] highway=motorway_junction : what about primary, secondary or tertiary ways?

[David Marchal]

Hello, there.


Is highway=motorway_junction also applicable to non-motorway roads? There are 
primary, secondary… roads where there are exits, but can these be tagged with 
this one?


Awaiting your answers,


Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Route members: ordered or not

[David Marchal]

Hello, there.


I recently worked a bit on hiking routes, and noticed that some routes have 
unordered members. That's particularly noticeable on waymarkedtrails.org, as it 
makes the elevation graph rubbish and useless. I read the relation:route wiki 
page, but there is only advice regarding stops order, and not way members 
order. Shouldn't there be a note on this page regarding the importance of 
sorting the ways to have a more useful relation than only spaghettis?


By the way, I saw some hiking relations having a node without explicit role, 
seemingly as a start point; is it a generally accepted, used feature, or only 
an idiosyncrasy?


Awaiting your answers,


Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] landuse=forest + ref=* : parcel number or what?

[David Marchal]

Hello, there.


I hope this will not start a flamewar: I noticed that, despite being widely 
used, ref=* is not rendered for landuse=forest. I assumed this was used for 
parcel (compartment) numbers, as this tag seems to fit the definition of a 
parcel number; nevertheless, I saw on a Github issue of the main style that 
this usage of ref=* on landuse=forest was unproven and that it ref=* not be 
assumed to contain the parcel number. Besides, it seems that the wiki doesn't 
document this use of ref=*. Making some use of Overpass turbo seems to indicate 
that ref=* is indeed used for parcel numbers; there is also 
boundary=forest_compartment relations, but they seem to be far less used, and 
mainly in Russia. I would like to document this specific use of ref=*, but, 
before, are there use cases where ref=* is used with landuse=forest for 
something, or are such uses errors, or marginal enough to ignore them?


Awaiting your answers,


Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Sinkholes refinement

[David Marchal]

Hi, Yuri.

Though I understand your request and find it relevant, I’m unsure about 
altering a proposal page after the vote had started; AFAIK, I’m supposed to let 
it as is, apart from the vote section. Could you show me if my assumption is 
wrong, or can someone on the ML confirm or infirm that?

Awaiting your answers,

Regards.

Le 12 nov. 2017 à 21:17, Yuri Astrakhan 
<yuriastrak...@gmail.com<mailto:yuriastrak...@gmail.com>> a écrit :

David, hi, just an thought - could you combine the rationale and examples 
sections?  The way you have it now is first you describe each concept, and 
afterwards you have the same concept but with a picture.  I think it would be 
better to list each variant with the picture right away.

Thanks!

On Sun, Nov 12, 2017 at 8:30 AM David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> wrote:
Hello, there.

Almost 3 weeks passed and only 3 people told that they preferred karst=yes 
instead of karstic=yes. As the first one was also the one stated as the 
proposal, and the second one was only mentioned in erroneous examples, I assume 
this relative unanimity is enough to confirm karst=yes as the one to use, and 
will create the wiki page accordingly. Thanks to all who voted; the proposal 
process is now fully finished, apart from creating all the Wiki pages.

Regards.


Le 24 oct. 2017 à 19:16, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Hello, there.

The vote period passed, and the proposal received a total of 16 approvals, 1 
spoilt vote and 0 refusals, so I closed the vote and marked the proposal as 
approved. Thanks to all the voters; I’ll create the according Wiki pages and 
edit existing ones to reflect the vote on the following days.

As a side note, there is a secondary vote on the proposal page; indeed, some 
voters noticed an inconsistency in the proposal, ie. a proposal example carried 
karstic=yes tagging instead of the proposed karst=yes. To make sure of what 
version the voters approved, I have to ask them to go back on the proposal page 
and vote, in the dedicated subsection, amongst karstic=yes or karst=yes. Once 
the choice will have been asserted, I’ll be able to create the corresponding 
Wiki page.

Thanking you for your patience, and awaiting your votes,

Regards.

Le 8 oct. 2017 à 09:51, David Marchal <pene...@live.fr<mailto:pene...@live.fr>> 
a écrit :

Hello, there.

The normal voting duration passed, but there are not enough votes yet to 
approve or reject the proposal, so I extend the voting period by two weeks to 
allow latecomers to vote.

Awaiting your votes,

Reagrds.

Le 26 sept. 2017 à 20:26, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Hello, there.

As this proposal has been RFCed more than 2 weeks ago, and that comments have 
been addressed, I’m now putting it on vote. Please go on the proposal page 
(https://wiki.openstreetmap.org/wiki/Proposed_features/Sinkholes_refinement) to 
vote.

Awaiting your votes,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Sinkholes refinement

[David Marchal]

Hello, there.

Almost 3 weeks passed and only 3 people told that they preferred karst=yes 
instead of karstic=yes. As the first one was also the one stated as the 
proposal, and the second one was only mentioned in erroneous examples, I assume 
this relative unanimity is enough to confirm karst=yes as the one to use, and 
will create the wiki page accordingly. Thanks to all who voted; the proposal 
process is now fully finished, apart from creating all the Wiki pages.

Regards.

Le 24 oct. 2017 à 19:16, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Hello, there.

The vote period passed, and the proposal received a total of 16 approvals, 1 
spoilt vote and 0 refusals, so I closed the vote and marked the proposal as 
approved. Thanks to all the voters; I’ll create the according Wiki pages and 
edit existing ones to reflect the vote on the following days.

As a side note, there is a secondary vote on the proposal page; indeed, some 
voters noticed an inconsistency in the proposal, ie. a proposal example carried 
karstic=yes tagging instead of the proposed karst=yes. To make sure of what 
version the voters approved, I have to ask them to go back on the proposal page 
and vote, in the dedicated subsection, amongst karstic=yes or karst=yes. Once 
the choice will have been asserted, I’ll be able to create the corresponding 
Wiki page.

Thanking you for your patience, and awaiting your votes,

Regards.

Le 8 oct. 2017 à 09:51, David Marchal <pene...@live.fr<mailto:pene...@live.fr>> 
a écrit :

Hello, there.

The normal voting duration passed, but there are not enough votes yet to 
approve or reject the proposal, so I extend the voting period by two weeks to 
allow latecomers to vote.

Awaiting your votes,

Reagrds.

Le 26 sept. 2017 à 20:26, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Hello, there.

As this proposal has been RFCed more than 2 weeks ago, and that comments have 
been addressed, I’m now putting it on vote. Please go on the proposal page 
(https://wiki.openstreetmap.org/wiki/Proposed_features/Sinkholes_refinement) to 
vote.

Awaiting your votes,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Sinkholes refinement

[David Marchal]

Hello, there.

The vote period passed, and the proposal received a total of 16 approvals, 1 
spoilt vote and 0 refusals, so I closed the vote and marked the proposal as 
approved. Thanks to all the voters; I’ll create the according Wiki pages and 
edit existing ones to reflect the vote on the following days.

As a side note, there is a secondary vote on the proposal page; indeed, some 
voters noticed an inconsistency in the proposal, ie. a proposal example carried 
karstic=yes tagging instead of the proposed karst=yes. To make sure of what 
version the voters approved, I have to ask them to go back on the proposal page 
and vote, in the dedicated subsection, amongst karstic=yes or karst=yes. Once 
the choice will have been asserted, I’ll be able to create the corresponding 
Wiki page.

Thanking you for your patience, and awaiting your votes,

Regards.

Le 8 oct. 2017 à 09:51, David Marchal <pene...@live.fr<mailto:pene...@live.fr>> 
a écrit :

Hello, there.

The normal voting duration passed, but there are not enough votes yet to 
approve or reject the proposal, so I extend the voting period by two weeks to 
allow latecomers to vote.

Awaiting your votes,

Reagrds.

Le 26 sept. 2017 à 20:26, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Hello, there.

As this proposal has been RFCed more than 2 weeks ago, and that comments have 
been addressed, I’m now putting it on vote. Please go on the proposal page 
(https://wiki.openstreetmap.org/wiki/Proposed_features/Sinkholes_refinement) to 
vote.

Awaiting your votes,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Part of forest which is in a scrub state: inside or outside multipolygon?

[David Marchal]

It’s a re-forestation area, but the trees have all been teared down, so it’s 
now scrub, but temporarily.

> Le 12 oct. 2017 à 11:20, Volker Schmidt  a écrit :
> 
> Is it (permanently) scrub or is it re-forestation area that is temporarily 
> without trees?
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Part of forest which is in a scrub state: inside or outside multipolygon?

[David Marchal]

Hello, there.

If a part of a forest has been razed and is now a scrub area, should I let this 
natural=scrub area in the forest multipolygon? I thought so, as the scrub area 
is still managed as a section of the whole forest, but another user updated it 
to exclude the scrub areas from the forest multipolygon, so I would like to 
know which version was correct.

Awaiting your answers,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - Sinkholes refinement

[David Marchal]

Hello, there.

As this proposal has been RFCed more than 2 weeks ago, and that comments have 
been addressed, I’m now putting it on vote. Please go on the proposal page 
(https://wiki.openstreetmap.org/wiki/Proposed_features/Sinkholes_refinement) to 
vote.

Awaiting your votes,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Geological Faults

[David Marchal]

Hello.

A naive tagging would be natural=fault on a way drawn along the fault, but it’s 
very naive, as I never mapped anything related.

Regards.

Le 11 sept. 2017 à 04:29, J.J.Iglesias 
> a écrit :

I am unable to find how to tag geological Faults.

Any Idea?

Thanks

JJ
@ Bolivia



[Logotipo de AVG]

Este correo electrónico ha sido comprobado en busca de virus con el software 
antivirus AVG.
www.avg.com



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Sinkholes refinement

[David Marchal]

Hello, there.

RicoZ has drawn my attention on the fact that my proposal introduced new keys 
which are not meant to be specific to sinkholes, and that it could be better to 
mention them here, so here are the new tags which are not sinkhole-specific:

  *   anthropogenic=yes, to model the fact that a feature tagged as natural=* 
is anthropogenic; in the proposal, it is introduced to explain piping 
pseudokarsts, or mining sinkholes, but it can be used for any natural=* feature 
which appeared because of human activities, for example natural=peak on spoil 
tips;
  *   karst=yes, to model the fact that the water of a spring originates from a 
karst system, i.e. it’s a karst spring; this tag could also be used on anything 
of karstic origin, like caves or tunnels;
  *   refitted=yes, to model the fact that karstic features have been altered 
by humans, for instance by refitting the hole with concrete or metal bars; this 
tag could also be used on any natural feature which has been altered by humans, 
for instance spring coming through a pipe or captured for human consumption;
  *   flow_direction=both, to model water streams connected to estavelles, 
which is a karst feature acting as spring or ponor depending on the current 
conditions, as these streams can have their flow reversed if the estavelle 
starts acting the opposite to usual; I remember this tag has already been used 
a few times in OSM.

I created the 3 first tags as, despite my research, I wasn’t able to find an 
already used fitted tag, but, if there are some, feel free to give them on the 
Talk page. Regarding flow_direction=both, it was mentioned on a Tagging ML talk 
months ago, but, if there is some better fitted tag, again, please give it on 
the Talk page.

Awaiting you comments,

Regards.

Le 9 sept. 2017 à 17:25, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Hello, there.

I’ve created a proposal for better tagging of sinkholes, as they can be of 
multiple types, not currently acknowledged by mainstream tagging practices. 
This proposal can be read here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Sinkholes_refinement Any 
comments should be left on its talk page.

Awaiting your comments,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Sinkholes refinement

[David Marchal]

Hello, there.

I’ve created a proposal for better tagging of sinkholes, as they can be of 
multiple types, not currently acknowledged by mainstream tagging practices. 
This proposal can be read here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Sinkholes_refinement Any 
comments should be left on its talk page.

Awaiting your comments,

Regards.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discouraging frequency=* on power lines and cables

[David Marchal]

> Le 8 mars 2017 à 23:04, Michael Reichert  a écrit :
> 
> Please keep OSM simple. I don't want to add a power route relation on
> every tiny minor distribution line/cable (230 V).
> 
Totally agree with that. I don’t understand the usage of a relation binding the 
distribution network elements: the connections between them can be retrieved 
from the nodes and ways, and the relation would merely be use for group 
tagging. IMHO, the relation would only make sense for transport lines, which 
are often viewed and treated as continuous, even if their characteristics 
change along their path (overhead, underground…). At a distribution level, 
however, this sounds overkill to me.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag beginning of a river

[David Marchal]

> Le 25 févr. 2017 à 12:16, Dave F  a écrit :
> 
> Hi Dave
> 
> Won't the first node of the named way that's most upstream indicate its start 
> point by default?
> 
> What advantages will adding a specific 'it starts here' tag bring?
> 
> Cheers
> DaveF
I agree with Dave here: the first node in the waterway can be retrieved by 
parsing the relation:waterway, so using a tag to highlight something the data 
already contains sound redundant to me, and of a limited use; it will merely 
ease its retrieval, while not adding anything to the data.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Use of oneway=yes on waterways

[David Marchal]

Note that, although exceptional, some waterways can flow both ways, according 
to tidal, floods, if a connected estavelle is absorbing or discharging water... 
Even if it is unlikely, this tag could be of some use to highlight the fact 
that the waterway is not subject to such stream variations.

From: letopographe...@gmail.com
To: tagging@openstreetmap.org
Date: Sat, 17 Sep 2016 14:06:23 +0200
Subject: [Tagging] Use of oneway=yes on waterways


  


  
  
Hi

According to the waterway=stream wiki page
  (http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dstream):


  If a flow exists, the direction of the way must be
  downstream (i.e. the way direction follows the flow)


As of today there is a very small percentage of streams (17593
  ways according to taginfo, 0.23%) with oneway=yes.

Is there any undocumented purpose? Is it ok and safe to delete
  oneway=yes tags for streams?



The same question can apply to drains, ditches, canals...

Yours,





-- 
LeTopographeFou
  


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Help required on tagging a "wadi"

[David Marchal]

I would add that, according to the wiki 
(https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwadi), waterway=wadi has 
been deprecated and should be replaced with waterway=stream or waterway=river, 
anyway with intermittent=yes. Apart from that, I agree with 61sundowner: the 
track and the waterway should be mapped separately, each with their own path.

From: 61sundow...@gmail.com
To: tagging@openstreetmap.org
Date: Mon, 5 Sep 2016 08:24:36 +1000
Subject: Re: [Tagging] Help required on tagging a "wadi"


  

  
  
On 9/5/2016 4:34 AM, Greg Wickham
  wrote:



  
  

  
  In Saudi Arabia a wadi is a mostly dry riverbed that
carries water very infrequently (maybe a couple of times year).
  

  
  Within most sandy bottomed wadi’s is at least one
track (typically 4wd).
  

  
  The exact location of the track within the wadi will
change due to occasional flooding events.
  

  
  I’ve read the discussion summary at 
http://wiki.openstreetmap.org/wiki/Talk:Tag:waterway%3Dwadi but
  I’m still not clear exactly how to tag this feature?
  

  
  It seems:
  

  
-
waterway=wadi
-
intermittent=yes
  

  
  is ok.
  

  
  But how to indicate can be vehicle track?
  

  
  Is it ok to mark a track in the “rough” vicinity
(i.e.: the track path will change between flooding events)?
  

  
  Should the wadi “line” be marked in the centre
between the edges?
  

  
  Would these tags be ok for a: “sandy bottomed wadi;
4wd only"
  

  
waterway
= wadi
intermittent
= yes
highway
= track
tracktype
= grade4
4wd_only
= yes
surface
= unpaved
  

  
  Suggestions welcome.
  

  


  



In an ideal world;

the wadi would be a way along the lowest path - where water would
first flow.

the track would be a separate way 



For less work a mapper would combine these into one way ... that
makes rendering harder. 









  


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roads with no speed limits

[David Marchal]

AFAIK, no maxspeed value means that the default maximum speed for this type of 
road in this area applies, so I wouldn't add this tag when there is no sign; 
that would also fulfill the "Map what's on the ground" principle. Beware that, 
if there that was a maximum speed sign (hundreds of) kilometers before, which 
is still in effect, you should then use this value; that kind of situation is 
pretty common, at least here in France, as it prevents installation of 
redundant signs after each junction.

From: hans.dekryge...@gmail.com
Date: Sun, 28 Aug 2016 12:35:48 -0700
To: tagging@openstreetmap.org
Subject: [Tagging] Roads with no speed limits

Here in Phoenix Arizona more than half the freeway off ramps have no listed 
speed limit. Does (maxspeed=none) work? I've worked hard here in the valley 
adding speed limits and when you look at the ito map it looks like no one added 
any to the off ramps when in fact most of them have been surveyed and they have 
none. How to tag them?
Regards,

Hans

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Does disused:railway=* require railway=disused?

[David Marchal]

Hello, there.

I've been told in a JOSM ticket 
(https://josm.openstreetmap.de/ticket/12866#comment:2) that the wiki states 
that disused:railway=* requires railway=disused, and, indeed, the wiki says 
that (https://wiki.openstreetmap.org/wiki/Key:disused:railway). I don't 
understand why as, AFAIK, the lifecycle prefixing doesn't requires this, as it 
merely intends to suppress the(highway|railway|*)=disused tagging. Requiring to 
keep this deprecated and redundant data sounds inconsistent and confusing to 
me, especially if this requirement is limited to railways. How do things stand 
regarding this matter?

Awaiting your answers,

Regards.  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging natural or historic regions

[David Marchal]

Hello, there.
At least here, in France, there are numerous regions, whose unity is based 
either on a common historical background, for example as a medieval county or 
duchy like the Barrois, or on a uniform natural landscape, as the Bauges 
mountains or the Mont Blanc massif. These regions are often called "pays" in 
French, but it should not be understood as a nation, and the regions I'm 
talking about do not always have an administrative representations, being often 
known only as a traditionally-named area.
Whatever, how to map such regions? I asked on a French forum, but it seems that 
the issue has not really been addressed, at least not from our point of view, 
but there may be an existing tagging scheme for that, as I see no reason for 
this issue being culturally restricted to our country. I assume that, as there 
areas do not always have clearly defined borders, they should be tagged as a 
single node, but, still, how to map them?
Awaiting your answers,
Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] How to tag a natural, man-organised feature?

[David Marchal]

Hello, there.
I'm wondering: there are tons of natural features that have been modified or 
organized by humans, like springs which emerge in man-made ponds. Is there a 
tag used to model this organization, like organised=yes?
Awaiting your answers,
Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Guides to improve navigation data in OpenStreetMap

[David Marchal]

Hello, Abhishek.
Nice idea to synthesize all the available stuff regarding navigation data. Not 
my main interest in OSM, as I've got enough work on my rural, mainly filled by 
bots area, but still a good idea. Keep it up!
Regards.

Date: Thu, 10 Mar 2016 15:33:45 +0530
From: saikia.abhi...@gmail.com
To: t...@openstreetmap.org
Subject: [OSM-talk] Guides to improve navigation data in OpenStreetMap

Hello everyone,
As a part of a recent push to improve OpenStreetMap navigation data, our team 
at Mapbox started collaborating documentation to create a comprehensive wiki on 
" Guides to improve navigation data in OpenStreetMap". This mapping guide is 
still not complete and the team intends to keep on adding new features to the 
guide  and make it more comprehensive so that it can be a reference to anyone 
who wants to contribute navigation data on OpenStreetMap. It will be helpful 
and great if the community can go through the guide and give their valuable 
feedback.

Regards,
Abhishek

___
talk mailing list
t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk   
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] tributary role in waterway relations: widespread?

[David Marchal]

Hello, there.

I wondered: I saw the' tributary' role on some waterway relations; while I 
understand its usage — to represent the fact that a waterway flows into another 
—, I would like to know if it is widespread or even widely accepted, if not 
voted on wiki, as JOSM complains about not knowing it every time I use it.

Awaiting your answers,

Regards.  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging problem for a river running in a culvert below a track / wiki votes enforcement

[David Marchal]

> Date: Mon, 25 Jan 2016 18:26:55 +0100
> From: matkoni...@gmail.com
> To: pene...@live.fr
> CC: tagging@openstreetmap.org
> Subject: Re: [Tagging] Tagging problem for a river running in a culvert below 
> a track / wiki votes enforcement
> 
> I think that photo of this object would be useful to decide how it
> should be tagged.

Indeed; here comes the picture: http://1drv.ms/1ZQJCxT

Hendrikklaas told me by a private message "Simple tagging is 
tunnel=culvert-bridge and add layer=-1 to avoid crossing conflicts. Or leave it 
just tunnel=building_passage like you already did just like any other road 
crossing a building but remember to add layers." Should I consider this as a 
building?

Thank you in advance for your help.

Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging problem for a river running in a culvert below a track / wiki votes enforcement

[David Marchal]

> Date: Mon, 25 Jan 2016 12:06:22 +0100
> From: dieterdre...@gmail.com
> can you please post a link to the object you think is rendered wrong, not to 
> the part of the map, e.g. like this: 
> https://www.openstreetmap.org/way/350320686
> This is a track, it should likely get a layer tag and a bridge attribute on 
> the part that runs over the river?
> If this is the culvert: https://www.openstreetmap.org/way/343507824 it should 
> be split at the border of the river and the culvert tag removed from the part 
> that isn't in a culvert.

No, I'm aware of the problem for way 343507824, I just didn't correct it yet. 
The problem is for https://www.openstreetmap.org/way/355739433 : it isn't a 
bridge, it's basically a parallelepipedic concrete block with culverts below to 
allow water to pass, and on which one drives. If this is in the borders of what 
is modelled as bridges on OSM, then I'll model it that way, but I don't think 
it's a good modelling.

Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging problem for a river running in a culvert below a track / wiki votes enforcement

[David Marchal]

Hello, there.
I've got a tagging problem here: 
https://www.openstreetmap.org/#map=19/48.34992/6.15965 A side stream of the 
Madon river runs in a culvert under the private track, and that makes a glitch 
by rendering the culvert over the `natural=water/water=river` polygon. I asked 
on the rendering config repo — 
https://github.com/gravitystorm/openstreetmap-carto/issues/2027 —, believing it 
to be a rendering bug, but been told that it's a tagging problem. I assume I 
shouldn't tag a single water polygon under the track, but there is nothing else 
to be tagged here than the track, merely a concrete block upon a culvert, the 
river under it, and the riverbed around that, so why is my tagging wrong? How 
should I correct that?
Besides, on the GitHub issue last comment, I've been told that Wiki tagging 
votes are only advisory and that the community is only invited, not required 
nor suggested, to follow them. As I understand this comment, the community MAY 
follow the Wiki tagging votes, it does not SHOULD nor MUST follow them. I was 
under the impression that the community at least SHOULD apply the votes 
results. Am I wrong on that?
Awaiting your answers,
Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[David Marchal]

Damn Hotmail!


> From: chris_horm...@gmx.de
> To: tagging@openstreetmap.org
> Date: Sat, 23 Jan 2016 22:37:07 +0100
> Subject: Re: [Tagging] wetland=bog, why only "receive their water and 
> nutrients from rainfall"?
>
> On Saturday 23 January 2016, David Marchal wrote:
> >
> > I tagged some bogs today, and I wondered: why does the wiki restricts
> > bogs to "depressions that receive their water and nutrients from
> > rainfall"? AFAIK, bogs are not necessarily isolated from water
> > streams or bodies. Wikipedia talls about sloping bogs where running
> > water is intercepted in the soil by plants;
>
> There are of course all kind of boundary cases but the typical bog as
> common in many parts of northern Europe is rain fed. In German we have
> the more specific term 'Regenmoor' which indicates this. Mires fed by
> groundwater or water inflow from the outside are usually not bogs.
> See:
>
> https://en.wikipedia.org/wiki/Mire

Ah, that can explain the difference in my interpretation: in French, bogs and 
fens are usually designated with the same word, "tourbière", which designates 
mires; this word is usually translated in English with "bog". To designate 
fens, we say "tourbière minérotrophe", but essentialy only specialists will 
know about this difference, most people will use "tourbière" for both fens and 
bogs. And now, I see my error: fens are modelled with a different "wetland=*" 
tagging, but, my language using essentially the same word for both, I stopped 
at the first occurence on the wiki page designating a mire, "wetland=bog", 
without understanding that the next one, "wetland=fen", designated exactly what 
I was looking for. The problem is the French translation of this page on the 
wiki, I'll correct it. Thanks for your answer.  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[David Marchal]

Re-sent message, the first one being misformatted.

> From: chris_horm...@gmx.de
> To: tagging@openstreetmap.org
> Date: Sat, 23 Jan 2016 22:37:07 +0100
> Subject: Re: [Tagging] wetland=bog,   why only "receive their water and 
> nutrients from rainfall"?
> 
> On Saturday 23 January 2016, David Marchal wrote:
>>
>> I tagged some bogs today, and I wondered: why does the wiki restricts
>> bogs to "depressions that receive their water and nutrients from
>> rainfall"? AFAIK, bogs are not necessarily isolated from water
>> streams or bodies. Wikipedia talls about sloping bogs where running
>> water is intercepted in the soil by plants; 

Ah, that can explain the difference in my interpretation: in French, bogs and 
fens are usually designated with the same word, "tourbière", which designates 
mires; this word is usually translated in English with "bog". To designate 
fens, we say "tourbière minérotrophe", but essentialy only specialists will 
know about this difference, most people will use "tourbière" for both fens and 
bogs. And now, I see my error: fens are modelled with a different "wetland=*" 
tagging, but, my language using essentially the same word for both, I stopped 
at the first occurence on the wiki page designating a mire, "wetland=bog", 
without understanding that the next one, "wetland=fen", designated exactly what 
I was looking for. The problem is the French translation of this page on the 
wiki, I'll correct it. Thanks for your answer.  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[David Marchal]

> From: chris_horm...@gmx.de
> There are of course all kind of boundary cases but the typical bog as 
> common in many parts of northern Europe is rain fed. In German we have 
> the more specific term 'Regenmoor' which indicates this. Mires fed by 
> groundwater or water inflow from the outside are usually not bogs. 
> See:
> 
> https://en.wikipedia.org/wiki/Mire
> 
> Of course wetland=bog is currently widely used incorrectly in OSM in 
> that regard. But assessing the specifics of water chemistry and plant 
> communities is not easy so this is somewhat understandable.

Ah, that can explain the difference in my interpretation: in French, bogs and 
fens are usually designated with the same word, "tourbière", which designates 
mires; this word is usually translated in English with "bog". To designate 
fens, we say "tourbière minérotrophe", but essentialy only specialists will 
know about this difference, most people will use "tourbière" for both fens and 
bogs. And now, I see my error: fens are modelled with a different "wetland=*" 
tagging, but, my language using essentially the same word for both, I stopped 
at the first occurence on the wiki page designating a mire, "wetland=bog", 
without understanding that the next one, "wetland=fen", designated exactly what 
I was looking for. The problem is the French translation of this page on the 
wiki, I'll correct it.

Thanks for your answer.   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[David Marchal]

Hello, there.

I tagged some bogs today, and I wondered: why does the wiki restricts bogs to 
"depressions that receive their water and nutrients from rainfall"? AFAIK, bogs 
are not necessarily isolated from water streams or bodies. Wikipedia talls 
about sloping bogs where running water is intercepted in the soil by plants; at 
least one well-known example comes to my mind, the lac de Lispach, in France, 
which is crossed by a river and still hosts a bog, and I saw 2 more exeamples 
today on a hike in the French mountains Vosges. Shouldn't this restriction be 
lifted, as it does not seem to be justified?

Furthermore, how could rain bring nutrients? It only brings, at least directly, 
water, and can only bring nutrients indirectly, like with erosion or bringing 
leaves.

Awaiting your answers,

Regards.  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forest parcels and national/municipal forest: how to map?

[David Marchal]

> From: g...@ir.bbn.com
> To: pene...@live.fr
> CC: tagging@openstreetmap.org
> Subject: Re: [Tagging] Forest parcels and national/municipal forest: how to 
> map?
> Date: Thu, 26 Nov 2015 09:05:01 -0500
> 
> 
> David Marchal  writes:
> 
>> 1) forest parcels: some people use a boundary relation with
>> boundary=forest_compartment, but this seems mainly used in Eastern
>> Europe, so geographically limited; others map each parcel with
> 
> (We don't do this in the US, as far as I know; sounds like allotments
> for forestry?)
> 
> I am guessing there is some biggish region used for forestry, and then
> within it there are specific areas leased/etc. to individuals/companies?
> I would tag landuse=forest around the whole thing.
> 
> Then, representing ownership/etc. within is really just like parcels for
> houses, which so far OSM has declined to put in the db.
In fact, the parcels I'm talking about have their number displayed on their 
corners, so I thought it could be useful to record them in order to ease 
orientation in forests. I'm not thinking about private, restricted access parts 
of forests, nor about their ownership, only the publicly-displayed number; I 
don't think every parcels are labelled as such, though. Besides, I saw that 
some contributors already started to do so, like here: 
http://www.openstreetmap.org/=14/48.6747/6.0705 but I asked this question 
to see if there was a recommended way to do so. 

>> 2) national/municipal forests: numerous forests, here in France, are
>> municipal or national ones — the latter being called “forêt domaniale”
>> —; many of them are labelled as such on road signs, and they are often
>> named after this parameter — like “forêt domaniale de Dabo”, Dabo
>> being the neighboring village —, so I think they should be mapped, but
>> how? Should I, there again, use a boundary relation and tag it
>> boundary=forest? This seems to be the wider-used solution and the most
>> consistent one, but boundary=forest isn't in the uses of boundary
>> relations documented on the wiki, and I read warnings on
>> help.openstreetmap.org and MLs against such undocumented uses, so I
>> prefer asking here: should I use this solution? Another?
> 
> I would do landuse=forest and then just put name= on the polygon.
> Yes, this is a boundary, but no more so than the boundary around a
> school or a church or a town park, and we don't use boundary for that.
The problem is that uch forests can be fragmented, composed of several 
disconnected pieces of land, but still named and designated as a whole, like 
this one: https://www.openstreetmap.org/relation/4775589 so, again, I searched 
for a recommended way to do so, but I only found this unofficial tagging, 
mostly consistent for me, but I prefered asking for opinions on this question 
before using this tagging scheme.

> We do have boundary=protected_area, but I think that's a mistake, and
> we should instead tag the properties on the closed way to denote the
> state of the inside. But the notion of a boundary vs a property of the
> inside of a polygon is semantically messy to start with.
No, I wouldn't use such tagging for this usage, it would be too far of the 
intended use to do anything more than messing with the data.

> One could argue that every area tag goo on a polygon could instead be
> boundary=foo. I don't think that's helpful.


  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forest parcels and national/municipal forest: how to map?

[David Marchal]

> From: g...@ir.bbn.com
> To: pene...@live.fr
> CC: tagging@openstreetmap.org
> Subject: Re: [Tagging] Forest parcels and national/municipal forest: how to 
> map?
> Date: Thu, 26 Nov 2015 09:05:01 -0500
>
>
> David Marchal <pene...@live.fr> writes:
>
>> 1) forest parcels: some people use a boundary relation with
>> boundary=forest_compartment, but this seems mainly used in Eastern
>> Europe, so geographically limited; others map each parcel with
>
> (We don't do this in the US, as far as I know; sounds like allotments
> for forestry?)
>
> I am guessing there is some biggish region used for forestry, and then
> within it there are specific areas leased/etc. to individuals/companies?
> I would tag landuse=forest around the whole thing.
>
> Then, representing ownership/etc. within is really just like parcels for
> houses, which so far OSM has declined to put in the db.
In fact, the parcels I'm talking about have their number displayed on their 
corners, so I thought it could be useful to record them in order to ease 
orientation in forests. I'm not thinking about private, restricted access parts 
of forests, nor about their ownership, only the publicly-displayed number; I 
don't think every parcels are labelled as such, though. Besides, I saw that 
some contributors already started to do so, like here: 
http://www.openstreetmap.org/=14/48.6747/6.0705 but I asked this question 
to see if there was a recommended way to do so.

>> 2) national/municipal forests: numerous forests, here in France, are
>> municipal or national ones — the latter being called “forêt domaniale”
>> —; many of them are labelled as such on road signs, and they are often
>> named after this parameter — like “forêt domaniale de Dabo”, Dabo
>> being the neighboring village —, so I think they should be mapped, but
>> how? Should I, there again, use a boundary relation and tag it
>> boundary=forest? This seems to be the wider-used solution and the most
>> consistent one, but boundary=forest isn't in the uses of boundary
>> relations documented on the wiki, and I read warnings on
>> help.openstreetmap.org and MLs against such undocumented uses, so I
>> prefer asking here: should I use this solution? Another?
>
> I would do landuse=forest and then just put name= on the polygon.
> Yes, this is a boundary, but no more so than the boundary around a
> school or a church or a town park, and we don't use boundary for that.
The problem is that such forests can be fragmented, composed of several 
disconnected pieces of land, but still named and designated as a whole, like 
this one: https://www.openstreetmap.org/relation/4775589 so, again, I searched 
for a recommended way to do so, but I only found this unofficial tagging, 
mostly consistent for me, but I prefered asking for opinions on this question 
before using this tagging scheme.

> We do have boundary=protected_area, but I think that's a mistake, and
> we should instead tag the properties on the closed way to denote the
> state of the inside. But the notion of a boundary vs a property of the
> inside of a polygon is semantically messy to start with.
No, I wouldn't use such tagging for this usage, it would be too far of the 
intended use to do anything more than messing with the data.

> One could argue that every area tag goo on a polygon could instead be
> boundary=foo. I don't think that's helpful.

P.S.: I resend this mail as it seems Outlook messed with its content the first 
time; sorry for the inconvenience. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[David Marchal]

___
> 
> On 06/11/2015 10:24, Paul Johnson wrote: 
> 
> Obviously in places where a road can have multiple equivalent 
> references (such as the US) route relations perfect sense (as does 
> figuring out which routes are actually signed on which bits of road) 
> but in places where there's only one real ref per piece of tarmac (such 
> as the UK) there's no need to force mappers to start maintaining 
> relations as well as just recording the reference. 

I also agrees with Paul. This proposal can be useful in some situations, but 
not all networks are such a mess. Here, in France, apart from E-roads,, there 
are virtually no road with several refs, and, AFAIK, that's the same for nearby 
countries. Besides, maintaining such a long relation can quickly become a 
nightmare, so I don't think it would really be useful in most situations, even 
if I understand it could be useful in some situations, like the USA networks 
you described.   
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging airport approach aid systems

[David Marchal]

Hello, there.

I'm trying to map some approach aid systems on a local airport, but I have 
trouble choosing the correct tags: the wiki mentions aeroway=navigationaid, and 
navigationaid=* to precise type, but this page has a banner telling to use 
airmark=beacon, an almost empty page with no instruction to precise the type of 
aid; the airmark tag wiki page is also empty. How should I map the approach aid 
systems? Which landuse should I use for the underlying land, as this land is 
only maintained for the approach aid system, nothing else?

Hoping you can help me,

Regards.  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] power=* tag: minor_line vs. line

[David Marchal]

> From: g...@ir.bbn.com
> To: pene...@live.fr
> CC: tagging@openstreetmap.org
> Subject: Re: [Tagging] power=* tag: minor_line vs. line
> Date: Thu, 15 Oct 2015 09:12:55 -0400
> I'm coming into this late, but I think key questions are:
> 
> transmission vs distribution: in the US, this is a big divide.
> Sometimes transmission lines are on "poles" and sometimes on
> "towers". That doesn't really matter in terms of how they work and
> are used. The point is that 115 kV or even 69 kV is distribution to
> town-based substations, not from substations to customers. Is the
> rest of the world like this?
> 
At least here in France, transmission lines are mainly on towers and 
distribution lines on poles, but there are exceptions: I know at least one 
example of a transmission line using towers only to cross a valley and using 
poles elsewhere. The difference between transmission and distribution lines is 
visible by the number of discs, but I don't think we can expect beginners or 
the first mapper that comes along to know the relation between the number of 
discs and the usage, transmission or distribution, of the line, that needs some 
technical knowledge on the power networks. Here is where the current size-based 
minor_line/line split is very practical, although not the best possible: it 
gives a simple way to do the split between minor lines and lines by simply 
looking at them, without having much technical knowledge about power networks 
operations. Of course, this split doesn't reflect the distribution/transmission 
split, but it easily gives the real importance of the line in the landscape, 
which seems more important for most consumers than knowing that a line is a 
transmission line.

> do we expect power-line mappers to be able to tell transmission vs
> distribution?
> 
> 
> I think it's reasonable to expect mappers to tell distribution from
> transmission. Do we mean minor_line is for distribution? Or is it some
> kind of transmission?
> 

Yes, you can expect power-line mappers to know the difference; that even seems 
logical, but power-line mappers aren't the only ones to map lines, whence the 
above answer: general mappers can't, IMHO, be expected to know about these 
technical details. On the contrary, experimented power-line mappers can map 
details, like voltage or the number of cables, in addition of the 
minor_line/line split, thus allowing consumers with enough knowledge to 
abstract this split and get a map of transmission/distribution lines. This way, 
the current minor_line/line split is not a major obstacle for power networks 
consumers, just something to be told of to correctly interpret the raw OSM data.

Regards.  
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] power=* tag: minor_line vs. line

[David Marchal]

Wow, I only asked about using the single line/minor_line distinction; if this 
one isn't easy at all, what will it be by adding importance or usage, which 
seems far less obvious than minor_line/line, itself not as obvious as I thought 
at first? The current disctinction has the advantage it can be discussed on the 
simple viewing of the whole line; on the opposite, importance and usage will 
not be easy to retrieve without using network managers data. Won't it be better 
to determine once and for all the correct usage of current tagging, than 
creating a new scheme which, IMHO, will add more complexity to an already 
complex question?
Regards.

> Date: Wed, 14 Oct 2015 21:02:07 +0200
> From: fl.infosrese...@gmail.com
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] power=* tag: minor_line vs. line
> 
> We are not talking about stop to differentiate power lines but to use
> different tags to do so.
> 
> By landscape : importance=* may support the difference between "big"
> and "small" power lines.
> http://wiki.openstreetmap.org/wiki/Proposed_Features/Importance
> power=line + importance=local
> power=line + importance=regional
> power=line + importance=minor
> power=line + importance=major
> and so on
> 
> On supports : color=*, structure=*, height=*
> 
> By power grid function :
> power=line + usage=distribution
> power=line + usage=transmission
> power=line + usage=traction
> and so on
> 
> I completely second what Ralph said.
> The problem is also no one has really the same point of view regarding
> power lines classification.
> 
> And we are forcing people who can't/don't want to handle such a choice
> between minor/major, huge/small, useful/not useful.
> 
> 
> Finally, how would you tag such feature ?
> https://www.google.fr/maps/@46.0051218,6.6292445,3a,75y,140.55h,108.7t/data=!3m6!1e1!3m4!1snMHy5MWRsC1Q39kjLUSkag!2e0!7i13312!8i6656
> 
> cheers
> 
> François
> 
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] power=* tag: minor_line vs. line

[David Marchal]

Thanks for the full story, Lauri. I understand now why the subject seems so 
sensitive to some. I retain from your story, if I correctly understood it 
that:* the current usage of minor_line/line is the one I previously suggested: 
use minor_line for lines mainly on poles and line for lines mainly on towers, 
with a tolerance if a line occasionally uses something different;* the problem 
of this modelling, which bothers some, is that it leads to a fuzzy modelling 
from a technical, power network point of view, because it doesn't reflect the 
actual usage, voltage or any technical characteristics of the power line;* the 
current usage of minor_line/line is nevertheless retained as it is a 
perceptible, beginners-friendly distinction, allows easy rendering, and as 
other essential characteristics, as voltage, number of cables or tower/pole 
shapes are already managed by other tags, even if some others, as the 
distribution/transport distinction, isn't modelled.
Am I correct?
Regards.

> Date: Thu, 15 Oct 2015 13:12:02 +0300
> From: lkyto...@gmail.com
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] power=* tag: minor_line vs. line
> 
> David Marchal wrote:
> > I saw conflicting points of view regarding the difference between these two
> > ways for modelling aerial power lines: some say that it is the voltage which
> > matters, others say that it's the visibility difference that matters, others
> 
> Hi.
> 
> To properly understand this issue, here's the history of the tags:
> - originally, in 2006, there was just the page Key:power (then under the
> title "Proposed features/Power Lines") with discussions specifically
> agreeing that the project should use a different tag for "large" lines
> "strung from latticework pylons" and other lines. At that time, nobody had
> seriously thought about ever mapping the smaller ones, and it is a common
> separation on all pre-OSM maps (and their source data). Being a global
> project, "latticework pylons" referred to the type of construction common in
> the countries where the early mappers resided, so even if other countries
> used different constructions for high voltage lines, they would still be
> power=tower. The original description/proposal
> http://wiki.openstreetmap.org/w/index.php?title=Key:power=6410
> and after discussions agreeing:
> http://wiki.openstreetmap.org/w/index.php?title=Key:power=17349#Notes
> 
> Power=pole was suggested already in November 2006 for support structures
> smaller than power=tower (in the link above)
> 
> - in July 2007 the descriptions of power=line and power=tower were copied
> to the Map_Features. Still, the assumption and the practice was that people
> didn't map "smaller" power lines at all; even if the description of 'line' 
> only
> referenced "the path of power cables", it was assumed they'd only be drawn
> between power=tower nodes, i.e. only high voltage lines on "big" pylons.
> http://wiki.openstreetmap.org/w/index.php?title=Map_Features=39342=39308
> 
> - in January 2008 pages were created for
> * Tag:power=tower, with the sentence still present "Should not be used for
> electricity or telephone cables carried on single wooden pole."
> * Tag:power=line, which still had a description referencing "way following
> power cables"
> * Key:power was changed to reference the template Map_features:power,
> with no change in wording
> - In March 2008 some had discussed on the osm talk list that minor
> lines could be mapped with a different tag.
> 
> - following my question in September 2008 on Talk:Key:power, minor_line was
> suggested and others started using it, too, if they hadn't already
> prior to that.
> 
> - in January 2009 the suggestion to use minor_line for "minor lines with poles
> and not towers" was added to the list template, as well as
> http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:power=next=206851
> 
> - In July 2009 rendering minor_line was already discussed on the talk-de 
> mailing
> list.
> 
> - in January 2010 the values minor_line and pole were added to the
> list template,
> after they had proved to be used.
> http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:power=401683=344715
> 
> In June 2011 some user(s) wrote a proposal to change everything above ground 
> to
> 'line' and use other tags with an unlimited list of values for
> describing their differences.
> http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Power_transmission_refinement=652518
> After discussions and a wiki vote such a change was even rejected in
> October 2013,
> and the next modified proposal (Power supports refinement) for
> redefining pow

Re: [Tagging] power=* tag: minor_line vs. line

[David Marchal]

In fact, this problem leaded me to my question: I noticed some minor lines 
tagged as power=line, cluttering the Mapnik rendering, so I searched the 
correct way of modelling them, to see if it was a rendering or modelling issue, 
and one thing leading to another…
Regarding the parting between minor_line and line, I can see that my opinion is 
common, although without unanimity, so I suppose I can safely work with my 
vision of the minor_line/line parting from now.
Thanks for your help, everybody; I'll hold the line in case of further 
developments.
Regards.
Date: Wed, 14 Oct 2015 10:26:26 +0200
From: dieterdre...@gmail.com
To: tagging@openstreetmap.org
Subject: Re: [Tagging] power=* tag: minor_line vs. line

the problem is that people often can't provide the information about voltage or 
operator, so you will end up with minor distribution lines tagged as power=line 
and nothing else, and will not have the basis to make a decision about the 
importance.

I agree that additional details like voltage, ref, operator etc. are nice to 
have, but an unambiguous decision between minor lines and transmission lines 
can be made much easier (you see this in most cases even from far away), and is 
what many mappers seem to consider sufficient, so I wouldn't deprecate this 
established system.

Cheers,
Martin


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] power=* tag: minor_line vs. line

[David Marchal]

Well, I would say: mainly on poles = minor_line, and mainly on towers = line; 
this way, the difference is easy to see for mappers, even on Bing imagery, and, 
as poles, AFAIK, are always smaller that towers, that would properly model the 
landscape impact these power lines have. Besides, I know we're not supposed to 
map for the renderer, but the OSM Mapnik stylesheet seems adapted for such 
modelling, as minor_line are rendered only on higher zooms, i.e. starting from 
z16, which seems to me a correct rendering for lines on poles, far less visible 
than lines on towers. I mean, the stylesheet guys made a logical choice, why 
not adopting the same?

Date: Tue, 13 Oct 2015 22:48:58 +0200
From: fl.infosrese...@gmail.com
To: tagging@openstreetmap.org
Subject: Re: [Tagging] power=* tag: minor_line vs. line

(Sent from a phone)
Hi David,
Many opinion exists regarding the minor or not line qualification and still no 
consensus.
As consumers may not be able to make the right distinction between minor or 
major lines, I assume using power=line only, in continental France and always 
in combination with voltage=* and operator=*.
Thus both users and mappers only have information instead of hypothesis and can 
make the distinction they want from the voltage, location and operating company.
Additionally, underground power paths use to be mapped with power=cable + 
location=underground
Let us know if you have better idea to improve power line mapping ;)
All the best
François

  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] power=* tag: minor_line vs. line

[David Marchal]

Hello, there.
I saw conflicting points of view regarding the difference between these two 
ways for modelling aerial power lines: some say that it is the voltage which 
matters, others say that it's the visibility difference that matters, others 
say that it's the danger for planes that matters, and some use other reasons or 
some of these together. The wiki doesn't help much: 
http://wiki.openstreetmap.org/wiki/Tag:power%3Dminor_line seems to primarily 
use the height of the line supports, with a lose usage of voltage, but 
http://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France says that 
any aerial line is to me mapped as power=line; meanwhile, 
https://help.openstreetmap.org/questions/45781/power-lines-minor_line-threshold 
refers to both the landscape and the danger for pilots of planes and 
helicopters. I'm inclined to use the general landscape visibility of the line 
to map it, as it seems to be the reason of the difference of rendering between 
them, which means that lines on poles and small tower would be 
power=minor_line, and lines on taller towers would be power=line, but I would 
like to have a confirmation on that, as it doesn't seem to be clear anywhere. 
If I'm able to collect enough opinions to meet a consensus, I'll try to update 
the different sources, mainly the wiki, accordingly, precising that the matter 
was discussed here and reached a consensus.
Awaiting your answers,
Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] power=* tag: minor_line vs. line

[David Marchal]

Well, I thought underground lines was to be tagged as `power=line`; besides, I 
thought like you at first, but I've been told on the help.openstreetmap.org 
link that the distribution/transmission parting should not be taken into 
primary consideration, maybe because the difference is not obvious for people 
unaccustomed with the power networks who only want to map the line they see, 
but primarily on a lanscape point of view, which takes sense, as a naive map 
reader won't try to interpret the power lines map as distribution/transmission, 
but mainly as landmarks, in which case the landscape criteria makes sense.
From: br...@7thposition.com
Date: Tue, 13 Oct 2015 10:16:55 -0400
To: tagging@openstreetmap.org
Subject: Re: [Tagging] power=* tag: minor_line vs. line

A simper way to describe this would be to say that:
`power=line` is for 
“transmission”https://en.wikipedia.org/wiki/Electric_power_transmission
`power=minor_line` is for 
“distribution”https://en.wikipedia.org/wiki/Electric_power_distribution

Trying to define this based on line voltage or tower heights or danger to 
aircraft is silly.  Transmission and distribution lines can be located 
underground. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Modelling the relation between a waterstream and one of its resurgence

[David Marchal]

> Date: Fri, 11 Sep 2015 14:18:37 +0200
> From: ricoz@gmail.com
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Modelling the relation between a waterstream and one 
> of its resurgence
> missing data should not prevent the mapping of known good data. If it has 
> been established as 
> the "main route" than it is fine to map that. We have rivers with side 
> channels and branches
> that aren't completely mapped either.

Yes, but if I try to map these waterways as a single one, it will no longer 
represent the official modelling of the stream, which is: two separate streams, 
one meeting the other on a downstream section. Modelling them as one would 
destroy the current modelling, so how can I map the connection without altering 
the current data?
> Not much different from confluence points of large rivers?
Well, the stream feeded by the other is 126 km long, and it's spring, 
resurgence of the other, is around 50 km away from the second so it can't be 
just modelled as a branch of the other.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Modelling the relation between a waterstream and one of its resurgence

[David Marchal]

Yes, I indeed thought of a karst system, but specifically of the case when one 
spring, even if it feeds a stream of its own, is in fact a resurgence of a 
partial loss of another stream.

From: j...@jfeldredge.com
To: tagging@openstreetmap.org
Date: Thu, 10 Sep 2015 17:30:24 -0500
Subject: Re: [Tagging] Modelling the relation between a waterstream and one 
of its resurgence









Are you referring to a stream
that, at some point, goes underground, then re-emerges to the surface at a
downstream point? These are common on karst terrain.
-- 

John F. Eldredge -- j...@jfeldredge.com

"Darkness cannot drive out darkness; only light can do that. Hate cannot drive 
out hate; only love can do that."
-- Martin Luther King, Jr.




On
September 9, 2015 1:56:27 AM David Marchal <pene...@live.fr> wrote:

Hello, there.
I wondered: when a
waterstream is known to be, instead of a real, separated waterstream,
merely a resurgence of another one, how should the link between them be
modelled? Which tags should I use, and in which relation? Should I tag the
resurgence by itself?
Hoping you can
help,
Regards.  
___

Tagging mailing list

Tagging@openstreetmap.org

https:/​/​lists​.​openstreetmap​.​org/​listinfo/​tagging






___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Modelling the relation between a waterstream and one of its resurgence

[David Marchal]

Hello, there.
I wondered: when a waterstream is known to be, instead of a real, separated 
waterstream, merely a resurgence of another one, how should the link between 
them be modelled? Which tags should I use, and in which relation? Should I tag 
the resurgence by itself?
Hoping you can help,
Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Modelling the relation between a waterstream and one of its resurgence

[David Marchal]

> map the underground stream if possible.
As I don't know where the intake from the first stream is, I think I can't map 
it this way. Besides, wouldn't that make the link exclusive, i.e. tell that the 
water only comes from one point and exits at another? If so, I can't either, as 
no-one can be sure of that in karstic systems: you can be sure that a ponor 
feeds a spring, but not that only this single ponor feeds only this particular 
spring, as there can be other ponors feeding this spring, and other springs fed 
by this ponor.
Anyway, I can remember of some locations where a stream is known to be 
undergroud, and that it is the same stream all along, running underground below 
its dry bed during summer and filling it only during winter, so that will be 
useful.
> If mapping the underground stream is not an option use the quite normal
> relation waterway.

The problem is that the resurgence is renowned as a separate river, even if the 
link with the losing stream is well known, and those rivers both has their 
waterway relation. How can I map the link without messing with the separate 
waterway relations ? By creating a super-relation ? I don't want to FUBAR the 
data.
Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Modelling the relation between a waterstream and one of its resurgence

[David Marchal]

> Which is why mapping this is not really within the scope of OSM - 
> natural underground waterflows are inherently non-verifiable.  

Well, maybe I should let that down, then, or put the data in the description 
field; this way, I won't mess with the OSM data, but they'll be there if 
someone is interested.

> You can and should map the surface phenomena related to the underground 
> water flow of course - ponors, dolines, karst springs and other stuff.

In fact, I'm drafting a proposal on this, which is why I asked this, to know if 
I could put something consistent on this matter in the proposal.

Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Drafting proposal: use oneway=reversible or create tag?

[David Marchal]

Hello, there.
I'm drafting a proposal concerning some waterways whose flow regularly changes 
direction, which happens near some sinkholes named estavelles, which drain or 
feed water according to the aquifer level. I would consequently propose a way 
to map it, but it should be consistent with current tags, so I wondered: should 
I propose using
oneway=reversible, as it already exists and can be used on other ways than 
roads, according to the wiki, but would in this case be used to indicate that 
something is _not_ oneway, oranother tag, such as twoway=yes, which could be 
clearer in this context of a way you would expect to be oneway, but at the risk 
of duplicating the use of oneway=no?
Hoping you can help,
Regards.
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging