Re: [Tagging] coastline v. water

[David Groom]

See comments below:

David
-- Original Message --
From: "Eric H. Christensen via Tagging" 
To: "tagging@openstreetmap.org" 
Cc: "Eric H. Christensen" 
Sent: 18/11/2020 20:19:51
Subject: [Tagging] coastline v. water


After a few days of much work, a recent collaborative project to turn the 
Chesapeake Bay from a nothing space outlined by natural=coastline to what we 
considered to be a more accurate relation of natural=water, we've received some 
negative feedback.

The difference of opinion seems to lie in the definition of what we're mapping.  The use of 
coastline is for "seas"[0] while the use of water is for "inland areas of 
water"[1].  Even though the Chesapeake Bay is tidal, there is no question that it is an inland 
waterway (it is completely surrounded by land except for the mouth at its southeast side).
Using this logic the Mediterranean Sea, the Red Sea, and the Persian 
Gulf should all have the coastline tags removed from their defining ways 
and converted to water areas!   Italy, Greece, Libya, Egypt and a large 
group of other counties would find they had no coastline, which might 
come as a surprise to anyone lining there.



The idea of using coastlines for basically creating an edge between the land 
and the nothingness of the ocean makes sense when, as far as the eye can see 
it's only water.

Now, some of the feedback that has been presented[2] is that because it is 
tidal it is part of the sea.  I have pointed out that many rivers and streams 
(and ditches!) are tidal; does that make them part of the sea?  I would not 
think so.  In fact, there are named seas on this planet that are not even 
connected to other water formations (the tiniest, according to the National 
Geographic, is the Sea of Marmara which has an area just less than 12,950 sq 
km, larger than the Chesapeake Bay).

But, tagging the Chesapeake Bay, and its tributaries, as "water" brings several 
benefits to the map and the users.  First, it helps identify the sections of water that 
exist in these areas (this can't really be done with node points as there is no way to 
define start and end points of an area).  There are many defined bays, rivers, and 
streams that make up the greater Chesapeake Bay area.  What one may see as one large mass 
of water is actually many smaller defined segments each with their own history.
This is irrelevant to the question of whether the ways should be tagged 
as natural = coastline.  You have had to create a multipolygon 
containing the ways which form the "sections of water", its perfectly 
possible to add the "name" tag to this multipolygon without removing the 
coastline tag from the ways



 Second, we can speed up any updates (fixes) to outlines of the polygons that 
happen in these water areas without having to wait for the entire Earth's 
coastlines to be re-rendered.
Changes to tagging should not be done to facilitate easier rendering on 
one particular map.



 I suspect having less coastline to render would also speed up the rendering of 
coastlines as well?

Very unlikely.


I would like for the tagging community to clarify the different between "water" and 
"coastline" and when to use each.  The definition on water seems to say to use it on inland water 
but there seems to be, at least, and open interpretation of the word "sea" for coastline that is 
dragging many inland waters into that category.

Thanks,
Eric "Sparks" Christensen

[0] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline
[1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
[2] https://www.openstreetmap.org/changeset/94093155#map=10/37.1620/-76.1581

___
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] Rio de la Plata edit war

[David Groom]

-- Original Message --
From: "Christoph Hormann" 
To: "Tag discussion, strategy and related tools" 


Sent: 07/08/2020 08:27:23
Subject: Re: [Tagging] Rio de la Plata edit war



I concur with a lot of your observations and like you i had essentially
given up on the idea of the coastline representing meaningful
information in the long term.  But considering this is a very sad
conclusion which essentially means OpenStreetMap failing in its primary
goal in the single most fundamental mapping task of the planet, namely
the distinction between ocean and land, i am trying my best here to
work towards a consensus - no matter how slim the chances are from my
perspective.

I agree




 1) We should establish an agreed "OSM Coastline position", which I
 suggest would approximate to the position of the coastline on 1
 January 2020.

 2) Any edit which moved the position of the coastline by more than
 20Km from the established position should be classed as vandalism,
 unless such movement had previously been agreed by the community.


That is a practically feasible approach but it would form a major
beachhead in abolishing the principle of verifiablility in
OpenStreetMap in favor of adopting the major consensus narrative of the
OSM community as the reality to map rather than the intersubjectively
verifiable reality.

To put it bluntly:  In your scenario if the OSM community agreed on
ignoring the physical reality mapping of the coastline could depart
arbitrarily far from said physical reality.
But we are only having this discussion because there are places where 
the coastline boundary has no "physical reality".


We de facto already have the situation that if edits are contested the
status quo is the fallback.  And more strongly formalizing that in case
of the coastline could be a good idea.  But to forgo having a
verifiable definition of the coastline tag supported by consensus is
not a good idea IMO.
I am quite happy for my proposal to be an interim solution until there 
is a "verifiable definition of the coastline tag supported by consensus"


I would however modify my last point (2) to be

(2) In the case of disagreement, any edit which moved the position of the 
coastline by more than 20Km from the established position should prima facie be 
classed as vandalism, unless such movement had previously been agreed by the 
OSM community.

This modification primarily allows for the continuing improvement of the PGS 
import without needlessly seeking prior approval in each instance

David



Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[David Groom]

I've so far stayed out of this discussion because my final thoughts on 
the matter will I am sure be contentious.


In no order of importance my thoughts are:

1) the idea of basing a the limit on coastline on levels of salinity or 
average water flows makes as little sense as trying to specify that the 
"landuse = forest" tag can only be used when there are a specific number 
of trees growing in a particular area.


2)  yes the wiki says coastline should be based on the Mean High Water 
Spring, but I've long argued that for instance no one in London would 
say they lived on the coast even though the River Thames is tidal 
upstream of the city.  Hence the border between coastline and water body 
should be downstream of the tidal influence and is based on "a 
reasonable estimation of where an observer might suggest the river ends, 
and the sea begins".  Such an estimation is imprecise, not subject to 
verification, and different observers will have different opinions - get 
over it.  As in point (1)  different observers will have different 
opinions on where a "forest" ends and "scrubland" starts.


3) Due to the needs of the rendering process we have long established 
that ways tagged "natural = coastline"  are a special case.


4) We have existing tags for "tidal = yes" and "estuary=yes", 
"admin_level = ?" which means it is unnecessary for the coastline tag to 
be used as a proxy for these.


5)  The discussion on what the tag "natural = coastline" actually means 
has been discussed for so long that it appears almost insolvable.


Given the above.

A) In view of all the points above it is not possible to write a concise 
definition of what the tag natural = coastline" represents.


B) Until January 2020 we had a reasonably broad agreement on where the 
coastline should be.  Though I recognise, perhaps more than most who 
have contributed to this thread, that there are still are large number 
of ways ( particularly in the more sparsely populated areas of the 
world, or where the OSM community is not large)  that are unchanged from 
the position they were placed in by the PGS imports in 2006.


After much thought my, probably contentious, view  is:

1) We should establish an agreed "OSM Coastline position", which I 
suggest would approximate to the position of the coastline on 1 January 
2020.


2) Any edit which moved the position of the coastline by more than 20Km 
from the established position should be classed as vandalism, unless 
such movement had previously been agreed by the community.


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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[David Dean]

Once again, thanks for everyone's great comments, but I'm not entirely sure
what, if any, consensus we can draw from our discussions here.

To my mind, we are all in agreement that we should have values for the
service tag for 'main parking access' and 'main property/campus access',
although some of us believe that the same tagging could be used for both.


# Parking Access

There are already 2K examples of service=parking in use around the world (
https://taginfo.openstreetmap.org/tags/service=parking), and while I can't
claim to have done an exhaustive study, it appears that it is used for the
purpose of the main driveways through a parking lot.

However, I am certainly open to the idea that it could be confusing as
there often may not be parking explicitly on the serice=parking way itself.

So, it's a trade-off between reflecting what seems to be established usage,
or to come up with a better tagging that we hope to become the new
established usage.

*If* we want to push for a new established usage, how about
service=parking_access ?


# Other Property/Facility/Campus Access

There are already 800 examples of service=access in use around the world (
https://taginfo.openstreetmap.org/tags/service=access), and while I also
can't claim to have done an exhaustive study, it does appear to be used for
the purpose that we have been discussing in this thread.

In this case, I certainly understand the objection that this doesn't
actually mean a lot - as all highway=service ways are for accessing
something.

Once again, it's a trade-off between reflecting what seems to be a minor
level of established usage, or to come up with a better tagging that we
hope to become the new established usage.

*If* we want to push for a new established usage, how about
service=main_access ?


Happy to hear everyone's thoughts here, and I hope to get something we can
vote on on the wiki soon.

- David

On Tue, 4 Aug 2020 at 21:43, Matthew Woehlke 
wrote:

> On 03/08/2020 19.56, Graeme Fitzpatrick wrote:
> > On Tue, 4 Aug 2020 at 01:10, Matthew Woehlke wrote:
> >> Parking lot access roads are a common example; I don't really feel that
> >> these are "driveways", but I also prefer to reserve "parking_aisle" for
> >> ways that actually *have* parking spaces along them.
> >
> > Main through road across the front of the shopping centre, with
> > parking_aisles opening off it, put with a dozen or so specialised parking
> > spaces (disabled, ambulance, reserved, electric vehicle charging) on it -
> > does that change it from "access" to another parking aisle?
>
> Maybe. It's possible I'd tag that as a parking_aisle. The point was more
> though that I wouldn't use parking_aisle for something that *doesn't*
> have parking spaces.
>
> >> service=driveway/drive-through -> Service way for access to a fuel
> station
> >>
> >> IMHO, a drive-through is a very specific type of way which involves a
> >> service window. *Maybe* you could argue for that in case of a
> >> full-service fuel station, but I wouldn't use it otherwise. (Note:
> >> "drive through" implies that the vehicle will engage in stopping but no
> >> standing or parking.)
> >
> > No, driveway/-through is good for a fuel station, as well as anywhere
> else
> > that you don't get out of your car to be served eg take-away, car wash,
> > bottle shop (liquor store)
>
> "Anywhere else that you don't get out of your car to be served" is
> effectively what I proposed, but (at least in the US, nearly all) fuel
> stations do *not* meet that criteria.
>
> --
> Matthew
>
> ___
> 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] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[David Dean]

Thanks for the great feedback, everyone.

Firstly, I don't want anyone to feel that just tagging highway=service is
wrong, and you have to have a service tag. Any information available on the
map is more useful than no information. I just want the ability to
differentiate between 'we don't know what sort of service road this is' and
'we know it is a main parking road and/or access within a private
residential/commercial/industrial/etc property/campus'.

On the main parking road, I think we are largely in agreement that
service=parking would be a good addition to OSM documentation (and is
already in use throughout the world, as such).

For the second type of highway=service with no service tagging, what about
using service=access?
It has been used about 1K times already (
https://taginfo.openstreetmap.org/tags/service=access#overview,
https://overpass-turbo.eu/s/WGY), and looks like it has been used in that
general 'access to facilities on a larger property/campus' sense.

For example: https://overpass-turbo.eu/s/WGZ.

- David

On Mon, 3 Aug 2020 at 08:31, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 3. Aug 2020, at 00:18, Graeme Fitzpatrick 
> wrote:
>
>
>> So what all these have in common is that they are not public roads not
>> intended for through-traffic. They are all on private/public properties.
>> So maybe they could be summarized under service=property, with a
>> description like "roads on (private) large properties, such as on
>> hospital grounds, cemeteries, camping grounds, industrial or commercial
>> areas"
>>
>
> That's a nice idea!
>
>
>
> not all “service without additional subclass” are on properties, while
> most of those that already have additional subclasses like
> service=driveway/parking_aisle/drive_through etc. usually are. IMHO
> “property” would be misleading as qualifier for more important service roads
> ___
> 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]

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

[Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[David Dean]

Hi everyone,

I'm interested in proposing and/or documenting existing tagging approaches
of the wiki to ensure that all highway=service ways can have a service=?
associated tag. Having done, so I'm planning on resurrecting
https://github.com/westnordost/StreetComplete/issues/808 to help people get
all service roads appropriately tagged in their area.

At the moment, service=? can be (according to the wiki at
https://wiki.openstreetmap.org/wiki/Key:service):

* service=parking_aisle
* service=driveway
* service=alley
* service=emergency_access
* service=drive-through

But service roads are also used for the 'main ways on a parking lot', and
there is also an indication of access to multiple businesses (like in an
industrial estate etc), and it looks like the documented way is to not to
provide a service=? tag in this case.

This seems problematic to me from a map maintenance purpose, as how do we
know if a highway=service just hasn't had a service=? tag applied yet, or
if it is one of the exceptions that does not get a service=? tag (and which
one is it?)

I would like to try to understand the highway=service usages that don't
have a current documented service=? tag and either propose an appropriate
tag or find examples of existing tagging to document.

At this stage I think appropriate tagging for some of the missing service=?
tagging indicated in the documentation would be:

service=parking -> main way in a parking lot, for connecting
service=parking_isles (used almost 2K times already:
https://taginfo.openstreetmap.org/keys/service#values)

service=driveway -> also used for access to multiple businesses (like in an
industrial estate, etc)

service=driveway/drive-through -> Service way for access to a fuel station


Are there any other main understood uses of no service=? tag that would
need an appropriate service=? tag to fill this gap?

Once I've got some good starting feedback from this forum, I plan on
revising
https://wiki.openstreetmap.org/wiki/Proposed_features/service%3Dparking to
include any new appropriate service=? (not just service=parking) tagging
and start the formal RFC process.

Thanks for your feedback, everyone.

- David
___
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

Re: [Tagging] Coastline for rivers, estuaries and mangroves?

[David Groom]

-- Original Message --
From: "Joseph Eisenberg" 
To: tagging@openstreetmap.org
Sent: 07/09/2018 04:02:26
Subject: Re: [Tagging] Coastline for rivers, estuaries and mangroves?

I've now edited the coastline in the area mentioned. I have now added 
natural=coastline along all the ways forming the edge of the mangroves 
and open water. 
https://www.openstreetmap.org/changeset/62340975#map=13/-4.9075/137.1762


I have to say that to me this seems wrong. Coastline tags are now on 
ways forming channels 40m wide and 30km from open ocean.  I just don't 
see that these are "coastlines" .


David




Further west, I moved the administrative boundary off of the coastline 
of internal waterways, positioning it near the low water line / 
baseline, because I believe this is closer to the official Indonesian 
definition for Kabupaten (admin level 6) boundaries, and it no longer 
creates separate polygons around each patch of mangroves. 
https://www.openstreetmap.org/changeset/62344890#map=14/-4.8615/136.8500


This brought up another issue. I did not want to delete the 
natural=water areas, so I changed them to multipolygons (since I had to 
break the closed ways to make a proper coastline) and marked salt=yes, 
removing natural=river from the areas that might better be described as 
tidal channels. I considered using water=tidal or water=salt, but both 
of these tags seem to have limited use and an unclear definition; JOSM 
suggested salt=yes.


But I am uncertain what to do with the waterway=river in the case of 
tidal channels and the complex connections between rivers in these 
mangrove areas. A search of taginfo did not find an alternative tag, 
although river=tidal is in use. I think there should still be a 
waterway midline for the large tidal channels in the mangroves which 
can be used by boats or even ships, to help navigation software. (Many 
of these channels were actually created by flowing river water; the 
rivers in this area meander strongly and often change the location of 
the mouth, as can be seen by comparing the current situation to 100 
year old Dutch maps)


Perhaps waterway=river with tidal=yes or river=tidal is the best option 
to prevent tag fragmentation? Or is river=tidal_channel preferable? The 
problem is determining the direction of water flow when two channels 
connect. Besides tidal, is there a better tag to imply two-way water 
flow depending on the tidal cycle?


Joseph



Message: 3
Date: Wed, 5 Sep 2018 18:03:36 +0200
From: Christoph Hormann 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Coastline for rivers, estuaries and mangroves?
Message-ID: <201809051803.36467@imagico.de>
Content-Type: text/plain;  charset="utf-8"

On Wednesday 05 September 2018, Joseph Eisenberg wrote:
> Specific examples:
>
> 1) This changeset on the River Dart in southwest England was the
> source of the Help site question:
> https://www.openstreetmap.org/changeset/61959067

The coastline closure there:

https://www.openstreetmap.org/way/216482240

is both below the lower limit of the proposal and below the the range 
i

can imagine a meaningful coastline closure rule to allow.

I would however be interested in hearing any universal rule that would
allow this kind of placement based on physically observable criteria
and that would maintain the coastline as a meaningful geometry on its
own.

> It looks like quite a large estuary, much wider than the non-tidal
> part of the river upstream.

That is largely not really an estuary but more of a ria.  I have no 
data

for this at hand but you can likely see an abrupt change in the
elevation profile near Totnes where the submerged section of the 
former

river valley starts.  So in this case it would make a lot of sense to
place the coastline closure near the upper end of the tidal section
because this is much better defined in terms of physical geography.

> 2) The estuaries and mangrove tidal channels in this area:
> https://www.openstreetmap.org/#map=11/-4.8806/136.9339

Here i likewise see no meaningful motivation for the current coastline
placement - like here:

https://www.openstreetmap.org/way/614052686

Poor image quality in the available sources makes identifying the 
limit

of the mangroves difficult, you really need to make use of available
lower resolution open data images in the area for proper maiing here.
But you can conclude a few thing from the structure of the network of
channels.  For example

https://www.openstreetmap.org/relation/7301266

is quite clearly not a river but a tidal channel (there is no river
feeding it, it is just draining seawater that has entered during
raising tide).

> I previously changed the coastline to be closer to the river mouths
> in another section of coast to the southeast, but perhaps I should
> change it back? The whole idea of coastline around mangrove swamps 
is

> most c

[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] maxweight=* specified for different axle counts

[David Wang]

What is the best way to specify the maximum weight when a sign specifies 
different weights for different axle counts?




The situation in question is here:

https://www.mapillary.com/map/im/VMM_wbgzcm1jFm_APKhQww




For those who cannot see the image, the sign says

: WEIGHT LIMIT

: 2 axle - 10 tons

: 3 axle - 16 tons

: 4 axle + - 17 tons

(“tons” in this case means “short tons”, as it is in the US)




I went through the Tagging list archives and found a thread from Dec 2015/Jan 
2016, with the subject “Specifying maxweight, when different weight limits are 
signed” (starting here: 
https://lists.openstreetmap.org/pipermail/tagging/2015-December/027931.html and 
here: 
https://lists.openstreetmap.org/pipermail/tagging/2016-January/027975.html)


My problem is that placing “maxweight=10 st” and “maxweight=17 st” are both not 
true to the information on the ground, plus info is lost. 


One solution proposed in the above thread is to find the weight borne per axle 
and then use the most restrictive weight, as in (17 st)/(4 axles)=4.25 st/axle, 
tagged as “maxaxleload=4.25 st”. Unfortunately, the last is 4+ axles, meaning 
that with multiple axles, the maximum load per axle goes to zero, so this does 
not work. 


Another solution was to use the access keys as suffixes on the maxweight key, 
as in “maxweight:hgv” and “maxweight:bus”, to specify the maximum weight. 
However, I find this solution clunky. It also doesn’t address the fact that 
some vehicles can have different axle counts, for example an HGV can have 
anywhere from two to five axles. 


I feel this situation might need a new suffix at the very least 
(“maxweight:axles:#=*” ?), but it’s definitely up to comment.


Thanks,

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

Re: [Tagging] 3d-tagging

[David Fox]

Which one? Link?
There were a few.

On 24 May 2018, at 10:05, "Stefan K."  wrote:

I found a wiki for 3d-tagging, is that a proposal? Can i tag using  
theses suggestet tags?
Unfortunately i could not find a 3d-mailinglist so i thought i mayb  
try it here. The 3d section in the forum seems not to populated  
unfortunately, i would prefer it over the mailing-list :(

Greetings


___
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] 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] Road barrier

[David Swarthout]

Huh?

access=motorcar is for motorhomes?  That's not the way I interpreted it. I 
thought a motorcar was the same as an automobile, like a family car. A 
motorhome is a large vehicle that's suitable to live in. That's from an 
American English perspective.

Dave

Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand


From: Georg Feddern 
Sent: Tuesday, November 28, 2017 5:26:12 PM
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Road barrier

Am 28.11.2017 um 10:00 schrieb Martin Koppenhoefer:
On 27. Nov 2017, at 13:51, Selfish Seahorse 
> wrote:

Sorry for asking again, but does anyone know if motorcar=no implies
that there is no access for all multi-track motor vehicles or only for
motorcars?

In case hgv are permitted I’d explicitly tag it with hgv=yes, but according to 
the wiki, motorcar only implies motorhome:
https://wiki.openstreetmap.org/wiki/Key:access

Yes, unfortunately the european common-in-use traffic sign "VEHICLES PROHIBITED 
EXCEPT MOTORBIKE/SIDECAR" or "Prohibited for any double-tracked motor vehicles" 
has no equivalent in the OSM access scheme.
I think it is time for a =double_tracked (motor vehicles)!
___
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] Proposal: "slogan" tag. Opinions?

[David Fox]

Many company names are trademarked, yet included in OSM. 

That said, I'm uncertain of any benefits of a 'slogan' tag.

On 19 September 2017, at 08:19, Tod Fitch  wrote:

It is my understanding that corporate slogans are usually trademarked and 
written permission is required to use or reproduce them.

I think that would rule them out as acceptable items to include in OSM.


On September 19, 2017 12:13:21 AM PDT, SwiftFast  wrote:

The slogan tag would contain a company/organization's slogan or motto.
It is human-readable, similar to the "description"[1] tag. Multiple
languages are allowed with the "slogan:lang" format, just like
descriptions and names.

Example usage:
brand=McDonald's
slogan=I'm Lovin' it

[1] https://wiki.openstreetmap.org/wiki/key:description


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


-- 
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

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] ferry relations

[David Groom]

-- Original Message --
From: "wille" 
To: "Tag discussion, strategy and related tools" 


Sent: 17/08/2017 16:06:39
Subject: [Tagging] ferry relations


Hello!

The wiki page https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry 
says that "No relation should be used even if the key route 
=* suggests this.".


However more or less 10% of the route=ferry objects are relations, the 
routers and renderers seems to deal well with it and there are very 
long routes that shouldn't be a unique way.


Does that wiki recommendation make sense nowadays? Should we update it?

Thank you,
--
Wille
http://wille.blog.br
http://maption.com.br/


I note the wiki page 
https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry  was only changed 
in June of this year to remove the suggestion that relations could be 
used.  Might be a good idea to see why the wiki editor changed the page


David___
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] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[David Bannon]

On 07/03/17 20:58, Thilo Haug wrote:

...

I'm not really sure about which issue you talk in the 2nd part of your 
message "not actual rules",
do you refer to my entry in the proposal about a "code of conduct" ? 
...


Thilo, what I was suggesting is that you need to receive the list 
messages, read them, understand the ideas behind them. That cannot 
happen if you try to block all messages other than your own topic (or 
unsubscribe). Or think of them as spam.




"own data, as an overlay" doesn't make sense to me in this case,


OK, then thats not a suitable solution for you.


Didn't understand what you mean with "digest approach" ?

I thought you mentioned getting the list communications via digest 
instead of directly receiving what you call spam. If not, sorry for the 
distraction.


David





Cheers,
Thilo


Am 07.03.2017 um 04:15 schrieb David Bannon:

On 07/03/17 04:55, Thilo Haug wrote:

..

I (accidentally) unsubscribed because of the "spam" coming in,
means I didn't get just messages regarding the topic.

Thilo, perhaps thats the underlying problem here ?  You read the 
rules on the wiki, complied with what you understood and now, I guess 
feel as if you are being treated a bit unfairly ? However, I doubt 
that any proposal has succeeded where the proposer has not been a 
member of this list, been actively reading the messages at least and 
probably been contributing as well.


The truth is that not all the "rules" are on the wiki, there is a 
huge quantity of community knowledge, not actual rules, and much of 
it is accessible via this list. We have a large number of very 
experienced  database, rendering, mapping, cultural experts who live 
here (no, I'm not one!). They comment on a proposal and help a 
proposal comply with the OSM culture. Their "rules" are not written 
down as the document would run to 100's pages and we'd never agree on 
the content. Written rules have to cover every possible situation. 
Too hard.


This list is very welcoming, always open to new ideas and not, in any 
way, locked into particular policies. Within the list you will find 
widely differing views but always respect for others.


To solve your problem Thilo, you could do a number of things. 
Firstly, tags in OSM do not need be approved. I, personally don't 
recommend unapproved tags but lots will disagree with me. 
Alternatively, its relatively easy to put your own data, as an 
overlay, onto an OSM map. Keep you data privately or put it into one 
of the public POI databases. But really, I strongly recommend you 
keep trying as you are, refine and improve your proposal with the 
help of the mailing list, understand why OSM "rules" are what they 
are. You can then make a good tag, one that can be used around the 
world and rendered on lots of maps.


By the way, I would not recommend the digest approach, I found it 
harder to assign time to. Digest users, when replying, often seem to 
forget to change the message title and are not always taken seriously :-)


David




Am 06.03.2017 um 18:09 schrieb Martin Koppenhoefer:


2017-03-06 17:46 GMT+01:00 Michael Reichert <naka...@gmx.net 
<mailto:naka...@gmx.net>>:


Hi Martin and others,

Am 2017-03-06 um 17:37 schrieb Martin Koppenhoefer:
> yes, that wording is unfortunate, because in most/many OSM
mailing lists
> messages never get approved. I am myself admin of a very
small regional ML
> and from time to time there are periods where a lot of spam
arrives, I can
> imagine checking held back messages in the big lists would be
a lot of work
> (and mostly consist in rejecting spam). You would also have
to do it daily,
> because after some time many messages will seem out of context.

I have changed the wording of the wiki page Proposal_Process
today to
stress the necessity to subscribe the Tagging mailing list.
Feel free to
modify/revert it if you don't like it.



As you name me in person: I was not referring to the wording in the 
wiki but the wording of the mailing list autoresponder message in 
case someone not subscribed sends a message (and from the reply 
might get to the impression that it will pass, which it in fact 
almost never does for any of the OSM lists).


Cheers,
Martin


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


--

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856


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




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


--

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[David Bannon]

On 07/03/17 04:55, Thilo Haug wrote:

..

I (accidentally) unsubscribed because of the "spam" coming in,
means I didn't get just messages regarding the topic.

Thilo, perhaps thats the underlying problem here ?  You read the rules 
on the wiki, complied with what you understood and now, I guess feel as 
if you are being treated a bit unfairly ?   However, I doubt that any 
proposal has succeeded where the proposer has not been a member of this 
list, been actively reading the messages at least and probably been 
contributing as well.


The truth is that not all the "rules" are on the wiki, there is a huge 
quantity of community knowledge, not actual rules, and much of it is 
accessible via this list. We have a large number of very experienced  
database, rendering, mapping, cultural experts who live here (no, I'm 
not one!). They comment on a proposal and help a proposal comply with 
the OSM culture. Their "rules" are not written down as the document 
would run to 100's pages and we'd never agree on the content. Written 
rules have to cover every possible situation. Too hard.


This list is very welcoming, always open to new ideas and not, in any 
way, locked into particular policies. Within the list you will find 
widely differing views but always respect for others.


To solve your problem Thilo, you could do a number of things. Firstly, 
tags in OSM do not need be approved. I, personally don't recommend 
unapproved tags but lots will disagree with me. Alternatively, its 
relatively easy to put your own data, as an overlay, onto an OSM map. 
Keep you data privately or put it into one of the public POI databases. 
But really, I strongly recommend you keep trying as you are, refine and 
improve your proposal with the help of the mailing list, understand why 
OSM "rules" are what they are. You can then make a good tag, one that 
can be used around the world and rendered on lots of maps.


By the way, I would not recommend the digest approach, I found it harder 
to assign time to. Digest users, when replying, often seem to forget to 
change the message title and are not always taken seriously :-)


David




Am 06.03.2017 um 18:09 schrieb Martin Koppenhoefer:


2017-03-06 17:46 GMT+01:00 Michael Reichert <naka...@gmx.net 
<mailto:naka...@gmx.net>>:


Hi Martin and others,

Am 2017-03-06 um 17:37 schrieb Martin Koppenhoefer:
> yes, that wording is unfortunate, because in most/many OSM
mailing lists
> messages never get approved. I am myself admin of a very small
regional ML
> and from time to time there are periods where a lot of spam
arrives, I can
> imagine checking held back messages in the big lists would be a
lot of work
> (and mostly consist in rejecting spam). You would also have to
do it daily,
> because after some time many messages will seem out of context.

I have changed the wording of the wiki page Proposal_Process today to
stress the necessity to subscribe the Tagging mailing list. Feel
free to
modify/revert it if you don't like it.



As you name me in person: I was not referring to the wording in the 
wiki but the wording of the mailing list autoresponder message in 
case someone not subscribed sends a message (and from the reply might 
get to the impression that it will pass, which it in fact almost 
never does for any of the OSM lists).


Cheers,
Martin


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


--

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856


___
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] Mapping time zones as geometries (relations)

[L. David Baron]

On Monday 2017-03-06 14:15 -0500, Richard Welty wrote:
> On 3/6/17 11:21 AM, Paul Johnson wrote:
> > On Mar 5, 2017 18:30, "Frederik Ramm" <frede...@remote.org
> > <mailto:frede...@remote.org>> wrote:
> >
> > Hi,
> >
> >I would like to start a discussion about the mapping of time zones.
> >
> >
> > What do you think?
> >
> >
> > I'm generally opposed to mapping timezones in OpenStreetMap unless the
> > tzdata maintainers are 100% on board.  Since timezones are a royal
> > pain to keep track of, often changing 100+ times a year, on as little
> > as a few hours notice in some cases.
> >
> i agree. this a perfect example of something that belongs in its own
> database or
> shape file, available to be overlaid on the map when it's wanted.

For what it's worth, data of this sort are maintained at
http://efele.net/maps/tz/ , although the shapefiles there (based on
VMAP0) are somewhat inferior to OSM data, since a number of the
national boundaries (e.g., using the Sudanese claim for the
Egypt/Sudan border) or coastlines (e.g., Aral Sea) are quite out of
date, in ways that are noticeable when overlaying the data.

Apparently the
http://efele.net/maps/tz/world/tz_world_ingredients.zip file there
has information that could be used to rebuild the shapefiles on top
of other sources of data, but I've never attempted to do this.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[David Bannon]

Maybe its time someone put a note on the proposal page saying that the 
author is posting to the list but does not appear to be receiving 
messages from it ?


In case its a language issue, could that message be in German and 
English perhaps ?


David


On 06/03/17 05:17, Martin Koppenhoefer wrote:



sent from a phone

On 4 Mar 2017, at 16:50, Thilo Haug <th...@gmx.de 
<mailto:th...@gmx.de>> wrote:



Please check where this mail has been gone, reason :
https://lists.openstreetmap.org/pipermail/tagging/2017-March/031403.html



maybe you haven't been subscribed with the email address from which it 
was sent by the time it was sent? You should have gotten an automatic 
reply in this case.



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] 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] amenity=vending_machine and vending=public_transport_plans?

[David Bannon]

On 18/02/17 18:59, Martin Koppenhoefer wrote:

...a 'ticket' could be 'single use, with the option of a return journey, for a 
set distance or place'.
...a 'card' could be 'multiple use, no set time or distance, limited by the 
amount on the card'?
...a 'pass' could be for a planned trip over a set route?


I suggest not to get into this level of detail, as this is quite volatile data, 
and there are often lots of different options
Yes, I strongly agree Martin. A far better approach would be to include 
a link to an authoritative source.  Just about all of these services 
have their own website. And its someones job to keep the information 
current !


Please see http://wiki.openstreetmap.org/wiki/Key:website

David

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

Re: [Tagging] self-service laudry machines a camp and caravan sites

[David Bannon]

I would think shop=laundry means there is  some sort of service provided 
at the campsite that involves someone else actually doing your laundry 
for you for a fee.


As you say, thats not the same thing as having machines available at a 
camp for you to do your laundry. I would prefer something like 
laundry=yes|no|fee.


David



On 08/02/17 20:28, Volker Schmidt wrote:

I see on the wiki page
http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site
the option
shop=laundry

This does not seem to be appropriate to map caravan sites that offer 
self-service coin-operated washing machines or dryers (and it seems 
not to be in use anyway).


Is there a common scheme that I have overlooked?



___
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 - dog toilets

[David Bannon]

Thanks Joost, I'd prefer option one or four. wrt lack of porcelain, the 
term "toilet" can also be used to refer to the room where the porcelain 
thing is located. So dog_toilet seems quite accurate.


But dog* or pet* ?  I do see people traveling with a cat but would be 
very surprised if a cat was comfortable using a doggy smelling place. I 
cannot image any other pet being very keen either. So rather than your 
99% dog use, I'd suggest its 100% dog for practical purposes.  Anyone's 
experience different ?


David


On 20/01/17 19:36, joost schouppe wrote:

Hi,

There were some previous discussions on how we could tag designated 
areas for dogs to urinate/defecate. They are quite common, but 
unfortunately there are many different tags going around for lack of 
documentation.


I have added a section to an old proposal page with these options 
(also links to the previous discussions I know of here). I'm not sure 
how we can get the comments here to translate to reducing the proposal 
to just one tagging option? Maybe have a pre-vote?


https://wiki.openstreetmap.org/wiki/Proposed_features/Dog_Poop_Area

Description:
This is an area designated for pets (dogs) urinate and excrete. Unlike 
dog_park label, the main objective of the area is not that dogs play. 
It is usually small and fenced areas, but can also just be a 
designated patch of grass by the side of the road. It is known as 
pee-can in some countries.




Joost Schouppe
OpenStreetMap <http://www.openstreetmap.org/user/joost%20schouppe/> | 
Twitter <https://twitter.com/joostjakob> | LinkedIn 
<https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup

<http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>


___
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] dog toilets

[David Bannon]

I would find it very hard to support "potty_area". A potty is a 
container used by small children during toilet training, what has that 
got to do with dogs ?


David


On 10/11/16 01:24, joost schouppe wrote:

Hi,

Many cities have special little areas which are specifically meant to 
be used as a toilet area for dogs.


They look like this:

http://photos1.blogger.com/blogger/2420/844/320/Hondentoilet.jpg

There is a proposal for this:

https://wiki.openstreetmap.org/wiki/Proposed_features/Dog_Poop_Area

It proposes amenity=potty_area (used about 50 times) . But there is 
also the (more descripitve?) tag dog_toilet (used about 30 times).


It should be pretty straightforward to merge these two tags. But 
before starting to contact people, I'd like to hear your opinion on 
the merits of both tags.



--
Joost @
Openstreetmap <http://www.openstreetmap.org/user/joost%20schouppe/> | 
Twitter <https://twitter.com/joostjakob> | LinkedIn 
<https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup 
<http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>



___
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] Tagging of Country Names

[David Bannon]

Sven, your approach makes sense assuming people only look at maps of 
their own country. Yes, I agree its respectful to people living in a non 
english speaking country but really does not address a much larger problem.


As a native English speaker, I often turn to OSM to help me understand 
some of the global issues around at present. But even now, many of the 
place names are rendered in local language, quite unreadable to me. As 
has been suggested, a database of names in every conceivable language 
would be a ideal, then a renderer can deliver a map readable in an 
appropriate language. That does sound like wikidata 


So, I suggest its possible your solution improves a small aspect of a 
larger problem but just perhaps also makes that larger problem even worse ?


David


On 26/10/16 02:02, Sven Geggus wrote:

Hello,

in our localized German map style we try to render Country names in German
with local name in parenthesis.

This works fine for a lot of countries. An example would be Thailand:
Thailand (ประเทศไทย)

or (more readable for westerners) France:
Frankreich (France)

Unfortunately there are some countries where this will not work:

Ägypten (Egypt مصر)

So this is where the tagging discussion starts.

I consider this a bad example of tagging for the renderer.

English is not an official language of Egypt thus the string "Egypt" is
simply invalid in the countries name tag.

What I consider valid would be the countires name in all of its official
langages.

Thus the right one would be:
Ägypten (مصر)

So I propose a correction of all country names to names into official langages 
of
the respective countries only and to remove all english names.

Any objectives?

Sven




___
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 Bannon]

On 06/09/16 08:08, Tod Fitch wrote:

There are places in the desert southwest of the United States where the place 
you drive is exactly the water course. And these can extend for miles. Saying 
that one feature on the ground needs to OSM objects because they have different 
properties is bogus: It is one object, you drive on it 99.9% of the time, and 
it carries water 0.1% of the time (percentages arbitrary here and will vary 
from one instance to the next).


"needs to be separate OSM objects  bogus" ?  No, sorry Tod, 
I disagree. The water course is made by a rain event. The road is 
something we have made, in practice just by driving along there in this 
case. Both the road and the water course will change over time but 
possibly independently of each other.   A example close to my heart is 
the road to the Finke Gorge National Park, N.T. AU. About 15 to 20Km 
from memory. When I first used it, it was almost all through the dry 
river bed. Over time, some parts are now along the banks and around 
obstacles. The road is referred to on maps and in National Park rules 
(etc), the waterway is defined by water flow, governed by the occasional 
rain  event. They have a different history, a different use and a 
different future.


David


___
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] Help required on tagging a "wadi"

[David Bannon]

On 05/09/16 04:34, Greg Wickham wrote:
In Saudi Arabia a wadi is a mostly dry riverbed that carries water 
very infrequently (maybe a couple of times year).

..

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


Greg, I think you have the tags right but I'd rather see the waterway 
and highway mapped as separate ways, even if they superimpose. While 
they may be in the same place, they are different things.  If the wadi 
is like what we see here in Oz, its probably pretty wide and may be best 
mapped as an area rather than a line, that way, the highway way would be 
more distinguishable. And we need be realistic about their position and 
accept they move.


David





Suggestions welcome.

   -Greg

--


___
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 - Voting - (midwife)

[David Picard]

Hi,

I removed over specific text about the country. The description of 
services does not exclude anything (like give birth).


Cheers.


Le 26/08/2016 00:44, Martin Koppenhoefer a écrit :



sent from a phone


Il giorno 25 ago 2016, alle ore 22:46, David Picard <dave...@yahoo.fr> ha 
scritto:

So, my description is too specific ? What if I just drop the following sentence 
? It is not really meaningful, anyway.
"In some countries, like France, a midwife is a profession on its own, not a 
specialized nurse like e.g. in the U.S.".



yes, remove anything not needed. Examples often are counterproductive, because 
people tend to generalize them, and in this case it doesn't really matter for 
osm mapping whether your country sees them as specialized nurses or as a 
profession on its own, how much they earn or how long you have to study etc. 
You will tag a midwife (s office? practice?) when they can be considered 
midwifes according to the situation in your country.




Also, about rendering : here in France, midwives in hospitals/clinics usually 
wear a pink suit. So, I guess the doctor symbol could be used if changed from 
red to pink. What do you think ?



-1, this is likely specific to France and will not be understood elsewhere


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] 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

Re: [Tagging] Feature Proposal - Voting - (midwife)

[David Picard]

Hi,

So, my description is too specific ? What if I just drop the following 
sentence ? It is not really meaningful, anyway.
"In some countries, like France, a midwife is a profession on its own, 
not a specialized nurse like e.g. in the U.S.".


Also, about rendering : here in France, midwives in hospitals/clinics 
usually wear a pink suit. So, I guess the doctor symbol could be used if 
changed from red to pink. What do you think ?


Cheers,
David.

Le 23/08/2016 02:02, David Bannon a écrit :

David, I am very sorry to only comment after you have gone to the vote,
very rude of me !

But I have been away, quite remote and very poor internet access, big
backlog of unread mail.

David, my partner is a midwife but of the "specialist nurse" variety.
What concerns us is how this tag will be used in parts of the world that
have a different midwife model. Here in Australia, midwives generally
work from, typically, hospitals or clinics and offer a reduced range of
services.

I think some advice needs to be given in the proposal on how to use it
in places that don't fit your description. Either

* "don't use it" or

* "use it but map users need be aware that services may not be as
described."

I suspect the first is a better option.

David

On 23/08/16 06:29, David Picard wrote:

The vote is open for :
https://wiki.openstreetmap.org/wiki/Proposed_features/midwife

___
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

Re: [Tagging] Feature Proposal - Voting - (midwife)

[David Bannon]

David, I am very sorry to only comment after you have gone to the vote, 
very rude of me !


But I have been away, quite remote and very poor internet access, big 
backlog of unread mail.


David, my partner is a midwife but of the "specialist nurse" variety. 
What concerns us is how this tag will be used in parts of the world that 
have a different midwife model. Here in Australia, midwives generally 
work from, typically, hospitals or clinics and offer a reduced range of 
services.


I think some advice needs to be given in the proposal on how to use it 
in places that don't fit your description. Either


* "don't use it" or

* "use it but map users need be aware that services may not be as 
described."


I suspect the first is a better option.

David

On 23/08/16 06:29, David Picard wrote:

The vote is open for :
https://wiki.openstreetmap.org/wiki/Proposed_features/midwife

___
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] Feature Proposal - Voting - (midwife)

[David Picard]

The vote is open for :
https://wiki.openstreetmap.org/wiki/Proposed_features/midwife

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

Re: [Tagging] Feature Proposal - RFC - (midwife)

[David Picard]

OK, I updated the page, using your comments.

https://wiki.openstreetmap.org/wiki/Proposed_features/midwife


Le 01/08/2016 à 17:13, Martin Koppenhoefer a écrit :


2016-08-01 17:03 GMT+02:00 David Picard <dave...@yahoo.fr
<mailto:dave...@yahoo.fr>>:

I think your proposal should be more explicit about the actual
tagging
you propose (key=value, possibly in bold text).


I don't understand what you mean here. I have no experience with OSM.



it was a suggestion regarding your layout of the page, right now I have
difficulties seeing which actual tag is proposed, or in other words,
which "key" and which "value" should be used to indicate the feature you
describe. These should stand out a little bit more to make it clearer
(just a suggestion).

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] Feature Proposal - RFC - (midwife)

[David Picard]

How about healthcare=midwife ?

Le 01/08/2016 17:13, Martin Koppenhoefer a écrit :


2016-08-01 17:03 GMT+02:00 David Picard <dave...@yahoo.fr
<mailto:dave...@yahoo.fr>>:

I think your proposal should be more explicit about the actual
tagging
you propose (key=value, possibly in bold text).


I don't understand what you mean here. I have no experience with OSM.



it was a suggestion regarding your layout of the page, right now I have
difficulties seeing which actual tag is proposed, or in other words,
which "key" and which "value" should be used to indicate the feature you
describe. These should stand out a little bit more to make it clearer
(just a suggestion).

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] Feature Proposal - RFC - (midwife)

[David Picard]

Hi,


Le 01/08/2016 à 11:15, Martin Koppenhoefer a écrit :


2016-07-31 19:21 GMT+02:00 David Picard <dave...@yahoo.fr
<mailto:dave...@yahoo.fr>>:

https://wiki.openstreetmap.org/wiki/Proposed_features/midwife

Definition: a midwife practising as a licensed professional in
an office



I think your proposal should be more explicit about the actual tagging
you propose (key=value, possibly in bold text).


I don't understand what you mean here. I have no experience with OSM.


Also the definition
leaves a lot of uncertainty (is this a about an office or a practice, or
is this the same in this context? Is it for the place where
examinations/birth is happening or is it for an administrative place, or
both?) Is this only for standalone features, or also for midwifes
associated to a clinic or hospital?


I guess it depends a lot on the country ! For example, in France, the 
only definition is : a place where a woman can exercise and get prepared 
for childbirth, get cured for a range of gynaecological problems (from 
puberty to end of life), get prescription for contraceptives, be taken 
care of before and after childbirth. It is NOT a place to give birth. 
Midwives who run a place like this in France are not linked to a clinic 
nor hospital.



Why do you require "licensed" (think
of places where public administration works worse, maybe they don't have
official licenses for midwifes).


I am not an English speaker. I meant an independent worker like a 
doctor, a lawyer, etc. running his own business. But maybe this can be 
just removed, so as to be more generic.




I also don't like the limitation to nodes, these will always have a
spatial extension, so allowing to tag them on areas as well seems
reasonable.



I don't really see why, but again, I have no experience with OSM...


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] Feature Proposal - RFC - (midwife)

[David Picard]

Hi,


Le 01/08/2016 à 11:15, Martin Koppenhoefer a écrit :


2016-07-31 19:21 GMT+02:00 David Picard <dave...@yahoo.fr
<mailto:dave...@yahoo.fr>>:

https://wiki.openstreetmap.org/wiki/Proposed_features/midwife

Definition: a midwife practising as a licensed professional in
an office



I think your proposal should be more explicit about the actual tagging
you propose (key=value, possibly in bold text).


I don't understand what you mean here. I have no experience with OSM.


Also the definition
leaves a lot of uncertainty (is this a about an office or a practice, or
is this the same in this context? Is it for the place where
examinations/birth is happening or is it for an administrative place, or
both?) Is this only for standalone features, or also for midwifes
associated to a clinic or hospital?


I guess it depends a lot on the country ! For example, in France, the 
only definition is : a place where a woman can exercise and get prepared 
for childbirth, get cured for a range of gynaecological problems (from 
puberty to end of life), get prescription for contraceptives, be taken 
care of before and after childbirth. It is NOT a place to give birth. 
Midwives who run a place like this in France are not linked to a clinic 
nor hospital.



Why do you require "licensed" (think
of places where public administration works worse, maybe they don't have
official licenses for midwifes).


I am not an English speaker. I meant an independent worker like a 
doctor, a lawyer, etc. running his own business. But maybe this can be 
just removed, so as to be more generic.




I also don't like the limitation to nodes, these will always have a
spatial extension, so allowing to tag them on areas as well seems
reasonable.



I don't really see why, but again, I have no experience with OSM...


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] Feature Proposal - RFC - (midwife)

[David Picard]

https://wiki.openstreetmap.org/wiki/Proposed_features/midwife

Definition: a midwife practising as a licensed professional in an office


___
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

Re: [Tagging] State parks and state forests: specific tagging question, general mapping philosophy

[David Bannon]

On 27/07/16 12:59, Kevin Kenny wrote:
.

 How about we make a deal that when the "correct" tagging actually 
becomes visible on at least one layer of the main site, I go back and 
remove the "legacy" tagging, which can be done with a mechanical edit?
Kevin, I share your frustration but suggest that is the wrong approach. 
Image Feature A is correctly rendered but not so Feature B.  We won't 
encourage the rendering mob to render B by tagging everything as A.


Might be worth your while looking at how others are using the data, 
OsmAnd do a great job of rendering some of the detail found in the 
database. And make a pretty attractive looking map at the same time. 
There are lots of other 'consumers' of OSM data.


David


___
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] Mapping pergolas/arbors

[David Swarthout]

I would discourage the use of type as a key here as it is used to differentiate 
between relations. Suggest shelter:type or something similar. Cheers Dave

Get Outlook for iOS




On Wed, May 18, 2016 at 6:29 PM -0700, "Mark Bradley" 
 wrote:










> From: Martin Koppenhoefer 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] Mapping pergolas/arbors
> >
> > I know of some pergolas I would like to map.  (Wikipedia says other
> > words for these features are "arbors" and "arbours.")  Looking on the
> > wiki on the list of map features, there doesn't appear to be any
> > established tags for these features, so I'm asking for suggestions
> > before I make up my own.
> 
> 
> maybe the key "building" could be used, values could be "pergola" or "arbour" 
> (BE
> spelling). This is about a frame on which plants are intended to grow for 
> shade, right?
> 
> 
> cheers,
> Martin
 
 
Yes Martin, you're correct.

Based on the discussion here, I will plan to go with amenity=shelter, followed 
by type=pergola.

Mark Bradley



___
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 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

Re: [Tagging] Proposal to Change Road Classification, Road Surface, Road Condition, and Add Number of Lanes

[David Bannon]

Wow Alberto, you have put a lot of thought into this. I agree its needed 
and think the model would serve us a lot better than the way its done 
now. But I see a couple of problems, first, we have a huge data set 
using the existing model. Very hard to change that. Secondly, I suspect 
not all contributers to OSM are familiar with the sort of roads that 
have prompted your proposal. So, wide spread support may be a bit hard 
to find.


But I'd be the last to suggest you give up something just because its 
impossible !


So, lets pick it over.

Firstly, maybe your categories might need to be a bit finer grained.  
For example, the jump, in Rural, 3 Tertiary and 4 Unclassified is too 
big. I live on a rural road, its not a connecting road and it is owned 
and maintained (occasionally) by the Municipality.  So its definitely a 
public access road but not one a routing engine should consider (except 
start and end stages of course). Such roads are very common.


I am not sure I like the classification you use for C Road Condition. It 
seems a bit too focused on maintenance models rather than providing an 
indication of how a traveler might find it. I suggest what a map (or 
whatever) user wants to know is "should I use this road ?". And that, of 
course, is dependent on vehicle, maybe affected by weather, maintenance 
cycles and so on.


Alberto, I'd like to see this model refined, lets make out that we are 
starting fresh, get it right and then look to see if some of the result 
can be incorporated into the current model, or even a long term transition ?


David

On 06/03/16 01:25, Alberto wrote:


Dear OSM staff, contributors, and users:

I have read the definitions, concepts and description that OSM uses to 
characterize (tag) roads and noticed that OSM does not establish the 
difference between inter-urban (rural) roads and urban roads 
(comprising mostly avenues and streets). Therefore, I propose to 
*replace the existing OSM road classification with a "functional 
classification"* that would allow OSM *"to better model and better 
visualize"* the actual road network. I have noticed that you have been 
challenged to adapt to the differences found in each country. If the 
following classification is adopted, it will be a "*universal 
standard*" and you will not need to adopt different criteria for 
developed or developing countries, like the OSM example for East Africa.


It would be useful to define a road class (paved/unpaved) and a road 
surface type (concrete, asphalt, surface treatment, gravel, earth). I 
also propose to reduce the options for road condition to only five 
categories defined by the need for maintenance or rehabilitation. I 
can provide a technical definition using the International Roughness 
Index (IRI) for paved and unpaved roads.



I am fully aware that these changes present a major challenge for the 
existing, coding, renderer, editors, etc. However, I am confident that 
introducing these changes (and adding the number of lanes) will not 
only simplify the mapping tasks, but would substantially improve the 
quality of the OMS products, particularly given the fact that many 
other layers are highly dependent on the quality of the road network.



I am a Civil Engineer (MS Stanford) with training on urban planning 
(MIT) with more than 20 years of experience working with international 
organizations like the World Bank and the African Development Bank on 
roads and highways in more than 50 countries, but mostly in 
Sub-Saharan Africa, South America, South Asia, East Asia and the 
Pacific, and Eastern Europe.


Alberto Nogales

202-257-8726


*A. FUNCTIONAL ROAD CLASSIFICATION for "Motor Vehicles":*

*
*

*Rural (Inter-Urban) Roads - Located outside of urban areas*

*Classified Road Network. *Generally falls under the responsibility of 
the National, Provincial (State), Municipal/Local Government to build, 
operate and maintain.


*1.* *Primary* Roads - National, Main, Trunk Roads outside of
urban areas that connect the main population and economic centers
of the country. Typically under the responsibility of the National
Government and with high levels of traffic.

*2.* *Secondary* Roads - Regional, State, Provincial Roads are the
main feeder routes into, and provide the main links between
primary roads. Typically under the responsibility of the
Provincial Government and with medium levels of traffic.

*3.* *Tertiary* Roads - Municipal, Local, Rural Roads that connect
the smaller towns to intermediate cities. Typically under the
responsibility of the Local Governments and with low levels of
traffic.

*Unclassified Road Network.*

*4. Unclassified* Roads. Mostly private roads or of unknown
responsibility to build and operate. Typically maintained by local
communities or by private mining, forestry, or agricultural
enterprises.

*Urban Network- Located within the

[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] Tagging scrapyards, junkyards

[David Swarthout]

As always, these linguistic preferences color every discussion. I use the word 
junkyard as do most Americans but I settled on scrapyard as a reasonable 
compromise but YMMV. these conversations tend to go round and round and I am 
satisfied with what I have. 
Sent from Outlook Mobile




On Thu, Jan 21, 2016 at 9:49 AM -0800, "Colin Smale"  
wrote:













What is your linguistic frame of reference?


In the UK, the word "junkyard" is not used often and I would go to a 
"scrapyard" (or even more likely a "breakers [yard]") for a "new" window for my 
old car.
 


Far better to use longer, more descriptive words/phrases which are less likely 
to lead to major differences in interpretation across the entire world, 
English-speaking and otherwise. We shouldn't be wasting energy arguing about 
whether to call an object a rubbish bin or a trash can. We could always call it 
a "wibble" so there are no winners, only losers, and everyone has to use a 
lookup table


//colin


On 2016-01-21 18:22, EthnicFood IsGreat wrote:


Date: Thu, 21 Jan 2016 06:12:23 +0700
 From: Dave Swarthout 
 To: "Tag discussion, strategy and related tools"
 
 Subject: Re: [Tagging] Tagging scrap yards, junkyards

 A waste transfer station is a different operation from this one, which is a
 place to store used parts for the long-term until someone buys them. The
 things stored therein are not waste but resellable parts. If I want a
 tail-light lens for a 1975 Ford, for example, the best place, often the
 only place, to get it would be at a junkyard/scrapyard.

 Thanks for the input. I've got some good ideas now. I now agree that adding
 the tags for shop=car_parts and second_hand=only would help describe this
 particular type of scrapyard quite nicely.

 Cheers,
 Dave


 I thought scrapyards and junkyards were two different entities.  This
 is how I think of them.

 Scrapyards are places whose primary purpose is to buy items that are
 no longer wanted (typically metal objects) and then sell them for the
 value of their raw materials.  Junkyards are places whose primary
 purpose is to sell intact vehicle parts from wrecks to people who are
 repairing a vehicle.  Definitely not the same thing.

 ___
 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] 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 Earl]

On Wed, 11 Nov 2015 at 14:01 Richard Welty  wrote:

> it's an inevitable consequence of serializing a complex data structure.
> we either find ways to deal with it or else we accept limits on what
> we can accomplish.
>

Or we change the way we do it.

For example, emitting the relations first would help somewhat.

Maybe thinking about the structure further rather than using relations
because they are there.

Or make it easier to cope by providing much easier and less resource hungry
means of managing this

and/or a higher level api which abstracts some of the change and provides a
better level of backward compatibility, at least for extending time. So for
example "tell me what the road number(s) of this way are" irrespective of
how they are stored, and "is this way the same as that one in respect of
road number X"? and so on.

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

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

[David Earl]

I can see the attraction of this, but I do always worry about gross lack of
backward compatibility being a huge barrier to adoption. If you have to
scramble to keep up with changes like this whenever they happen, you aren't
going to be keen to be a consumer of OSM data when it's only peripheral to
what you're trying to do. I hear all the arguments about being able to move
forward and so on, but if you can't keep the customers, there's no point.

Also relations are a massively bigger burden on a consumer. Every time you
get one you've got to do a look up in a potentially HUGE mass of other
data, so it probably has to be done via a database rather than in memory.
Getting the information you need becomes orders of magnitude slower for
every object.

It also doesn't help that relations appear last in the OSM data, so you
can't even note the relations as you go and then look them up as you see
ways etc. You have to process the lot first and then go back and to the
original task. Again it pretty much mandates a huge database for anything
other than a small area.

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

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

[David Earl]

Having been negative, now the opposite...

Why stop at ref?

There are lots of places where it would help to group things uniquely
rather than by a simple text string. Names are the obvious next one. If we
put the names on a separate shared object, you can then tell when they are
actually the same street, or whatever, rather than just a coincidence.
There are two entirely separate Love Lane in Cambridge, for example, and
many High Street all over the place. How do you know they are the same,
especially if they don't all interconnect, or conversely they do, but are
actually different.

Also you could deal with the case of things which have different names
rather than the bodges we have at present. For example, where a street has
different names on opposites sides which are rare, but do exist. Or where
you have a part of a street known by the name of its terrace of houses on
one section, but where the street is really continuous. Or a bridge has its
own name but the street with a name continues across it. And that's even
without starting on different languages.

Which then begs the question: why not do all or most of the tags this way?
Share tags between multiple objects as a matter of course when those
objects collectively represent one thing. And different but overlapping
subsets of objects represent different things. Then maybe say if we're
doing it this way some of the time, why not do it all of the time, even for
single objects, just for consistency.

In which case, are relations just in the picture because they happen to
provide a crude mechanism for this which already exists? If all tags were
done this way might we get to a point where we are representing real world
objects as a whole rather than trying to infer it from groups of tags which
happen to be similar and are split up purely for convenience of managing
other things like bus routes or bridges which run along part of the real
object.

David

On Wed, 11 Nov 2015 at 12:37 David Earl <da...@frankieandshadow.com> wrote:

> I can see the attraction of this, but I do always worry about gross lack
> of backward compatibility being a huge barrier to adoption. If you have to
> scramble to keep up with changes like this whenever they happen, you aren't
> going to be keen to be a consumer of OSM data when it's only peripheral to
> what you're trying to do. I hear all the arguments about being able to move
> forward and so on, but if you can't keep the customers, there's no point.
>
> Also relations are a massively bigger burden on a consumer. Every time you
> get one you've got to do a look up in a potentially HUGE mass of other
> data, so it probably has to be done via a database rather than in memory.
> Getting the information you need becomes orders of magnitude slower for
> every object.
>
> It also doesn't help that relations appear last in the OSM data, so you
> can't even note the relations as you go and then look them up as you see
> ways etc. You have to process the lot first and then go back and to the
> original task. Again it pretty much mandates a huge database for anything
> other than a small area.
>
> David
>
>
___
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

[Tagging] How to tag a "Olive Oil Factory?(done)

[david]

Hello again,

Thanks a lot to Eric Gillet, John Willis, Warin Mateusz Konieczny,
Volker Schmidt, Martin Koppenhoefer for replying me. It has been really
helpful to have good practises.

Regards
David Lopez Villegas

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

[Tagging] How to tag a "Olive Oil Factory"?

[david]

Hello,

My name is David, and I'm a novel user. I find OpenStreetMap really
interesting. My user in OpenStreetMap is dlv3.

I'm sourveying my little village. I'm trying to tag a "Olive Oil
Factory"(I'm not a english speaker, ¿is this name corret? The factory
takes harvested olives, after a few process, olive oil is produced).I
have looked for the tag in the wiki. However, I only have found the
following tag "man_made,works". Is this tag enough?

Thank you in advanced
David López Villegas

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

[Tagging] How to tag a "Olive Oil Factory"?

[david]

Hello,

My name is David, and I'm a novel user. I find OpenStreetMap really
interesting. My user in OpenStreetMap is dlv3.

I'm sourveying my little village. I'm trying to tag a "Olive Oil
Factory"(I'm not a english speaker, ¿is this name corret? The factory
takes harvested olives, after a few process, olive oil is produced).I
have looked for the tag in the wiki. However, I only have found the
following tag "man_made,works". Is this tag enough?

Thank you in advanced
David López Villegas

___
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] how to tag a salt flat

[David Bannon]

On 30/09/15 21:28, Warin wrote:

..
Well if you want to have lake Eyre 'qualify' for the tag 'intermittent'
.
But if you want to see Lake Eyre full .. 'typically' that is once 
every 10 years or so...


So to me a full cycle of Lake Eyre in all its 'seasons' would be 
'typically' 10 years.
Warin, I think you will find that Lake Eyre has only 'Filled' three 
times since (white man's) records have been kept, 150 years ? Its a very 
big place, when water flows in on those ten year cycles, it just gets a 
bit damp in one small corner, you could not say thats the defining cycle 
for the whole lake.


Does 'intermittent' still apply to a 50 or 100 year cycle ? Honestly, 
the natural state of Lake Eyre is dry. And thats how we like it !


David





___
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] how to tag a salt flat

[David Bannon]

Anyway, we agree that Lake Eyre does not fill seasonally, we agree it 
does fill intermittently (but maybe disagree on "full", not important).


"seasonal" may be a good qualifier for a lake that depends on the 
seasons and responds to the season cycle most times around. But thats 
not intermittent IMHO. I don't think "intermittent" and "seasonal" go 
well together.


David

On 01/10/15 10:16, Warin wrote:

On 1/10/2015 8:49 AM, David Bannon wrote:



On 30/09/15 21:28, Warin wrote:

..
Well if you want to have lake Eyre 'qualify' for the tag 'intermittent'
.
But if you want to see Lake Eyre full .. 'typically' that is once 
every 10 years or so...


So to me a full cycle of Lake Eyre in all its 'seasons' would be 
'typically' 10 years.
Warin, I think you will find that Lake Eyre has only 'Filled' three 
times since (white man's) records have been kept, 150 years ? Its a 
very big place, when water flows in on those ten year cycles, it just 
gets a bit damp in one small corner, you could not say thats the 
defining cycle for the whole lake.


'Full' ... http://www.lakeeyrebasin.gov.au/about-basin/water States 
the 'typical' inflows ...


And the yacht club has a graph of the water depth from 1975 ... 
http://www.lakeeyreyc.com/fldhist.html




Does 'intermittent' still apply to a 50 or 100 year cycle ?


I would say YES!

I think the OSM wiki is wrong in putting the word "seasonal" as a 
qualifier to the tag intermittent!

Seasonal things should be tagged with the tag seasonal!
In fact I'll be brave and remove the  word! It was looks to be added 
by Chrabros <http://wiki.openstreetmap.org/wiki/User:Chrabros>  in 
April 2014..
So I have removed the word seasonal from the meaning of intermittent 
and added a 'common mistakes' section for seasonal things...

And added my comments to its discussion page.

Honestly, the natural state of Lake Eyre is dry. And thats how we 
like it !



Naturally! With the occasional damp bit, and then the rarer wet bit.


___
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] 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