from:"Brian M. Sperlongano"

Hello,

On Sun, Dec 18, 2022 at 6:08 PM Jens Glad Balchen 
wrote:

>
> There are instances that you wouldn't want to include in your router.
> E.g. https://www.openstreetmap.org/way/658000911, which is similar
> except there is no sidewalk=separate. Walking on this "sidewalk" is
> probably prohibited, because to get to it, you have to pass a sign that
> says no walking, except if you manage to cross a gated fence (at the
> southern end). The "sidewalk" is probably for some other use, possibly
> emergencies, possibly something else, possibly just a waste of space.
> I'm not a big fan of this particular tagging because it is misleading
> and confusing.
>
> I don't know how you would tell the difference, apart from the lack of
> sidewalk=separate on the carriageway.
>

The way cited here is a highway=footway, and my dataset only includes the
roadways themselves, not footway/cycleway, etc, by design and intent.

In that case, there is an adjacent highway=trunk road (
https://www.openstreetmap.org/way/68648993) which is tagged foot=no, with
no sidewalk tagging.  In this case, my job is easy - the foot=no tells me
that I should exclude that road, and since the nearby sidewalk is not
actually accessible based on your description, it sounds like it's
correctly tagged.  This case is not a problem at all.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Foot / sidewalk access tagging

Currently taking bets on how long it will take before someone actually
answers the question I posed 😂

On Sun, Dec 18, 2022 at 5:03 PM stevea  wrote:

> My understanding (in Texas, and other states) in this case (where there is
> no sidewalk and it is not legal to walk "in the roadway") is that in cases
> like these, there will always be an "easement" along at least one side of
> the road, where utilities (wired poles, perhaps underground piping...) are
> allowed, and so, too, is granted "permission of access" to pedestrians, for
> the right to walk along such easement.  This isn't quite-exactly "public
> property," as the easement remains a "strip" of private property along
> stitched-together private parcels, but by virtue of it being "an easement,"
> explicit "public access" (e.g. pedestrians walking) IS allowed through such
> an easement.  So, for example, an access=yes tag (if not already implied)
> might be appropriate to explicitly include.
>
> So, say you're in Texas, there is a roadway (and you are not allowed to
> walk in it, lest you run afoul of "pedestrian-in-roadway" ordinances) and
> there is NO sidewalk.  In this case there IS an "easement" (whether
> populated by utilities or not) where pedestrians are allowed, because
> pedestrians must be able to use the right-of-way of the road, too.  Just
> not IN the roadway, but along it.  (And if there are wired poles along one
> side, choose that side).
>
> On Dec 18, 2022, at 1:43 PM, Brian M. Sperlongano 
> wrote:
> > What I've been told (and someone showed me the law to back it up) is
> that apparently in Texas, IF there is a sidewalk, you are not allowed to
> walk in the roadway.
> >
> > On Sun, Dec 18, 2022 at 4:42 PM Ivo Reano  wrote:
> > Are you saying that in Texas you can't walk on a street that doesn't
> have a sidewalk?
> > Only in a city environment or also in a non-city environment?
> > Or in Texas if you're on foot you're going nowhere?
> > Definitely not human!
> 
> ___
> 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] Foot / sidewalk access tagging

What I've been told (and someone showed me the law to back it up) is that
apparently in Texas, IF there is a sidewalk, you are not allowed to walk in
the roadway.

On Sun, Dec 18, 2022 at 4:42 PM Ivo Reano  wrote:

> Are you saying that in Texas you can't walk on a street that doesn't have
> a sidewalk?
> Only in a city environment or also in a non-city environment?
> Or in Texas if you're on foot you're going nowhere?
> Definitely not human!
>
>
> Il giorno dom 18 dic 2022 alle ore 22:31 Brian M. Sperlongano <
> zelonew...@gmail.com> ha scritto:
>
>> Hi,
>>
>> The tagging that I cited was from Texas in the USA.  In that location, it
>> is illegal to walk in the roadway (where the cars go), but there was a
>> separate sidewalk where pedestrians are supposed to walk.  However, my
>> software works globally so I'm trying to understand how that
>> `sidewalk=separate` + `foot=no` combination should be interpreted on a
>> global basis, or if I should just ignore those combinations as a tagging
>> error.
>>
>> So the situation is:
>> 1. There is a sidewalk, and it's mapped separately
>> 2. The road is tagged sidewalk=separate + foot=no
>> 3. It's illegal to walk in the road itself because there is a sidewalk
>> (state law in that area)
>>
>> On Sun, Dec 18, 2022 at 4:22 PM Ivo Reano  wrote:
>>
>>> I don't know in your area if all pedestrians who use the streets just
>>> because they don't have a car are punished.
>>> In Italy, only motorways and some major traffic routes are formally
>>> "forbidden" to pedestrian transit.
>>> If I found a foot=yes on a street, simply to indicate that one should
>>> not walk in the middle of the street, I would delete that tag (and send a
>>> message to the user asking what he meant).
>>> It seems obvious to me that if I walk on a road I keep to the left
>>> (excuse non-Anglo-Saxons, but this is the preferred direction for
>>> pedestrians on driveways in the rest of the world).
>>> While if I'm on a road with no traffic (not flat) I mostly walk on the
>>> downhill side.
>>> In short: if there isn't a sidewalk, and the street isn't reserved for
>>> vehicles (but where do you live?) foot=no it seems absurd to me, or rather
>>> wrong.
>>>
>>> Ivo, Jrachi
>>>
>>> Il giorno dom 18 dic 2022 alle ore 22:05  ha scritto:
>>>
>>>> Yes, only if the local legislation infers that pedestrians have to use
>>>> a (usually car) road-accompanying sidewalk.
>>>>
>>>> Also, your project reminds me of wandrer.earth, where craig also
>>>> introduced a way for running to track ran ways, not only for cyclists.
>>>> Though i only use it for cycling.
>>>>
>>>> --
>>>> Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail
>>>> gesendet.
>>>> Am 18.12.22, 21:47 schrieb "Brian M. Sperlongano" >>> >:
>>>>
>>>>> Thanks Cyton.
>>>>>
>>>>> Just to be clear, I'm only talking about automobile roads -
>>>>> highway=trunk/primary/secondary/tertiary/unclassified/residential.
>>>>>
>>>>> On Sun, Dec 18, 2022 at 3:41 PM  wrote:
>>>>>
>>>>>> If and only if there is a separately mapped sidewalk.
>>>>>> Sidewalk=separate means there needs to be such a way.
>>>>>> However i would tag foot=use_sidepath, which means the same as
>>>>>> foot=no but also indicates the existence of a separate way usable for
>>>>>> routing.
>>>>>> And only if the highway is a streets centerline, not a cycleway or
>>>>>> other.
>>>>>>
>>>>>> Cyton
>>>>>> Am 18.12.22, 21:32 schrieb "Brian M. Sperlongano" <
>>>>>> zelonew...@gmail.com>:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am the author of a data consumer which generates a list of streets
>>>>>>> that are accessible to walkers and joggers. The idea is that a user 
>>>>>>> would
>>>>>>> have a map of the streets in their town and can challenge themselves to
>>>>>>> walk/jog down every street, and they can look at statistics on which
>>>>>>> streets they've completed.  I use a 25-meter

Re: [Tagging] Foot / sidewalk access tagging

Hi,

The tagging that I cited was from Texas in the USA.  In that location, it
is illegal to walk in the roadway (where the cars go), but there was a
separate sidewalk where pedestrians are supposed to walk.  However, my
software works globally so I'm trying to understand how that
`sidewalk=separate` + `foot=no` combination should be interpreted on a
global basis, or if I should just ignore those combinations as a tagging
error.

So the situation is:
1. There is a sidewalk, and it's mapped separately
2. The road is tagged sidewalk=separate + foot=no
3. It's illegal to walk in the road itself because there is a sidewalk
(state law in that area)

On Sun, Dec 18, 2022 at 4:22 PM Ivo Reano  wrote:

> I don't know in your area if all pedestrians who use the streets just
> because they don't have a car are punished.
> In Italy, only motorways and some major traffic routes are formally
> "forbidden" to pedestrian transit.
> If I found a foot=yes on a street, simply to indicate that one should not
> walk in the middle of the street, I would delete that tag (and send a
> message to the user asking what he meant).
> It seems obvious to me that if I walk on a road I keep to the left (excuse
> non-Anglo-Saxons, but this is the preferred direction for pedestrians on
> driveways in the rest of the world).
> While if I'm on a road with no traffic (not flat) I mostly walk on the
> downhill side.
> In short: if there isn't a sidewalk, and the street isn't reserved for
> vehicles (but where do you live?) foot=no it seems absurd to me, or rather
> wrong.
>
> Ivo, Jrachi
>
> Il giorno dom 18 dic 2022 alle ore 22:05  ha scritto:
>
>> Yes, only if the local legislation infers that pedestrians have to use a
>> (usually car) road-accompanying sidewalk.
>>
>> Also, your project reminds me of wandrer.earth, where craig also
>> introduced a way for running to track ran ways, not only for cyclists.
>> Though i only use it for cycling.
>>
>> --
>> Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail
>> gesendet.
>> Am 18.12.22, 21:47 schrieb "Brian M. Sperlongano" :
>>
>>> Thanks Cyton.
>>>
>>> Just to be clear, I'm only talking about automobile roads -
>>> highway=trunk/primary/secondary/tertiary/unclassified/residential.
>>>
>>> On Sun, Dec 18, 2022 at 3:41 PM  wrote:
>>>
>>>> If and only if there is a separately mapped sidewalk.
>>>> Sidewalk=separate means there needs to be such a way.
>>>> However i would tag foot=use_sidepath, which means the same as foot=no
>>>> but also indicates the existence of a separate way usable for routing.
>>>> And only if the highway is a streets centerline, not a cycleway or
>>>> other.
>>>>
>>>> Cyton
>>>> Am 18.12.22, 21:32 schrieb "Brian M. Sperlongano" :
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> I am the author of a data consumer which generates a list of streets
>>>>> that are accessible to walkers and joggers. The idea is that a user would
>>>>> have a map of the streets in their town and can challenge themselves to
>>>>> walk/jog down every street, and they can look at statistics on which
>>>>> streets they've completed.  I use a 25-meter rule, so if a user can walk
>>>>> along the shoulder, or on a sidewalk/pavement, or in the verge, that's
>>>>> acceptable.
>>>>>
>>>>> I recently came across an unexpected tagging combination and I would
>>>>> like to understand how folks in various places would interpret this:
>>>>>
>>>>> highway=
>>>>> foot=no
>>>>> sidewalk=separate
>>>>>
>>>>> In my software's logic, I've made the assumption that foot=* applies
>>>>> to "the whole of the road" including the roadway, shoulders, verge,
>>>>> sidewalks, and so forth and thus excluded any roads that include that tag,
>>>>> regardless of other tagging. I came to understand that this tagging was
>>>>> used by a mapper to indicate that "pedestrians are not allowed on the
>>>>> roadway, however, they are allowed on the sidewalk"
>>>>>
>>>>> Would folks regard that as accurate data modeling?  I.e. should I
>>>>> change my software to treat streets tagged in this way as
>>>>> pedestrian-accessible, or would folks regard this combinat

Re: [Tagging] Foot / sidewalk access tagging

Thanks Cyton.

Just to be clear, I'm only talking about automobile roads -
highway=trunk/primary/secondary/tertiary/unclassified/residential.

On Sun, Dec 18, 2022 at 3:41 PM  wrote:

> If and only if there is a separately mapped sidewalk.
> Sidewalk=separate means there needs to be such a way.
> However i would tag foot=use_sidepath, which means the same as foot=no but
> also indicates the existence of a separate way usable for routing.
> And only if the highway is a streets centerline, not a cycleway or other.
>
> Cyton
> Am 18.12.22, 21:32 schrieb "Brian M. Sperlongano" :
>
>> Hello,
>>
>> I am the author of a data consumer which generates a list of streets that
>> are accessible to walkers and joggers. The idea is that a user would have a
>> map of the streets in their town and can challenge themselves to walk/jog
>> down every street, and they can look at statistics on which streets they've
>> completed.  I use a 25-meter rule, so if a user can walk along the
>> shoulder, or on a sidewalk/pavement, or in the verge, that's acceptable.
>>
>> I recently came across an unexpected tagging combination and I would like
>> to understand how folks in various places would interpret this:
>>
>> highway=
>> foot=no
>> sidewalk=separate
>>
>> In my software's logic, I've made the assumption that foot=* applies to
>> "the whole of the road" including the roadway, shoulders, verge, sidewalks,
>> and so forth and thus excluded any roads that include that tag, regardless
>> of other tagging. I came to understand that this tagging was used by a
>> mapper to indicate that "pedestrians are not allowed on the roadway,
>> however, they are allowed on the sidewalk"
>>
>> Would folks regard that as accurate data modeling?  I.e. should I change
>> my software to treat streets tagged in this way as pedestrian-accessible,
>> or would folks regard this combination as a tagging error?
>>
>>
>> ___ 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] Foot / sidewalk access tagging

Hello,

I am the author of a data consumer which generates a list of streets that
are accessible to walkers and joggers. The idea is that a user would have a
map of the streets in their town and can challenge themselves to walk/jog
down every street, and they can look at statistics on which streets they've
completed.  I use a 25-meter rule, so if a user can walk along the
shoulder, or on a sidewalk/pavement, or in the verge, that's acceptable.

I recently came across an unexpected tagging combination and I would like
to understand how folks in various places would interpret this:

highway=
foot=no
sidewalk=separate

In my software's logic, I've made the assumption that foot=* applies to
"the whole of the road" including the roadway, shoulders, verge, sidewalks,
and so forth and thus excluded any roads that include that tag, regardless
of other tagging. I came to understand that this tagging was used by a
mapper to indicate that "pedestrians are not allowed on the roadway,
however, they are allowed on the sidewalk"

Would folks regard that as accurate data modeling?  I.e. should I change my
software to treat streets tagged in this way as pedestrian-accessible, or
would folks regard this combination as a tagging error?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re-opening of historic=* key vote without community notification

2022-11-15 Thread Brian M. Sperlongano

On Tue, Nov 15, 2022 at 6:22 AM Włodzimierz Bartczak <
wlodzimierz.bartc...@openstreetmap.pl> wrote:

> That's right it's an oversight. I was a bit hasty. First of all, I wanted
> to start a discussion. It would be worthwhile to sort out the use of this
> key. Everyone is complaining about this proposal no one wants to put it in
> order. Maybe we should do it together as a community.
>

I'm happy to help start that discussion.

First, it needs to be clarified what problem the authors are trying to
solve with this proposal.  The proposal needs a clear, plainly-stated
purpose and rationale to understand what is being voted on and why the
status quo isn't good enough.

Beyond that, there are several long-standing issues with the historic=*
key.  Over the years, there has been a debate over what counts as
"historic".  Some community members have suggested that features which are
"merely old" are not necessarily historic and that perhaps a heritage
organization or government's recognition is required to meet that threshold.

Additionally, Sarah Hoffman has previously pointed out some structural
issues with the use of historic as a top-level key sometimes and an
ancillary key other times:
https://lists.openstreetmap.org/pipermail/tagging/2022-November/066294.html

I think, at a minimum, these three points should be addressed by the
proposal authors before moving forward.  They are certainly blockers for my
support.  Consider this an opportunity to dig into the issues with this key
and work with the community to find where the consensus may lie.  Do not
rush to declare a vote until the issues raised by the community have been
adequately addressed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Re-opening of historic=* key vote without community notification

2022-11-14 Thread Brian M. Sperlongano

It has come to my attention that the "historic" proposal has apparently
been re-opened for a vote without even a courtesy message to the tagging
mailing list.  Thank you to user Mnalis to noticing this and alerting
several community members that have previously commented on the proposal.

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

I'm assuming this was merely an oversight, and so I wish to bring it to the
community's attention.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

2022-11-14 Thread Brian M. Sperlongano

On Mon, Nov 14, 2022 at 2:49 AM Marc_marc  wrote:

> We can see it with the osm-fr experience: the immature forum has split
> the community, far from federating
>

Thank you for clearly describing the root cause of your objection.

In my opinion, it is better to let people decide for themselves where they
wish to communicate.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

2022-11-13 Thread Brian M. Sperlongano

You're using the wrong metric.  The standard for a proposal, which purports
to change tagging standards that affect *the entire community*, should be
to advertise it as widely as possible.  With the new forums picking up
interest and activity, it is entirely appropriate to say to a proposer
"...and please also post a notice on the forum" to ensure maximum
visibility and participation.  The new forums are attracting a global
audience, rather than the few regional enclaves hosted on the old forums.
And, with the new forum linked to your osm.org user account, it's neatly
tied into the existing OSM infrastructure and doesn't require special
software or accounts to access.

I don't view this as a "first step towards moving to the forums" that the
proposal author probably does -- I view it as a recognition that the forum
has attracted enough interest and maturity in its short existence that it's
appropriate to demand to proposal authors that they also make an
announcement post there.  Now, over time, if we find that interest has
waned in the new forums, or on the flip side, if the forums come to largely
supplant the mailing lists, we can easily make the decision later to
eliminate the cross-posting requirement and pick a winner if and when this
occurs.

On Sun, Nov 13, 2022 at 5:25 PM Graeme Fitzpatrick 
wrote:

>
> On Mon, 14 Nov 2022 at 01:07, Cartographer10 via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> I hope that the current proposal will for everybody.
>>
>
> It possibly will be one day, but at the moment, no, I don't think that
> we're yet ready to say "You *have* to post there".
>
> I recently started a discussion to clarify some points on existing tags,
> before going into a full RFC / Proposal concerning them.
>
> Posted the same original message, then two further follow-up questions,
> here on Tagging, in Discourse & on the talk page of the three pages
> concerned.
>
> So far, there have been 23 responses to Tagging, the original message
> received one "like" in Discourse, & there's been a single response on one
> of the 3 talk pages.
>
> Possibly the subject under discussion is of no interest to the majority of
> people?, but those results would suggest that, so far, Tagging is still the
> most active site?
>
> Thanks
>
> Graeme
>
> PS & I should add that I am finding the Community site to be quite good,
> although there are still a number of hiccups that need fixing.
> ___
> 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 - Start moving proposal announcements to the new forum

2022-11-13 Thread Brian M. Sperlongano

I support the idea that proposals be posted to both the mailing list and
the community forums.  Over time we can assess whether one or the other is
better.

One thing I think is missing is that I would like to see proposals posted
to a dedicated space in the forums that can be subscribed to, that way
someone can subscribe to new proposal announcements without having to wade
through general tagging discussions.  Has there been any thought to
creating a dedicated proposal space, or is there otherwise some
functionality that would allow someone to subscribe just to proposal
announcements?

On Sun, Nov 13, 2022 at 10:07 AM Cartographer10 via Tagging <
tagging@openstreetmap.org> wrote:

> I didn't receive any feedback on my updated proposal. If you have any,
> please share it here. I hope that the current proposal will for everybody.
>
> Kind regards,
>
> Vincent
>
>
>
> 6 nov. 2022 09:03 van
> tagging_at_openstreetmap_org_seblajk...@simplelogin.co:
>
> I have updated the proposal a few days back which I would like to receive
> feedback on.
>
> I removed the transition period and required both the forum and the ML to
> be notified of a new proposal or vote. One exception I propose is that the
> proposal should be allowed to be made on behalf of the proposal author on
> either the ML or the forum.
>
> I hope that this change will satisfy both sides
>
> Vincent
>
>
> 29 okt. 2022 09:34 van
> tagging_at_openstreetmap_org_seblajk...@simplelogin.co:
>
> Hello everybody,
>
> Based on the feedback, I updated the proposal to start using the new forum
> for proposal announcements.
>
> Please discuss this proposal on its Wiki Talk page.
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Start_moving_proposal_announcements_to_the_new_forum
>
>
> Kind regards,
> Vincent
>
>
>
> ___
> 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] Easy way to find proposals [was: Healthcare]

2022-11-06 Thread Brian M. Sperlongano

You should bookmark this site to keep track of proposals:

https://osm-proposals.push-f.com/

Ideally this should probably be linked to more places.

On Sun, Nov 6, 2022 at 7:31 AM ael via Tagging 
wrote:

> A very general comment:-
>
> I very seldom consider voting on proposals, but I did want to look over
> this one.
>
> However, when I logged into the wiki, there seemed to be no easy way
> to find current proposals nor to identify those with active voting.
> Perhaps if I had kept a copy of the initial messages in this thread,
> I would have found an URI.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Proposal process [was: healthcare]

2022-11-05 Thread Brian M. Sperlongano

On Sat, Nov 5, 2022 at 6:45 PM Robin Burek  wrote:

> And if we now get to the point of just "throwing away" the consensus of 12
> years ago.
>

> do we still need the proposal process at all? Because the result from 12
> years ago is also completely ignored by you.
>

it was already decided to deprecate in 2010, but no one has finally
> implemented it.
>

What you are discovering firsthand, are the limits of the proposal system.
Indeed I encountered the same challenges. A proposal compels nobody to do
anything. A proposal is nothing more than a communication tool to
demonstrate support for an idea to other players in the community. It's a
signal to other parts of the ecosystem. In other words, if the participants
thought something was a good idea a decade ago, but the rest of the
community (mappers, renderers, editors, data consumers) didn't adopt the
change, in reality, then the persuasive value of that approved proposal
from 12 years ago has faded significantly.

In this community, we seem to be moving further and further into a system
> where improvements to the system are massively prevented and established
> double tagging is simply left in place instead of finally being cleaned up.
>

I don't agree this has "moved" at all!  The project has always operated
this way.  Eliminating duplicate tagging that has been supplanted by a
newer approved tag is obscenely difficult. I led an effort to resolve
duplicate river area tagging to 99% completion[1]. which was also a change
that was the subject of an approved 2010 proposal. Despite the approved
proposal, it was still controversial, with some community members
disagreeing about exactly what was approved due to how the proposal was
worded and debating whether the old approval was still valid or even a
good idea.

The river project accomplished its goal because enough mappers cared about
it to have community discussions about river tagging in countries
worldwide.  They reached out across many channels to discuss the proposed
changes and the value it brought. And even with that, some people
disagreed, and we had some rough spots early on in the process. The
retagging was followed up with proposals and PRs to change software support
across the project's tooling to drop the old tag.

I was the biggest advocate for the change, but it only happened because I
was met with strong agreement.  Building consensus is hard.  I had to write
really clear and persuasive documentation.  I had to discuss the specifics
of river tagging with many many people.  Those people talked to other
people.  Other mappers generated statistics, procedures, and visualizations
of our progress.  At one point, I even gave a "Mappy Hour" talk[2] on the
project.

If that sounds like a lot of work -- it was!  And just for a single tag!
But THAT is the scope and scale of effort that it's going to take to change
tagging that has tens to hundreds of thousands of objects tagged.  You need
overwhelming agreement AND enough support from motivated community members
to make all the pieces of the ground game come together.  Is this an
indication that our community is dysfunctional?  Maybe.  But it's 100% the
reality that we live in if you want to accomplish wide-ranging change.

This, by the way, is one reason why certain companies refuse to use OSM
> data. The data structure is unnecessarily inflated and complicated by such
> duplications. If we don't stick to our own conventions and enforce
> consensus, perhaps the consensus process should be abolished altogether?
>

This point would be much stronger if you could point to a specific company
that refused to use OSM data. I've asked for concrete examples about why
our free-for-all is a problem, but I always seem to get hand-waving instead
about the general benefits of standardization[3], which is the reason I've
submitted a question to the candidates in the OSMF election to see where
they stand on it[4].  While I don't like duplicate tagging, I have so far
not seen a convincing argument that it's particularly troublesome, and this
is speaking as someone that's built and operates a service that uses OSM
data.

If you want to propose tagging for something that's never been mapped
before, a proposal is a great way to ensure that the tag you're making up
is reasonable.  If you want to make a change of significant scope and scale
to tagging on the project, you must understand that a proposal is only a
single tool to generate support for your idea, which must be part of a
broader effort towards consensus-building and community action.

[1]
https://wiki.openstreetmap.org/wiki/WikiProject_Waterways/River_modernization

[2] https://www.youtube.com/watch?v=c5YwXDKGr2Y
[3]
https://lists.openstreetmap.org/pipermail/tagging/2022-October/066238.html
[4]
https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM2022/Election_to_Board#Question:_Tagging_Standards
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.op

Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1

2022-11-05 Thread Brian M. Sperlongano

On Sat, Nov 5, 2022 at 5:55 PM Robin Burek  wrote:

> What kind of reversal of guilt is that? If someone does not participate in
> the RFC. And it has been discussed both here and in the new forum. Even
> constructive support, which I have received and not a little.
> I have yet to talk to anyone who didn't think it was right to finally
> enforce the 2010 consensus. So am I supposed to keep looking here until
> someone eventually comes around? Sorry, but I cannot accept this attack
> against me. If there have been major changes, I understand that
> reminders/updates are sent. But not for this simple issue.
>

"It was discussed here" = a single response where Mateusz said he thought
it was premature. If a consensus developed separately, by all means bring
it to light here. My brief scan of the community forums doesn't seem to
show an obvious consensus that has developed, as the proposal vote appears
to be showing. The sole link to discussion in the proposal goes only to a
single German-language thread on the forum. While this proposal may be
obvious to you, consider what a contributor reading the proposal for the
first time might take away.

If you think I am poking a finger at you, I'm sorry, but I've put
significant work into the proposals I've done in the past, and I'd
encourage you to consider constructively whether what you have written
makes a strong case for what you're trying to do.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1

2022-11-05 Thread Brian M. Sperlongano

It is the responsibility of the proposer to ensure that there is a
consensus before moving to a vote, regardless of timelines. It seems to me
that there has been a recent plague of proposals where proposal writers are
tossing proposals into voting status without doing enough due diligence.
If you are not getting much feedback on your proposal, sending a reminder
is appropriate. It is never "too late" for someone to express an opinion.

The lack of immediate opposition is not an indicator of consensus.

On Sat, Nov 5, 2022 at 5:42 PM Robin Burek  wrote:

> Sorry, but this comes a bit too late. The RFC has been running for a
> month! Contentwise only different "old" designations were added there.
>
> It is also not changed to a "new key". There is also nothing "new". Only
> the old Healthcare Proposal from 2010 (!) is finally enforced (so much for
> "without justification"). I think we should finally accept and enforce the
> solutions that have been agreed upon. Or deprecate the old consensus! But I
> have decided for the first.
>
>
>
>
> "Joseph Eisenberg" joseph.eisenb...@gmail.com – 5. November 2022 22:31
>
>
> This proposal attempts to deprecate very popular tags without
> justification.
>
> The tags amenity=hospital, amenity=clinic and amenity=dentist are
> extremely well established and used by all kinds of maps and applications
> of Openstreetmap data.
>
> These features are also clearly amenities: they are an important service
> that you want to have nearby in your town, and all residents and visitors
> will need to know the location of the closest hospital or dentist to get
> medical services.
>
> There is no benefit to changing to a different key, but there is a great
> difficulty in re-tagging and changing applications.
>
> This proposal should be rejected.
>
>
> - Joseph Eisenberg
>
>
>
>
> On Sat, Nov 5, 2022 at 1:49 PM Robin Burek  > wrote:
>
>
>
> Voting has started for Healthcare 1.1 -
> https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_1.1
>
> ___
> 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 - historic

2022-11-04 Thread Brian M. Sperlongano

I'll offer a well-known example from my country:

https://en.wikipedia.org/wiki/Welcome_to_Fabulous_Las_Vegas_sign

It's on the US National Register of Historic Places which should qualify it
as a historic sign.  Although I suppose those in Europe would just consider
the sign to be a little old.

On Fri, Nov 4, 2022 at 11:56 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> https://en.wikipedia.org/wiki/White_Post_Historic_District
>
>
> Nov 4, 2022, 16:38 by annekadis...@web.de:
>
> I wasn't aware bicycle parking and sign posts are considered historic now.
> :P
> On 04/11/2022 15:33, Mateusz Konieczny via Tagging wrote:
>
>
>
>
> Nov 4, 2022, 12:59 by annekadis...@web.de:
>
> I also noticed that the inscription key is used a lot where it should be
> description. I think that's the "fault" of the iD editor form for
> historic features. The inscription field only makes sense for memorials
> IMHO.
>
> I used it for graves, crosses, monuments, amenity = drinking_water,
> man_made = signpost,
>
>- amenity = bicycle_parking
>-
>- I see it also being validly used for many other objects.
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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 - Deprecate man made=drinking fountain

2022-11-04 Thread Brian M. Sperlongano

I think I understand the proposal from poking around on the links to the
different alternatives, but could you clarify, for objects currently tagged
man_made=drinking_fountain, what the range of alternative taggings would
be?  I almost wish there was a flow chart that would let the mapper of a
particular water fixture determine what to tag it.

On Fri, Nov 4, 2022 at 11:48 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Voting has started!
>
> See
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecate_man_made%3Ddrinking_fountain
> for the proposal
>
> In addition to regular vote: can you mention whether
> https://commons.wikimedia.org/wiki/File:Fontanella_Bolsena.jpg and
>
> https://commons.wikimedia.org/wiki/File:Drinking_fountain,_istituto_scolastico_Principe_di_Piemonte,_Roma,_Italia_Sep_24,_2020_01-56-27_PM.jpeg
> are drinking fountains or not when adding vote on wiki ?
>
> See also poll on
> https://community.openstreetmap.org/t/is-it-a-drinking-fountain-or-not/4128
> (login with OSM account) that I started to check whether I am
> the only person confused by classification of items here.
> ___
> 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 - historic

2022-11-03 Thread Brian M. Sperlongano

The main issue I have with this proposal is that there is a longstanding
controversy regarding the historic key.  Namely, the question of whether it
is used for things that are historic or merely old.  I don't see how a
proposal centered around this key can move forward with that fundamental
debate unaddressed.

On Thu, Nov 3, 2022, 8:56 AM Anne-Karoline Distel 
wrote:

> Thanks for pointing that out, I've closed the vote again, and will open
> again tomorrow. I don't know if that it the procedure when you correct
> an oversight on the proposal page.
>
> Anne
>
> On 03/11/2022 12:16, Daniel Capilla wrote:
> > Please,
> >
> > Check the wiki talk page of this proposal before opening the voting
> > time. Some issues are not cleared resolved.
> >
> > Thank you.
> >
> >
> > Regards,
> >
> >
> > Daniel Capilla
> >
> >
> > ___
> > 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] Tagging standards [moved from osmf-talk]

2022-10-23 Thread Brian M. Sperlongano

On Sun, Oct 23, 2022 at 10:18 AM Andy Allan  wrote:

> Can I reiterate this please - of all the things in OpenStreetMap that
> OSMF gets involved in, tagging is perhaps the thing that OSMF gets
> involved in least of all. So I think this discussion is happening in
> quite the wrong mailing list.
>

I agree.  For those of you on tagging@ and not osmf-talk@, there has been
an ongoing discussion on the topic of tagging standards.  Since those
archives are openly published, you can read the thread starting here:

https://lists.openstreetmap.org/pipermail/osmf-talk/2022-October/008416.html

Now that you're caught up, the most interesting moment in the discussion,
from my perspective, was the remarks from the former OSMF chair when he
said:

"there is a case to be made [...] for a subset of tags that are widely
agreed to and "curated". Exactly where the boundaries of that subset would
be placed would be highly debatable" [1]

Those who know me would probably be surprised to learn my position on this:
I'm not convinced this is a good idea. Discussion about tagging standards
always starts from the position that "we should have tagging standards"
without understanding the problem we're trying to solve.

I agree that there is a set of "core" tags whose meaning is so widely
understood and established that they are standard tags by usage and
convention today. For the case of these "core" tags, I'm not sure what
value we would add by labeling them "standard" and codifying their existing
meaning. They're already standard! Standardizing what's already standard
feels like a waste of time, and no doubt the community leaders that would
be involved in such a standards body might better apply their time to other
needs on the project.

Thus, it would follow that the only possible value to be added by any kind
of standardization movement is in the gray area, for tags with some
ambiguity or disagreement associated with them.  However, it would seem
that there is little appetite in this community for any authoritative
"tagging court" to settle disputes.

In my mind, the one thing that has been sorely lacking from this discussion
is a clear articulation of the problem we are trying to solve here, from
both a data producer (mapper) and data consumer (renderer etc) perspective.
I would like to understand, specifically and with real examples, what
problems people are encountering with the current tagging free-for-all.
With that context in hand, we might consider whether our lack of tagging
standardization is hurting anyone or is just a philosophical talking point
by people who think standards are a good idea.

Or, perhaps the real problems that people are encountering might be better
solved by some other approach entirely. There's no way to know unless we
clearly understand the problem we're trying to solve, and to what degree
this problem harms OSM.

[1]
https://lists.openstreetmap.org/pipermail/osmf-talk/2022-October/008464.html
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-11 Thread Brian M. Sperlongano

I appreciate the effort here, but I think it's too broad.  I would rather
have a more focused look at individual keys that considers what the tagging
alternatives are to each, and to assess whether there is duplication and/or
debates surrounding them that are worth investigating.  There is really no
profound need to "approve" the historic key as a whole.

On Tue, Oct 11, 2022 at 9:18 AM martianfreeloader <
martianfreeloa...@posteo.net> wrote:

> Hello.
>
> I’m proposing to approve the historic=* key together with a number of tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Historic
>
> historic=* is in widespread use and currently documented as de facto.
>
> Please comment wherever you feel most comfortable:
> - Here
> - On the wiki talk page
> - In the forum
>
> ___
> 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] OSM Wiki

2022-09-30 Thread Brian M. Sperlongano

On Fri, Sep 30, 2022 at 7:45 PM Graeme Fitzpatrick 
wrote:

> How about "water bubblers"? Are they also a tap?
>

Ah yes, the "bubbler".

For those that don't live in Rhode Island, or one specific part of
Wisconsin, "bubbler" is a word that we use for what's called a "water
fountain" in other parts of the US.  The history of this is that once upon
a time, the Kohler company (the one that makes faucets and so forth)
manufactured the first outdoor water fountain, and named this invention the
"bubbler".  For reasons probably lost in history, these Kohler Bubblers
were first installed in those two locations and locals there referred to
them as bubblers from thereon out.  As other manufacturers made other water
fountain fixtures, "everywhere else" just called them water fountains.

I was probably in high school before I learned what a "water fountain"
was...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Quarry lakes

2020-12-24 Thread Brian M. Sperlongano

A commenter on the reservoir proposal[1] pointed out the existence of
quarry lakes[2], which is a lake that is formed after a quarry has been dug
after a mining operation.  It was suggested that such bodies of water
should be tagged separately from other lakes with a tag such as
water=quarry.

Should quarry lakes be tagged under a separate value from water=lake?

Should quarry lakes be tagged as a subset of lake, something like
water=lake + lake=quarry?

If there is consensus that quarry lakes should be excluded from water=lake,
obviously that impacts how water=lake is defined.

Existing usages:
water=quarry_lake: 37
water=quarry: 27
water=Quarry: 18
lake=quarry: 1

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
[2] https://en.wikipedia.org/wiki/Quarry_lake
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

2020-12-24 Thread Brian M. Sperlongano

On Thu, Dec 24, 2020 at 9:00 AM Paul Allen  All of which has drifted somewhat off topic, but until we have a
> reasonable understanding of how different legislations handle
> things we don't have a good model of how we ought to go
> about mapping them (or even if we should map them).
>

I'm not sure I understand this.  It sounds like these questions are
perfectly satisfied by fee=* and access=* (and its derivatives, such as
fishing=*), not to mention related_law=* if you really want to get into it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

2020-12-23 Thread Brian M. Sperlongano

That doesn't work if the river/stream is modeled as a way only.  Also, it
assumes that every waterfall has a plunge pool - I'm not sure that's the
case.

On Thu, Dec 24, 2020, 12:25 AM Andrew Harvey 
wrote:

> Mind you, you do need any of these tags to determine that. You can
> automatically measure natural=water size where the way contains a waterfall
> node.
>
> On Thu, 24 Dec 2020, 4:14 pm Brian M. Sperlongano, 
> wrote:
>
>> I could see value in tagging them separately.  I.e. "I'd like to swim in
>> a small pool with a waterfall".
>>
>> On Thu, Dec 24, 2020, 12:10 AM Andrew Harvey 
>> wrote:
>>
>>>
>>>
>>> On Thu, 24 Dec 2020 at 10:26, Paul Allen  wrote:
>>>
>>>>
>>>> Isn't that a plunge pool?  https://en.wikipedia.org/wiki/Plunge_pool
>>>> I didn't even know plunge pools where a thing until Kevin Kenny
>>>> mentioned them.  He knows everything.
>>>>
>>>
>>> Probably, but per wikipedia (again I'm no expert on this) "Plunge pools,
>>> or plunge basins, are stream pools formed by the action of waterfalls", so
>>> plunge pools are just a specific type of stream pool, When I originally
>>> documented stream_pool on the wiki after the mailing list discussion the
>>> intent was that plunge pools would be tagged as water=stream_pool.
>>> ___
>>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

2020-12-23 Thread Brian M. Sperlongano

I could see value in tagging them separately.  I.e. "I'd like to swim in a
small pool with a waterfall".

On Thu, Dec 24, 2020, 12:10 AM Andrew Harvey 
wrote:

>
>
> On Thu, 24 Dec 2020 at 10:26, Paul Allen  wrote:
>
>>
>> Isn't that a plunge pool?  https://en.wikipedia.org/wiki/Plunge_pool
>> I didn't even know plunge pools where a thing until Kevin Kenny
>> mentioned them.  He knows everything.
>>
>
> Probably, but per wikipedia (again I'm no expert on this) "Plunge pools,
> or plunge basins, are stream pools formed by the action of waterfalls", so
> plunge pools are just a specific type of stream pool, When I originally
> documented stream_pool on the wiki after the mailing list discussion the
> intent was that plunge pools would be tagged as water=stream_pool.
> ___
> 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] Definition of lake/pond as applied to stream/plunge pools

> I think you need to expand a little on how to "conflate" a pool with a
> river.  The
> disadvantage of doing so is that the pool then cannot have a name assigned.
>

Sorry, my words were not clear enough here.  By "conflate" I mean that the
pool would simply be part of the river polygon.  See this example near
Boston:
https://www.openstreetmap.org/way/91082432#map=16/42.2615/-71.2764

Note that I explicitly included the phrase "if they are named or
significant in size" to cover the case where a stream pool has a name.  My
intent is to craft the definition in such a way that it allows either
scheme without preference (i.e. part of the river polygon, or a separate
pond/lake polygon with a name).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

Would this work for addressing schemes that use a hyphenated prefix?

In Hawaii, addresses outside of the city of Honolulu use a two-digit prefix
in addresses to determine which sector of the island an address is
located.  So an address might be something like "99-123 Kamehameha
Highway".  Would this scheme work for an apartment complex that's addressed
something like 99-100 through 99-200 ?

On Mon, Dec 21, 2020 at 1:15 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I like this new tag.
>
> I had proposing something like that on my TODO list.
>
> I added it in https://www.openstreetmap.org/changeset/96211869
> 
> to mark addr:housenumber=1-3 as a single address, not a range
> (based on survey that I remember well)
>
> Dec 21, 2020, 19:05 by tagging@openstreetmap.org:
>
> Okay. In this case I can rename to proposal page to "addr:range".
>
> This new tag:
>
> - applies to nodes and closed ways that have addr:housenumber
> - "addr:range=n" means every nth house is counted in a range
> - "addr:range=even/odd" means every even/odd house is counted
> - "addr:range=all" means every house is counted (default value for a
> housenumber tag with a hyphen in it if no range is given).
> - "addr:range=no" means that the housenumber tag is NOT a range of values
> but rather a single housenumber.
>
> "addr:range=all" is the default because that is what the wiki says and
> what software like streetcomplete suggests. Many buildings with multiple
> housenumbers are tagged like this.
>
> However, software can create different defaults for different countries.
> For example, in the UK a hypenated address most probably means a range of
> even/odd addresses (so "addr:range=2")
>
> What are your thoughts on this?
>
> Also, I had linked the talk-gb thread, which discusses how
> addr:interpolation on closed ways and nodes is already standard. That is
> the problem with suggesting a new tag. This proposal would now require
> informing multiple mappers to switch up the taggong scheme.
>
> Thanks,
> IpswichMapper
>
> --
>
>
> 21 Dec 2020, 15:19 by lon...@denofr.de:
>
> On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging
> wrote:
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
>
> Quick proposal I just created to accept this form of tagging. This follows
> from a discussion on the Talk-GB mailing list.
>
> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
>
>
> Please comment if there are issues with accepting this form of tagging.
>
>
> I dislike this kind of tagging to the point that I've refused to
> support it in Nominatim in the past. See
> https://github.com/osm-search/Nominatim/issues/565 for the full
> disucssion.
>
> The problem is that it makes the interpretation of addr:housenumber and
> addr:interpolation dependent on the presence of another tag.
>
> Note that addr:housenumber=40-48 can be a valid housenumber. Example:
> https://www.openstreetmap.org/way/285077586 So to know if the tag needs
> to be interpreted as a single housenumber or as a housenumber range
> you need to check if the node/way has a addr:interpolation tag in addtion
> to the addr:housenumber tag.
>
> Similarly, a way with addr:interpolation needs to be processed in two
> different ways: If a addr:housenumber is present, then assume it's a
> building and parse the addr:housenumber tag to get the range. If no
> housenumber is on the way, assume it is a good old interpolation line
> and look at the housenumbers along the nodes of the way.
>
> I find this kind of double meaning for tagging confusing and error-prone.
> But I might be fighting wind mills here.
>
> Sarah
>
>
> ___
> 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] Definition of lake/pond as applied to stream/plunge pools

Discussion on the current reservoir proposal[1] (which seeks to define the
distinction between reservoirs, lakes, and ponds) has brought up the
question of stream/plunge pools[2,3], and how they fit into the lake/pond
definitions.

I've come up with the following text:

"Occasionally a river or stream will form a stream pool or plunge pool,
which are bodies of water that naturally occur along the course of the
waterway. These waterbodies may either be tagged as a lake or (usually)
pond if they are named or significant in size, or else they can be simply
conflated with the river."

Is this distinction satisfactory?  How are folks tagging these features?


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
[2] https://en.wikipedia.org/wiki/Stream_pool
[3] https://en.wikipedia.org/wiki/Plunge_pool
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fuzzy areas again: should we have them or not?

On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm  wrote:

> Our current data model is not suitable for mapping fuzzy areas. We can
> only do "precise". Also, as you correctly pointed out, or basic tenet of
> verifiability doesn't work well with fuzzy data.
>

The current data model works just fine for fuzzy areas: it requires a
polygon combined with tagging that indicates that the area is "fuzzy".
Since the current data model allows both polygons and tags, fuzzy areas
could be mapped just fine from a technical standpoint.

So the one questions is, do we want fuzzy areas, the other is, if we
> want them, how can they be established - because in our current database
> they cannot.
>
> I think fuzzy areas make a lot of sense for cartography, but I strongly
> object to people adding hand-wavy polygons to OSM for fuzzy areas.
>

"Whether we want fuzzy areas" and "how they can be established" is
certainly an open question that requires additional intellectual thought
and consensus-building to achieve.  However, the statement that they
"cannot" be established in our database is simply an opinion, not a
technical barrier.

> Having a nice lettering across the Alps is certainly not a "higher goal"
> for OSM as a whole; forcing fuzzy polygons for that into OSM is
> irrelevant for most and outright damaging for some use cases, and the
> advantage it would have for the one single use case of map rendering
> does not justify it.
>

There are lots of things mapped in OSM that I don't care about.  For
example, I don't care about building outlines.  However, there are lots of
people that do care about building outlines and so they get mapped.  The
fact that I don't care about building outlines is not a good argument for
preventing others from mapping building outlines.  Likewise, the fact that
some don't care about fuzzy areas is an irrelevant argument to those that
wish to have them.

The statement that fuzzy polygons is "damaging" is an argument not based in
fact.  It is not damaging to me to have building outlines, which I do not
care about.  I can simply ignore them.  Likewise, fuzzy areas cause no
damage to people that do not care about fuzzy areas, provided that there is
tagging that distinguishes them from non-fuzzy areas.

> Please stop trying to frame this as "cartographers have a right to abuse
> the data model, and if someone doesn't want that, they need to present a
> viable alternative". We've come very far in OSM without such abuse and I
> don't see why it should suddenly be introduced.

Since "fuzzy areas" are allegedly harmful to the database and data model,
will the DWG be taking swift and immediate action to delete the 49 objects
currently harming the database by the use of the "fuzzy" key?

https://taginfo.openstreetmap.org/search?q=fuzzy

Further, since we have free tagging, there is nothing preventing mappers
(especially ones not party to these conversations) from adding additional
fuzzy areas to the database, mapped with some invented scheme, and
potentially even creating data consumers to consume such invented tagging.
Many tagging schemes in OSM have arisen in this manner.

I think we need to know whether these comments represent the opinion of the
DWG, and whether the DWG is signaling to the community that they will be
taking a heavy-handed approach against mappers that invent schemes for or
create fuzzy areas through the principle of free tagging.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

I agree with this interpretation.  sport=* should always be secondary to
some physical feature that is a location in some way related to the sport
(where it is played, where you can get lessons, a shop, etc).

On Sun, Dec 20, 2020 at 6:32 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 20. Dec 2020, at 22:45, Warin <61sundow...@gmail.com> wrote:
>
> Some examples;
>
> sportbowlsA place where you can play lawn bowls/lawn bowling.
>
> sportkitesurfingTo mark a spot for kitesurfing
>
> sportmultiA sports facility that is suitable for more than one
> sport
>
> sportracquetRacquetball facilities, such as racquetball courts
>
> sportscuba_divingTo mark a spot for scuba diving
>
> sportsurfingA spot for surfing.
>
>
>
> These do not describe the 'sport'/activity but state it is a
> 'place'/'spot' i.e. a physical thing.
>
>
>
> these descriptions are misguided and should be fixed. The tag “sport” is
> about a sport, it is a property, and unlike the wiki says, its presence
> does not even tell in every case that you can exercise the sport at an
> object with this tag. E.g.
> shop=sports
> sport=surfing
>
> The wiki is explicit: “ A sport should normally also be associated with a
> suitable physical feature where it is performed; often this is leisure
> =pitch
>  or leisure
> =trac
> 
>
>
> 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 - Emergency=Rescue Stations

> Yes, but all proposals suggest a rendering scheme.
>

The proposal process wiki page says "Not a part of the proposals process as
such, but hints for the renderer maintainer will help them out. maybe a
description of an icon (refer Map Icons), or an example mock-up. Usually
may be safely omitted from proposal."

Remember that, at the end of the day, the output of a successful proposal
is a change to the wiki, no more, no less.  It is still up to mappers,
renderers, data consumers, editors, etc., to choose to adopt the changes
specified by an approved proposal.  In practice, approved proposals have a
strong influence on all of those user communities, but at the end of the
day, a wiki page is documentation, not legislation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

Note that the shooting_range hazard is specifically about the zone in and
around a shooting range that you should avoid if you don't want to
accidentally encounter a stray bullet (the area of the hazard) rather than
as a tag for a shooting range itself.

On Sun, Dec 20, 2020 at 3:30 PM Jmapb  wrote:

> On 12/19/2020 5:16 PM, Martin Koppenhoefer wrote:
> > I agree with this, there’s a lot of abuse for “pitch”, and these are
> > not arguments for continuing the line, it’s never too late to learn
> > from past errors ;-)
> >
> > leisure=shooting_range might make sense? There are also 4000
> > military=range (is this about shooting? bombing? )
>
> I've been using leisure=sports_centre + sport=shooting for these,
> possibly combined with a building tag for an indoor range. Makes more
> sense to me to giving them a top-level leisure tag unlike all other sports.
>
> The value "shooting_range" is currently in use for the "hazard" key,
> though, and is part of the hazard=* proposal which is currently being
> voted in with flying colors. (
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard )
>
> J
>
>
> ___
> 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 - Reservoirs, lakes, and ponds

A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is now
open for comments.

This proposal:

  1. Deprecates landuse=reservoir
  2. Provides definitions for:
 a. water=reservoir
 b. water=lake
 c. water=pond

It is clear from various multiple discussions on this topic that there are
still open questions from the original 2011 water=* proposal, as well as
the exact definition of a reservoir, and how they differ from lakes and
ponds.  Previous discussions indicated that there is community support for
maintaining a distinction between lake and pond, rather than eliminating or
merging these concepts.

The definitions posed in this proposal were developed with the help of
considerable community input over the last week, and I want to thank the
numerous folks that collaborated on this.  The real world presents many
edge cases that make it challenging to come up with clear definitions, but
that should not prevent us from trying.

The goal in these definitions is to *describe* rather than *prescribe* how
reservoir, lake, and pond are actually tagged.  This necessarily involves
some degree of subjectivity between the categories, and the proposed
definitions leave it to mappers to make these subjective decisions when a
body of water exhibits some characteristics of more than one of these terms.

As this topic has been discussed ad nauseam for nearly a decade, I hope
that this proposal, discussion, and subsequent vote will allow us to put
this issue to rest, and/or document the level of community support that
exists for different tagging schemes.

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

> "Hillock" is quite common in British English


To describe a traffic control device?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

These guys in Texas will let you drive their tank around and shoot things,
for a price:

https://www.oxhuntingranch.com/activities/hunting-shooting/machine-gun-shooting/



On Sat, Dec 19, 2020 at 6:16 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 19. Dec 2020, at 23:59, Jeremy Harris  wrote:
> >
> > I think rifle-shooting was a component of a triathlon in a recent
> > Winter Olympic, too.
>
>
>
> if rifles are „ordnance“ my perplexity dissolves, I did not know the word
> ordnance and looking it up referred me to artillery. I bet you refer to
> biathlon rather than triathlon though ;-)
>
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

>
> is firing ordnance a leisure activity somewhere? Or a sport?


Hello, let me introduce to you the United States of America.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed feature - RFC - Military Bases

Historic or abandoned military features, or military ruins, are clearly not
what this proposal is describing.

On Sat, Dec 19, 2020 at 5:44 PM Graeme Fitzpatrick 
wrote:

> On Sun, 20 Dec 2020 at 02:00, St Niklaas  wrote:
>
>>
>> Your text or proposal seems to be focused on modern times.
>>
>
>  Yes, that's right, as it's intended for current, active, military
> establishments only.
>
> Since every town (vesting) or fortress (fort) has its own barracks in the
>> past
>>
>
> Yes, but they are (usually) no longer a military area, so to my mind
> shouldn't be mapped as landuse=military?
>
> I did earlier raise the question of how to deal with historical sites such
> as the ones you pointed out?
>
> "Ex-military bases, now often either historical precincts / tourist
> attractions / possibly ruins only eg Fort Lytton
> https://www.openstreetmap.org/#map=17/-27.41058/153.15263,
> https://fortlytton.org.au/ & many more similar worldwide. They were, but
> are not now military areas, so how should we tag them?
> museum + tourist attraction + was:landuse=military + was:military=base, or
> ignore all reference to "military"?"
>
> We could also include "historic=fort"
> https://wiki.openstreetmap.org/wiki/Tag:historic%3Dfort but that also
> says "a military fort: a stand-alone defensive structure which differs from
> a castle in that there is no permanent residence. There may have been
> temporary housing for the crew", which I have some issues with?
>
> (& I can already hear Paul saying just because it's old doesn't
> necessarily make it historic! :-))
>
> Thanks
>
> Graeme
>
>
>
> ___
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

Perhaps simply leisure=range, as this would be generic to any type of
facility where one might fire projectiles or ordnance.  You could then
extend that with something like range= to specify what is being fired,
and/or the existing sport= key if it's considered a shooting sport.

On Sat, Dec 19, 2020 at 5:18 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 19. Dec 2020, at 21:35, Paul Allen  wrote:
>
> Or is it always preferable to use sport=shooting + leisure=pitch?
>>
>
> That's an improvement.  Not ideal, because it's practised at a
> range, not on a pitch.  Just because we have other sports that
> have been shoe-horned into leisure=pitch I don't see a good
> reason to continue making that error.
>
>
>
> I agree with this, there’s a lot of abuse for “pitch”, and these are not
> arguments for continuing the line, it’s never too late to learn from past
> errors ;-)
>
> leisure=shooting_range might make sense? There are also 4000
> military=range (is this about shooting? bombing? )
>
> 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 - Tag:traffic_calming=hillocky

I've seen these in the US also, but I never knew what they were called.  I
understand that the purpose of them is simply to make noise when a car
drives over them, as they don't slow you down in any appreciable way like a
speed bump/hump.

We already have a tag for "a traffic calming device that makes noise when a
car drives over it", which is a rumble strip
(see: traffic_calming=rumble_strip).  Note, I am talking about the kind
that go all the way across the road, and not the kind in the shoulder of
the road that make noise when you veer out of your lane.

I usually think of rumble strips as grooves in the road, but it strikes me
that these micro-speed-bump things are essentially the same thing -- they
make noise when a car goes over it to alert the driver of something.

I'm uncomfortable with hillock/hillocky as a value.  Cursory searches seem
to indicate that this isn't a term in use, in any flavor of English.

On Sat, Dec 19, 2020 at 5:08 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 19. Dec 2020, at 22:53, Jeremy Harris  wrote:
> >
> > traffic_calming=multi_bump  ?
>
>
> or
> traffic_calming=mini_bumps ?
>
> when they come up with something smaller that could still be micro_bumps
> ;-)
>
>
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

I understand pitch to mean "a playing field" (as "pitch" is not often used
in US English -- we would say "soccer field" for example.).  I don't know
if a shooting range is a pitch or not, but it definitely isn't a playing
field.

On Sat, Dec 19, 2020 at 3:35 PM Paul Allen  wrote:

> On Sat, 19 Dec 2020 at 19:47, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> Is there some good use for sport=shooting_range?
>>
>
> Not in English as she is spoken.  "Shooting range" is not a sport.
> "Shooting" is a sport.
>
>>
>> Or is it always preferable to use sport=shooting + leisure=pitch?
>>
>
> That's an improvement.  Not ideal, because it's practised at a
> range, not on a pitch.  Just because we have other sports that
> have been shoe-horned into leisure=pitch I don't see a good
> reason to continue making that error.  A few bad ones,
> but no good one.
>
> --
> 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

Re: [Tagging] Tagging sewage treatment basins

2020-12-17 Thread Brian M. Sperlongano

With respect to basins, my understanding is that some of these have water
in them all of the time, some of them have water some of the time, and then
there are some that are almost always dry, but become wet only rarely when
they are needed (e.g. for stormwater handling)

Mappers have used BOTH landuse=basin tag as well as natural=water +
water=basin.  Both methods are documented in the wiki (parallel tagging
scheme).

Should basins be tagged as landuse, water, or both?  Or does it depend on
the type of basin?

On Thu, Dec 17, 2020 at 6:07 PM François Lacombe 
wrote:

>
> Hi Joseph,
>
> Le jeu. 17 déc. 2020 à 20:16, Joseph Eisenberg 
> a écrit :
>
>> I don't think mappers can know the maximum volume or capacity of a water
>> reservoir or water basin, unless it is written on a public sign somewhere?
>> We can map the surface area, but knowing the average depth or maximum depth
>> is quite difficult, especially when it is not uniform. However for
>> man_made=reservoir_covered and =storage_tank we have capacity=* (in cubic
>> meters?) and content=water/sewage/etc.
>>
>
> volume, elevation would be optional and mostly got from local signage.
> You may have opendata, knowledge or sometimes measurements.
> Many tags are already available but not used at the proper extent.
> For example, if we add capactiy (in cubic meters) on a waste water basin,
> we could do the same for man_made=covered_reservoir or even water=reservoir
> (if information is available somewhere)
> Look at this water tower hunting website giving many details from ground
> http://chateau.deau.free.fr/rdef/PagesHTML/Sommaires/GermanDossiers.html
>
>
>> The usage is not often tagged yet, since this might be hard for a mapper
>> to know.
>>
>
> Regarding waste water basins, it could be useful to distinguish
> - sand traps
> - oil separator
> - floccuation
> - decanter basins
> - aeration tanks
> and so on...
> https://www.horiba.com/fileadmin/_migrated/pics/Wastewater_Processing_E_.jpg
> That looks complex but easilly guessable from aerial imagery or even
> clearly explained during public visits of facilities.
> We could define simpler values if it helps
>
>
>> Currently for landuse=reservoir and water=reservoir this is some use of
>> reservoir_type= - https://wiki.openstreetmap.org/wiki/Key:reservoir_type
>> - with values of water_storage, sewage, tailings, evaporator, tank,
>> salt_pan, wastewater, slurry, irrigation, aquicultura, cooling, etc -
>> though only the first 4 are at all common.
>>
>> basin=* is used with landuse=basin or water=basin to describe the form
>> and function of the basin:
>>
>>- basin =infiltration
>> - An 
>> infiltration
>>basin  catches
>>storm water and allows it to seep into an aquifer
>>.
>>- basin =detention
>> - A detention
>>basin  catches
>>storm water and allows it to drain slowly into natural waterways.
>>- basin =retention
>> - A retention
>>basin  catches
>>storm water and retains it, forming an artificial pond.
>>
>>
>> And note that salt ponds (used to evaporate salt from sea-water) are
>> tagged as landuse =
>> salt_pond 
>> Pools for swimming are leisure
>> =swimming_pool
>> 
>>
>> I don't see many combinations with usage=* or another tag that might
>> describe how the reservoir or basin is used, so perhaps this could be
>> proposed?
>>
>
>
> That's right, usage=* corresponds to large familiy of activities and more
> specific tagging would be more suitable to describe precise purpose of a
> particular basin
> reservoir_type and basin looks like to refer to reservoir/basin purpose
> but mixes may concepts that may collide (irrigation is a water_storage as
> well)
> Only some values would match with usage=* ones: usage=irrigation is used
> 12k vs reservoir_type=irrigation 50
>
> Waste water processing could be described with less used water_works=*
> man_made=basin (An artifical structure designed to store some fluid, you
> find basins for storm/rain/radioactive water, sewage, oil, ...)
> content=sewage (Let's put waste water inside)
> usage=industrial (It's part of an industrial process)
> water_works=decanter (It's an actual decanter)
> capacity=
>
> I'd find great to use water=* with content=water, substance=water or
> natu

Re: [Tagging] Rapids (whitewater) on rivers

2020-12-17 Thread Brian M. Sperlongano

hazard=yes is neither banned nor discouraged.  It was simply not included
in the list of proposed approved tags due to objections raised during the
RFC.  The goal was to approve the hazard tagging that everyone agreed on.
Since hazard=yes has some existing tagging (>600 uses), it would still be
appropriate to document its use - it would just be listed as "in use"
rather than "approved" on its wiki page.

On Thu, Dec 17, 2020, 12:21 PM ael via Tagging 
wrote:

> On Thu, Dec 17, 2020 at 08:29:52AM -0800, Joseph Eisenberg wrote:
> >
> > Also, currently waterfalls (which can be considered very large and steep
> > rapids!) are tagged waterway=waterfall on a node. Other waterway barriers
> > are also tagged this way, e.g. waterway=dam and waterway=weir. Tagging
> > waterway=rapids on a node allows rapids to be tagged like other waterway
> > barriers to travel and similar to waterfalls.
>
> Noone, AIUI, is suggesting otherwise. But in some cases, there may be a
> case for adding hazard=yes.
>
> Other issue with the current wiki entry is that hazard=yes is
> discouraged (banned?), in which case we get an awkward duplication like
> hazard=rapids. Maybe in such a case, one could be more specific
> like hazard=drowning, hazard=rocks, or whatever.
>
> Weirs are another case where some are much more dangerous than others,
> and some may warrant a hazard tag as well. Again a case where
> hazard=yes would be appropriate.
>
> ael
>
>
> ___
> 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 sewage treatment basins

2020-12-17 Thread Brian M. Sperlongano

I knew them as sewage treatment ponds, but apparently there's a name for
them:

https://en.m.wikipedia.org/wiki/Waste_stabilization_pond

I feel like this a separate class of object that deserves its own tag,
either within or separate from natural=water, or perhaps even subclassed as
water=basin+basin=waste?

On Thu, Dec 17, 2020, 12:24 PM Joseph Eisenberg 
wrote:

> How should sewage treatment facilities be tagged, then?
>
> Isn't sewage 99% water?
>
> I think that most sewage treatment facilities in the USA include open
> settling basins and I would use landuse=basin or water=basin +
> natural=water for these: https://www.openstreetmap.org/way/420075503
>
> -- Joseph Eisenberg
>
> On Thu, Dec 17, 2020 at 1:55 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 17, 2020, 08:02 by dieterdre...@gmail.com:
>>
>>
>>
>> sent from a phone
>>
>> On 16. Dec 2020, at 17:52, Joseph Eisenberg 
>> wrote:
>>
>> You still have to distinguish marine water (outside of the
>> natural=coastline) from inland waters, and distinguishing rivers from lakes
>> is very important for proper rendering of many maps.
>>
>>
>>
>> and it seems landuse=reservoir is used for sewage as well:
>> https://taginfo.openstreetmap.org/tags/reservoir_type=sewage
>>
>> is this appropriate for natural=water?
>>
>> No.
>>
>> ___
>> 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] Rapids (whitewater) on rivers --> Hazards

Volker,

Thanks for the comments!  For the specific linked case (winding road for
74(!) miles), it seems that is already covered in the proposal -
hazard=curves and its sub-tags cover this, and if it truly is 74
consecutive miles, that I would think it's just fine to tag 74 miles worth
of ways in this way.

With regard to perceived hazards, and degrees of hazards, these are clearly
interesting and complex topics.  I don't know how to address them, but I
like that you're breaking down the problem in a systematic way.  I'm
intrigued and interested in hearing more and/or collaborating on the
topic.  I think we would need to examine a handful of examples to really
understand the space.

That said, I don't think the lack of a generalized approach towards
signed/unsigned/graded hazards should prevent us from formalizing the
30,000 usages of the hazard key.  Mappers have "voted with their tagging"
and we should respect that unless there is a strong reason not to.

On Wed, Dec 16, 2020 at 6:30 PM Volker Schmidt  wrote:

> Brian,
> I am trying to put order in this also in  my own mind.
> I think we should have an approach which is already clearly structured
> towards two things
> A the difference between
> - signposted hazards
> - unsigned hazards perceived by the mappers
> B for hazards that may have different degrees of hazardness (like the
> difficulty classes of hiking paths, MTB tracks, rapids,...)
> we should have solutions that allow a basic tagging plus the option of
> classes of hazardness for advanced mappers
>
> This approach should be put in the hazard proposal, even if at the moment
> the proposal only covers signposted hazards.
>
> Volker
>
> PS be prepared: how do we tag a hazard like this.
> <https://www.google.com/imgres?imgurl=https%3A%2F%2Fi.pinimg.com%2Foriginals%2Ff8%2F1f%2F81%2Ff81f81a46c423165f1ebf46dd63c9d64.jpg&imgrefurl=https%3A%2F%2Fwww.pinterest.se%2Fpin%2F446208275551301611%2F&tbnid=Lf3Kf2ucFsOb3M&vet=12ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu..i&docid=EcY5sJtmk2sheM&w=1200&h=1050&itg=1&q=california%20highway%201%20curves%20for%20next%2074%20miles&client=firefox-b-d&ved=2ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu>
>
>
>
>
> On Wed, 16 Dec 2020 at 23:13, Brian M. Sperlongano 
> wrote:
>
>> As the maintainer of the current hazard proposal - I don't really have
>> strong opinions about signed versus unsigned hazards, though I know others
>> do.  However, signed hazards seem to be something that we all agree should
>> be tagged, and this proposal is attempting to approve the collection of
>> usages that we all agree on.  I knew going in that the topic was too big to
>> be able to address every possible hazard that someone might want to tag but
>> we have to start somewhere.
>>
>> So --- consider this proposal a starting point, not the end of the story!
>>
>> There is no reason why hazard tagging can't be expanded from this current
>> base, and since we have free tagging, there is nothing stopping any mapper
>> from either simply inventing their own new hazard tag values or other
>> usages for things not covered, or offering new proposals to expand the
>> usage.
>>
>> On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
>>> > I see this subject directly related to the "hazard" discussion in the
>>> sense
>>> > that I suggested to clearly define the difference between signposted
>>> > hazards/dangers/warnings and un-signed such situations that are
>>> observable
>>> > on the ground, and therefore are subject also to personal judgement.
>>> With
>>> > other words, beyond the question of how to map it, there is also the
>>> > question of what is a rapid or any other hazard.
>>>
>>> I strongly agree. I was planning to vote against the current hazard
>>> proposal on exactly these grounds. There are clear hazards that
>>> are not necessarily signed. I don't see why we need two different
>>> tags.
>>>
>>> This is slightly off-topic in that I am picking up on the
>>> hazard tag rather than rapids. I see no objection to adding hazard=rapids
>>> although that might be redundant unless there exist rapids that are
>>> not hazardous. I suppose shallow rapids might qualify.
>>>
>>> ael
>>>
>>>
>>>
>>> ___
>>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

As the maintainer of the current hazard proposal - I don't really have
strong opinions about signed versus unsigned hazards, though I know others
do.  However, signed hazards seem to be something that we all agree should
be tagged, and this proposal is attempting to approve the collection of
usages that we all agree on.  I knew going in that the topic was too big to
be able to address every possible hazard that someone might want to tag but
we have to start somewhere.

So --- consider this proposal a starting point, not the end of the story!

There is no reason why hazard tagging can't be expanded from this current
base, and since we have free tagging, there is nothing stopping any mapper
from either simply inventing their own new hazard tag values or other
usages for things not covered, or offering new proposals to expand the
usage.

On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging 
wrote:

> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
> > I see this subject directly related to the "hazard" discussion in the
> sense
> > that I suggested to clearly define the difference between signposted
> > hazards/dangers/warnings and un-signed such situations that are
> observable
> > on the ground, and therefore are subject also to personal judgement. With
> > other words, beyond the question of how to map it, there is also the
> > question of what is a rapid or any other hazard.
>
> I strongly agree. I was planning to vote against the current hazard
> proposal on exactly these grounds. There are clear hazards that
> are not necessarily signed. I don't see why we need two different
> tags.
>
> This is slightly off-topic in that I am picking up on the
> hazard tag rather than rapids. I see no objection to adding hazard=rapids
> although that might be redundant unless there exist rapids that are
> not hazardous. I suppose shallow rapids might qualify.
>
> ael
>
>
>
> ___
> 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] Rapids (whitewater) on rivers

+1

IMHO these are complementary.  waterway=rapids can be tagged from overhead
imagery, and the additional detail of the rapids can be added later by
people with subject matter expertise.

I see this as equivalent to sac_scale=* for hiking trails - it does not
replace the underlying highway=path, it adds more detail as to the type of
path.

Since both taggings are in use (and one is approved), it is appropriate to
document both.  If someone thinks that waterway=rapids should be
deprecated, I think the burden would be on them to propose that.

On Wed, Dec 16, 2020 at 3:58 PM Joseph Eisenberg 
wrote:

> In the year 2020 waterway=rapids has been added a couple hundred times,
> and the other two tags whitewater:section_grade and whitewater:rapid_grade
> have been used about 100 times each:
> https://taghistory.raifer.tech/#***/whitewater:rapid_grade/&***/whitewater:section_grade/&***/waterway/rapids
> (zoom in to the most recent yet)
>
> I think both tagging methods have their use. The tag waterway=rapids is
> great to add to a node to specify that there are rapids here, and the
> others are good for expert kayakers and rafters who are able to assess the
> rapid grade.
>
> I don't know enough about the subject to make a proposal to clear things
> up, but the existing tags seem to be fine.
>
> -- Joseph Eisenberg
>
> On Wed, Dec 16, 2020 at 12:35 PM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:
>>
>> The last time I looked, there was no non-deprecated way to map the
>> information that I had.
>>
>> That is sign of bad tagging scheme.
>>
>> I now see that @jeisenbe has restored the `waterway=rapids` tag to the
>> Wiki.
>>
>> Is it enough?
>>
>> I asked here on the mailing list, and the only answers that I got were
>> along the lines of "then don't map it."  So for several years I haven't
>> attempted to map rapids. The ones I know of and want to render, I maintain
>> separately from OSM, because the previous discussion had caused me to label
>> this feature mentally as, "OSM doesn't want this mapped."
>>
>> :( Hopefully this can be fixed so this will not happen.
>> ___
>> 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] The saga of landuse=reservoir vs water=reservoir

The statistics reflect all areas, regardless of which editors were used to
create them.  I stand by them, as numbers do not lie.  There was a 3:1
preference for water=reservoir during 2017 and 2018, two years prior to the
change in iD preset.  The data is open, and taginfo provides a very helpful
REST API.  Feel free to conduct your own statistical analysis.

If you are not willing to have this question put up for a proposal (where,
as with any proposal, you are free to present your argument for all to
consider), your arguments are in bad faith, and again, must be dismissed
without consideration.  Your desire to bypass our democratic process and
upend community consensus for tagging you don't like is frankly insulting
to the rest of us that work hard to achieve consensus in tagging.  Why
should we waste time debating you, if you aren't willing to accept the
outcome of the community decision-making process?

On Wed, Dec 16, 2020 at 9:43 AM Tomas Straupis 
wrote:

> Brian, you're using statistics which DO NOT represent mappers preferences.
> If you would use only JOSM created objects - then it would be close to
> mappers preferences (as JOSM allows mappers to choose).
> But you use iD created/adjusted objects and as it does not allow
> showing your preference (drilling down into tags is only a theoretical
> possibility) and even pushes you to overwrite other peoples
> preferences you have to exclude iD tainted objects if you're trying to
> get "community preference" from statistics.
>
> Therefore I would suggest starting with the core - arguments
> advantages/disadvantages of both schemas.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

Tomas,

Since you are not willing to accept (1) an existing approved proposal, (2)
new proposal to correct flaws in the first one, or (3) the overwhelming
preference of the mapping community over the past four years[1], then I'm
sorry but we must curtly dismiss your arguments as a one-man crusade[2,3,4]
against tagging which you do not like.  It is clear that you wish to impose
your views on the community regardless of what the consensus is.  If there
is truly a community of mappers out there that share your view, it should
be easy to convince them to come and vote.  Since you are not willing to
accept the democratic process that we have established, and you do not
respect the viewpoints of others, all you are doing is wasting our time.
Thus I ask you, respectfully, to stop.

If there are others here that desire a proposal for the purpose of
documenting that landuse=reservoir is deprecated, I will gladly do so.
With no proposal, the status quo will remain: landuse=reservoir will
continue to be steadily replaced with water=reservoir, and our wiki will
remain confusing in its documentation of these tags.

[1] https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/Analysis/Reservoir
[2] https://github.com/openstreetmap/iD/issues/7382
[3] https://github.com/openstreetmap/iD/issues/6589
[4] https://josm.openstreetmap.de/ticket/17874

On Wed, Dec 16, 2020 at 8:32 AM Tomas Straupis 
wrote:

> > If you believe that your argument in favor of tagging reservoirs as
> landuse is
> > strong, then you should have no objection to placing this question up
> for a
> > community vote, and allowing the community the freedom to decide.
>
>   Brian, landuse=reservoir is the ORIGINAL and ACTIVE schema. Why
> should anybody propose the vote for it?
>
>   I do not like voting on wiki because it is clearly a flawed process
> (as discusses a number of times), what do 20 wiki participants/people
> mean against the actual mappers? We could end up in the same situation
> as with original water=reservoir proposal where somebody with barely
> few months of participation in OSM and no knowledge of GIS/Carto
> makes/influences the decision/proposal...
>
>   And what is a problem of listing benefits of water=reservoir schema?
> If there are none, then the only logical decision is to deprecate
> water=reservoir, because it would make it worse of the two. Shouldn't
> we get ARGUMENTS before we go to any kind of voting/decision?
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

Tomas,

If you believe that your argument in favor of tagging reservoirs as landuse
is strong, then you should have no objection to placing this question up
for a community vote, and allowing the community the freedom to decide.


On Wed, Dec 16, 2020 at 8:01 AM Tomas Straupis 
wrote:

> 2020-12-16, tr, 01:32 Brian M. Sperlongano rašė:
> > The iD editor preset appears to use water=reservoir while the JOSM
> > preset appears to use landuse=reservoir.
>
>   Not entirely correct.
>   * JOSM gives freedom to mappers and supports BOTH.
>   * iD forces to use water=reservoir and evenmore pushes users to
> change tagging by disguise of "upgrade" - therefore even mappers who
> do not understand/know the difference are inclined to change the
> tagging. <- this is the reason for current stats
>
>   My understanding is that given landuse=reservoir is the original
> water schema, the new one should show some benefits to replace the
> original one? Or we do not care about consistency and simply go on
> with replacing very prominent schemas for no good reason?
>
>   My take is that:
>   * landuse=reservoir is better compared to natural=water+water=x
> because it pushes mappers to make distinction for these
> GIS/Cartographically very different classes of water. Therefore if
> landuse=reservoir is deprecated tagging will be worse.
>
>   What are the benefits of water=reservoir?
>   Given that full scope of proposal to put all water classes under
> natural=water (the purpose which is disadvantageous from
> GIS/Cartography perspective) have failed and we're now only talking
> about two classes of water (natural and man made), and classes which
> are very different and therefore should not be merged.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-15 Thread Brian M. Sperlongano

Thanks everyone for the discussion.

I believe there are two germane points being raised by Tomas that warrant
our consideration:

1. It is not clear from the original 2011 vote which created
water=reservoir (and other values) as to whether the community intended to
deprecate landuse=reservoir or whether the community intended to create two
parallel tagging schemes for the same object.

2. There is some subset of the user base that uses and/or prefers
landuse=reservoir over, or in addition to, water=reservoir.  The iD editor
preset appears to use water=reservoir while the JOSM preset appears to use
landuse=reservoir.  It is unclear whether there is actually a strong user
base preference for either tag or whether the numbers simply reflect the
presets in the editors that users happen to use.  There is also no way to
determine from these discussions alone the size of community support for
either scheme, particularly if such support is factional within non
English-speaking communities.

Given these issues, I would suggest a narrowly-written proposal that puts
forth the clear and specific question as to whether landuse=reservoir
should be deprecated.  If that proposal demonstrates clear community
consensus for deprecation (per the guidelines in our proposal process), we
can update our wiki documentation to explicitly recommend that
landuse=reservoir be gradually replaced by natural=water+water=reservoir.
If, instead, that proposal demonstrates that there is still a sizable
subset of mappers that prefer the landuse=reservoir tag, we would simply
leave both tags documented without caveats, noting the results of both this
and the 2011 proposals, and allow the community to sort out which tagging
scheme is preferred based on actual usage over time.

As I am the one that raised this issue in the first place, I would be happy
to draft such a proposal for consideration.  I want to be clear that in
such a proposal, any instances of disrespectful or insulting commentary
directed towards any group or individual will not be tolerated and will be
immediately brought to the attention of the wiki admins for followup.

Would this be satisfactory to the group in resolving the question of
reservoir tagging?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Brian M. Sperlongano

Wouldn't it be more consistent to keep it in the same key, and call it
place=lake_group?  Or even place=lakes?

Would this be used for something like the Great Lakes in USA/Canada or is
that too large of a feature?

On Tue, Dec 15, 2020, 12:05 PM stevea  wrote:

> +1.  Joseph's suggestion is a fine example of "OSM can and does coin new
> tags on occasion."  Adding a nice boost, there is a suggestion that
> "similar" tagging be used as an example of how to define / use / document
> the new tag.  Great!
>
> On Dec 15, 2020, at 6:56 AM, Joseph Eisenberg 
> wrote:
> > Re: “ a couple of islets with a collective name”
> >
> > We have a tag for that: place=archipelago for a group of islands.
> >
> > There isn’t a common tag for a group of lakes with one name, probably
> because this is only common in some countries, especially near the Arctic
> region. We’ve talked about this issue before but did not find an existing
> tag.
> >
> > I would suggest a tag like natural=lake_group to be added to a
> multipolygon which includes each of the lakes, similar to how archipelagos
> are mapped.
>
> ___
> 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] Changes to clarify the Hazards proposal during the vote

Hello,

I recently received late feedback on the hazards proposal. Based on the
feedback, I felt it was necessary to make small changes to this proposal.
I believe these changes are sufficiently minor that they do not invalidate
the voting which has occurred so far. Since this proposal has begun voting
as of two days ago, I want to ensure that this change is made with full
transparency. If anyone feels that these changes require a reset of
voting, or an extension of the voting period, I will do so upon request.

The changes are as follows:

1. Clarify that "bump" and "dip" hazards may apply to both artificial and
naturally-occuring dips. This ensures that the definition of these two
tags are consistent with how those signs are actually used in the real
world, and also ensures that the definitions are consistent with the signs
shown in the sample images. In addition, a sentence was added to
specifically clarify that this tag should not be applied to traffic control
devices, which have their own tagging.

2. Clarify that it is acceptable to tag both a hazard sign as well as a
hazard itself. While both of these usages were listed as individually
acceptable, the proposal was silent on whether both approaches might be
used in tandem.

The exact changes to the proposal can be found here:

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2Fhazard&type=revision&diff=2072737&oldid=2072735
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

On Mon, Dec 14, 2020 at 5:11 PM François Lacombe 
wrote:

> Hi Brian,
>
> Thank you for your comments
>
> Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano 
> a écrit :
>
>> 1. The proposal states "It is proposed to discourage the use of
>> undocumented pump:type=* to state pump mechanisms in favour of new
>> pump_mechanism=*."  It is not clear what is meant by "discourage" in this
>> context.  Given the other threads today regarding reservoirs, it is
>> important to communicate clearly what we mean when we propose to stop using
>> a tag.  I would ask that instead of "discourage", that the proposal should
>> explicitly say "deprecate" so that there is no confusion that you intend
>> for us to stop using pump:type and document it as deprecated in the
>> deprecated features list.  Otherwise, I would ask that you clearly and
>> explicitly state what you mean by "discourage" and where those words of
>> discouragement would go.
>>
>
> To me, discourage means provide a better way to describe features and
> encourage people to do so. Reviewing a proposal and vote approval is a step
> and additional work has to be done in that way.
> I remember a discussion in my early OSM years about sense of "deprecated",
> "discouraged", "approved", "reviewed"... and I'm now merely in favour of
> encouraging and discouraging than enforcing or forbidding
> pump:type isn't documented currently, then how could it be added to any
> deprecated features list?
> The proposal aims to make pump_mechanism approved and then pump:type could
> be added to its wiki page as a possible duplicate.
>

Thanks for the clarification, however it does not quite resolve the
question.  That there is no such status "discouraged".  There is a page
that documents the possible status values[2] used by wiki templates.  To
directly answer your question, since there is no wiki page for the tag (as
in this case), it would be deprecated simply by adding it to the deprecated
features table with no additional action needed.

The wiki[1] says: "OpenStreetMap does not have 'banned features', as
anybody is allowed and encouraged to use any tag they think is useful."
Therefore, deprecating a feature does not "enforce or forbid" the use of a
tag - all it does is set the tag's status to deprecated on the tag's wiki
page, and adds an entry to the deprecated features[1] page.

If you are not proposing to deprecate the pump:type tag, then I think you
need to explain what you mean by "discourage".  Does that mean you will add
a disclaimer to some other wiki page, with a link to the proposal?  I'm not
sure what benefit that brings over simply deprecating the tag.

[1] https://wiki.openstreetmap.org/wiki/Deprecated_features
[2]
https://wiki.openstreetmap.org/wiki/Template:Description/doc#Additional_information
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

I agree with Mateusz that the wiki IS the project's standard document for
the meaning of tagging (from the perspective of data consumers) and how to
tag (from the perspective of mappers).  Note that both perspectives are
important.  But to address the specific point, there is no standard
document for renderer implementers, because there is no such thing as a
standard renderer implementation.  A renderer (something that turns data
into a map) is just one of very many ways to use and visualize geospatial
data.

I know you did not intend to criticize the volunteers that make this
project happen, but consider that when you dismiss the wiki as "no
documentation", it can be interpreted as dismissing the hard work of
countless people that volunteered their time to develop (and translate!) a
large and complex documentation base.  Most software developers find
documentation to be a chore and the last thing they deal with.  That is why
as someone who has the skills, time, and interest to contribute, I've
expended considerable effort improving the wiki's tagging documentation,
and when I've found gaps or problems, I've worked to draft and advance
proposals to address the deficiencies.  I saw a need and began filling it,
and my contributions to that documentation are something I am proud of.

For a project that provides its only product for free, it should be obvious
why the OSM Foundation has a small budget and can't afford to hire more
than a cursory staff for the most critical needs.  Consider changing your
perspective to "what am I able to contribute to make this project
stronger?" rather than "here are the things that are wrong".

As the author of a product that consumes OSM data, I am grateful to all of
the programmers, mappers, and technologists that have built the various
pieces of this ecosystem without which my product wouldn't exist.  It would
be awfully presumptuous of me to complain that this thing provided to me
entirely for free is in some way lacking, and I'm glad I am able to "give
back" in this small way.

This is just a gentle reminder that when you speak of "OSM", you are not
speaking to some big corporate entity with a glass lobby, a receptionist,
and someone to answer the phone -- you are speaking to a loose tribe of
individual volunteers that are collaborating on a free map of the world.

On Mon, Dec 14, 2020 at 4:15 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 14, 2020, 22:03 by and...@torger.se:
>
> Ok, understood. However as far as I know OSM lacks a standard document
> for render implementors to actually know how data should be interpreted.
>
> In part it is https://wiki.openstreetmap.org/ in part it is decision of
> authors of map style how they want map data to be intererpreted.
>
> The only reason I get here is when the OSM wiki doesn't have answers
>
> Yes, you are raising some very interesting cases (for example case of
> mountain
> and peaks named separately).
>
> Even here there are various answers and ideas circulating
>
> This is whole point of tagging mailing list for features with no known
> good way of tagging them. (or where it is not documented)
>
> ___
> 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 put a name tag on an area with more than one type?

It sounds like what we are asking for is the ability to tag a rough polygon
in the approximate area where a label should be placed for a known but not
strictly bounded toponymic feature (mountain range, water body, etc).  That
would give a hint to renderers as to the location and most importantly,
size, of a label for such features.  This would also solve the current
problem of tagging large coastline-bounded marine features, such as seas,
bays, straits, etc., without creating overly complex polygons resulting
from re-use of the coastline ways.  It would also fix the inability to tag
such basic features as oceans.  When you type "Atlantic Ocean" into any map
other than OSM, it shows you the ocean.  When you type it into
openstreetmap.org, it shows you a super-close zoom-in to a single node -
not very helpful.

It is reductio ad absurdum to say that features like "Pacific Ocean",
"Swiss Alps", "Spratley Islands", or "Sahara Desert" don't belong on a
project that aims to create a map of the world simply because these
features don't have a fence or sign around them to indicate their exact
boundary.  Features exist in approximation in the real world, and it is a
perfectly valid opinion to want those things to appear, also in
approximation, on the map.  These things are verifiable because people know
what these toponyms mean and represent.  If it is possible to write a
wikipedia article on "Indian Ocean", it is possible to draw a rough polygon
in openstreetmap which means "this is roughly where the Indian Ocean is,
and renderers should consider drawing a label".

Note that this is not "tagging for the renderer" (which is often code for
"tagging that I don't like"), these are real, major features that actually
exist in the real world and their absence makes OSM weaker.

On Mon, Dec 14, 2020 at 8:04 AM Anders Torger  wrote:

> To make a specific answer to "what additional verifiable local
> knowledge" this relation is intended to cover, is that the wetland is a
> single named entity, not multiple entities named the same.
>
> And here's some elaboration. This is 4 km wide wetland, in the real
> world named as a single entity, but it does consist of both bog and
> marsh, in the screenshot named each separate part as you suggested:
>
>
> https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png
>
> "Verifiable" is tricky in terms of names of natural features as we all
> know, as many of those haven't defined borders. Wetlands maybe so, but
> even in this case, are the small satellite wetlands part of Rijmmoàhpe
> or not? Noone knows, it was never defined. That's the way these names
> work. Does that mean that these type of names should not be in OSM at
> all? You tell me. I just try to contribute geodata to make maps for
> outdoor use. If OSM is not the platform, let me know.
>
> I'm not particularly experienced in how OSM use relations and why the
> are so "obnoxious" as Mateusz put it, but I have worked with arranging
> data in many projects and to me this is an obvious case of data that
> should be arranged as a container with all its parts. I also think that
> it would make it much easier to fix the renderer, it can easily get all
> parts for the single name, and as a added bonus get to know the "master
> type" (instead of having to go through all parts calculate the area to
> figure out which nature that is dominant to get the tag styling right).
> Etc.
>
> I didn't add it thinking about any renderer though, it was actually for
> myself to more easily keep track of all parts when editing on JOSM. With
> a parent relation I just need to click on one, and then on the parent
> relation to get all selected. Otherwise I need to create a filter on the
> name or something, so to me it's also more efficient for the mapper.
>
> And in the end I think that the individual parts should not have name
> tags at all, it should only be on the parent relation. The reason we put
> it on the individual parts now is to me obviously just because there is
> no renderer support available anywhere for naming these type of natural
> entities, and probably will stay that way for the foreseeable future.
>
> Having a relation on these new features makes them easy to find in the
> database and one can upgrade the tags later. I suppose it's much more
> complicated to make a filter to find parts named the same with shared
> borders, I don't really know how to do it in JOSM (but maybe one can?).
>
> So that's my reasons, but if you think they're bad I'll remove the
> relation. I would like to hear how you want to solve the problem instead
> though. As you see on the screenshot, the current situation is far from
> optimal with lots of tiny name tags where there should be only one.
>
> /Anders
>
> On 2020-12-14 13:28, Christoph Hormann wrote:
> >> Anders Torger  hat am 14.12.2020 07:59 geschrieben:
> >>
> >>
> >> I'll gladly answer questions, but I think you need to rephrase. I
> >> suppose it is some hidden critique in the

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

François, thank you for your hard work on this proposal!  I will most
likely support this version.  I have a few questions:

1. The proposal states "It is proposed to discourage the use of
undocumented pump:type=* to state pump mechanisms in favour of new
pump_mechanism=*."  It is not clear what is meant by "discourage" in this
context.  Given the other threads today regarding reservoirs, it is
important to communicate clearly what we mean when we propose to stop using
a tag.  I would ask that instead of "discourage", that the proposal should
explicitly say "deprecate" so that there is no confusion that you intend
for us to stop using pump:type and document it as deprecated in the
deprecated features list.  Otherwise, I would ask that you clearly and
explicitly state what you mean by "discourage" and where those words of
discouragement would go.

2.  You propose to deprecate man_made=pumping_rig and propose to replace it
with the (far more popular) man_made=petroleum_well.  Both of these are
combined with the substance=* key.  I would ask whether there are usages of
pumping_rig that are being used with substance=* tags for non-petroleum
products (i.e. not oil/natural gas) which would be lost by abandoning this
pumping_rig?  If the answer is "yes", then I would support simply changing
the description of pumping_rig to explicitly exclude petroleum products,
and if the answer is "no" then I agree with deprecating it.

On Sun, Dec 13, 2020 at 1:48 PM François Lacombe 
wrote:

> Dear all,
>
> Following some rework to take care of comments received during the first
> voting round of pumping proposal, here is a second proposed version
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> IanVG and I spent time to improve wording and make rationale section
> clearer.
> Classification of pumps is now done with pump_mechanism and is still
> equivalent to which available on Wikipedia. Numerous references are made
> toward it.
>
> Additional examples and illustrating gifs have been added at the bottom as
> well.
>
> This message opens a second RFC period and is expected to be shorter. Vote
> could begin by next Saturday.
>
> Best regards
>
> François
> ___
> 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] Is landuse=conservation actually deprecated?

I will note that the Massachusetts, USA mapping community does believe that
there is a distinction between the two tags, as noted here:

https://wiki.openstreetmap.org/wiki/Massachusetts/Conservation

However, this usage and definition seems to be specific to that particular
community and is not a widely shared viewpoint.  I was under the impression
that landuse=conservation was deprecated, but if that was resulting from an
arbitrary wiki edit and not a formal proposal, perhaps it should not be
marked deprecated in the wiki.

As to the question of whether landuse=conservation and
boundary=protected_area mean exactly the same thing, I don't think we can
answer that easily, because boundary=protected_area lacks a formal
definition.  My prior, current, and hopefully future proposal(s) are in
part working towards developing that definition of boundary=protected_area,
and aligning its meaning to the way wikipedia defines[1] protected area.

My personal *opinion* is that boundary=protected_area should deprecate
landuse=conservation, but there are certainly multiple viewpoints out there.

[1] https://en.wikipedia.org/wiki/Protected_area

On Sun, Dec 13, 2020 at 12:26 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Recently another wiki user marked landuse=conservation as "deprecated" on
> the Map Features page:
> https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:landuse&curid=11273&diff=2071912&oldid=2068278
>
> This same user had marked the page itself as deprecated back in 2017:
> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Alanduse%3Dconservation&type=revision&diff=1498145&oldid=387459
>
> Previously the Tag:landuse=conservation page had been redirected to a
> proposal since 2009:
> https://wiki.openstreetmap.org/wiki/Proposed_features/conservation
>
> *"Conservation land is land protected from development.*
>
> *It is left in more or less a natural state.*
>
> *It is often maintained to a very limited extent, such as annual mowing to
> prevent forest growth, removal of invasive species, replanting, or dealing
> with or preventing erosion.*
>
> *The public typically, but not always, has access, as it is a valuable
> recreational resource. (Sometimes the public has no physical way of getting
> to it, or is not allowed for water protection reasons, safety, etc)."*
> Now boundary=protected_area is probably the more common way to tag this
> concept.
>
> Comparison:
>
> https://taginfo.openstreetmap.org/compare/boundary=protected_area/landuse=conservation
>
> landuse=conservation is declining since 2015:
> https://taginfo.openstreetmap.org/tags/landuse=conservation#chronology
>
> While boundary=protected area mostly increases, though there are some
> jumps up and down from imports I imagine:
> https://taginfo.openstreetmap.org/tags/boundary=protected_area#chronology
>
> Is it correct to say that landuse=conservation has been deprecated,
> practically, by boundary=protected_area
> , even
> though that tag has not been approved?
>
> -- Joseph Eisenberg
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

Tomas,

Respectfully, I ask you to cease the pattern of name-calling, personal
attacks, and insulting language used in this forum, and on project bug
trackers[1][2].

Let's please assume good faith and be respectful while we discuss
differences of opinion with an open mind - we are all here for the same
reason - working together to create the best possible map for the world.


[1] https://josm.openstreetmap.de/ticket/17874
[2] https://github.com/openstreetmap/iD/issues/6589

On Sun, Dec 13, 2020 at 10:39 AM Tomas Straupis 
wrote:

> 2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
> > 2019 was a turning point, and over the last two years, landuse=reservoir
> has
> > been on a steady decline, while water=reservoir continued its rapid
> growth.
>
>   New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not what was better, and introduced
> water=reservoir as the only way to tag, all this at the time when
> water=reservoir usage was close to zero!
>
>   And the only reason for change of stat starting 2019 is because
> coders of iD decided to lie to the users that landuse=reservoir is
> deprecated which it never was and started replacing landuse=reservoir
> under their highly controversial disguise of "upgrade tags".
>
>   So the change of statistics is not the preference of mappers but
> preference of some nerds.
>
> > Is it time to more directly recommend that mappers favor natural=water +
> water=reservoir
> > *instead of* rather than *in addition to* landuse=reservoir?
>
>   I would propose to deprecate water=reservoir and even more - add
> guards so that such pointless/nerdy duplicate standards would not be
> introduced in the future.
>
>   Note that one of the main nerdy points of this schema was to have a
> possibility to write sql easier (somebody has problems with "and/or")
> and this would also require riverbanks to fall into this new water
> schema. And riverbank clearly does not fall into that even with iD
> lying about it too. Therefore the only point has failed and this
> stupidity is spreading havoc in tagging of such prominent water
> features for more than 10 years now.
>
> P.S. There is quite an easy solution to have a separate iD instance
> for beginners with correct tagging presets loaded.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

This story is offered because I find it interesting, and as a possible
catalyst for updates to our tagging documentation.  I offer apologies to
those that are well aware of this controversy.

There are two competing ways to tag reservoirs: landuse=reservoir, or
natural=water + water=reservoir.  The reservoirs near me all used the
"landuse" version, and so I only recently became aware of the difference
when another mapper pointed it out.

landuse=reservoir was the original scheme (first documented on the wiki in
2008), while water=reservoir came about three years later, in an approved
2011 proposal[1] which added the key "water".  To read the voting
commentary, the proposal was mildly controversial: one user described the
vote as rushed, and another cited an issue we still discuss in 2020:
whether there is a difference between water=lake and water=pond!

The proposal noted among other things that "landuse=reservoir [is replaced]
by natural=water + water=reservoir".  It further went on to state:

"Until all renderers (which render those areas differently from
natural=water) support those new values, both schemes can be used together:
just add natural=water and water=* to already present tags."

And so, mappers began mappers began adding the new tags to the map.  In
mid-2011, landuse=reservoir sat at 180K usages while the newly-invented
water=reservoir had near-zero usages.  The proposal described that mappers
should use both tagging schemes until renderer support was achieved, after
which (presumably) landuse=reservoir could be safely removed from these
features (and we could finally stop tagging something that is in reality a
type of water as a type of land!)

Renderer support for natural=water is ubiquitous today.  However, there was
no trigger built in to declare that "renderer support has been achieved",
and the double-tagging went on for *eight years*.  By the end of 2018,
tagging of landuse=reservoir had peaked[2], having racked up 450K usages.
The upstart water=reservoir, while still far behind, had been experiencing
a near-exponential growth curve[3], with 180K usages.

2019 was a turning point, and over the last two years, landuse=reservoir
has been on a steady decline, while water=reservoir continued its rapid
growth.  As of today, landuse=reservoir is down to 384K usages, and
water=reservoir has reached 332K usages.  However -- if we exclude nodes
(as there are a large number of presumably imported landuse=reservoir nodes
still hanging out in the map), water=reservoir is slightly ahead - 331K vs
330K.

Now let's turn to what our wiki has to say about this:

"There was considerable confusion whether landuse=reservoir is deprecated,
but it turned out to be not deprecated and landuse=reservoir is used more
widely than "new" way natural=water + water=reservoir."

This is...an interesting lede for a tagging article to say the least!  The
real story behind this awkwardly-worded statement is in the
landuse=reservoir wiki article history, which documents a 9-year-long
low-grade edit war between pro-landuse and pro-water factions.  The comment
about "considerable confusion" was first added in 2014, and has stuck,
despite several attempts over the years to remove it.

This ends our tale.

Is it time to more directly recommend that mappers favor natural=water +
water=reservoir *instead of* rather than *in addition to* landuse=reservoir?


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
[2]
https://taginfo.openstreetmap.org/tags/?key=landuse&value=reservoir#chronology
[3]
https://taginfo.openstreetmap.org/tags/?key=water&value=reservoir#chronology
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-12 Thread Brian M. Sperlongano

> Break - I've just found that there actually are a handful of
> club=army_cadets (8), =air_cadets (5) & =sea_cadets (2) already in use,
> although all are undocumented, so they will be fine. Are we all in
> agreement though, that there should be no reference to "military" against
> Cadet groups (except, of course, for those countries where they *are*
> actually part of the military!)?
>

I would tend to agree - cadet groups are not a military service like an
army or navy.


> One other thing I've realised from this exercise is that the "Military"
> page needs further cleaning-up, but let's get this one out of the way
> first! :-)
>

Excellent - I look forward to your effort and enthusiasm trying to sort
this all out!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - Hazards

2020-12-12 Thread Brian M. Sperlongano

Hello,

Voting is now open for a two-week period on the proposal "Hazards".  I wish
to express my sincere appreciation to the many of you that provided
valuable input during the development of this proposal.

Voting link:
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard#Voting
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-11 Thread Brian M. Sperlongano

Hello Anders,

I would recommend creating a multipolygon relation (type=multipolygon) with
each of the wetland pieces, and set the name= and appropriate natural= and
wetland= tags on the relation.

On Fri, Dec 11, 2020, 11:11 AM Anders Torger  wrote:

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
> Asking on OSM Help website for a solution I got the answer to make a new
> containing multipolygon and set the name on that. That would be quite
> elegant for sure, but JOSM warns about that, can't have a name without a
> type, and if I set the type, say natural=wetland without any subtype, I
> get a JOSM warning that I have natural features on top of eachother. If
> I still upload it OSM-Carto does render out the name but you can see
> that the wetland pattern of the outer polygon is drawn on top of the
> contained polygons, so it does not seem to be the way to do it.
>
> The least bad way I've come up with is to just name all polygons
> belonging to the same wetlands the same, and hope for that in the future
> smart renderers will understand that polygons with shared borders and
> shared name is the same named entity.
>
> Any ideas or suggestions?
>
> /Anders
>
> ___
> 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] Proposed feature - RFC - Military Bases

>
> Ground/land, air/aviation & maritime/naval all seem pretty well
> interchangeable, space is ready for the future & we should also include
> amphibious & probably Staff / Command / Headquarters for somewhere like
> this place: https://www.openstreetmap.org/relation/89605! Currently
> office=military & also office+government (together with building=public?),
> so would become landuse=military + military=base +
> military_service=joint_forces + function/branch="command" - sound good?
>

Yes, this makes sense in broad strokes, though some thought is needed as to
the exact set of keys and values would be needed to describe these things.


> I don't think we'd need to drill down further into what "type" of unit it
> is (Armour, Artillery, Engineers, MP etc) as that will just introduce a
> whole realm of further confusion, especially if it's being done by
> non-Military mappers, plus which I also still have some security concerns
> about identifying things too accurately‽
>

I think it would be fine to have a way to tag such unit identifiers, though
there can be multiple tenant units within a base, so this is possibly
beyond the scope of base tagging.

I did mention earlier in reply to one of the comments that (previously
> base=) military_service=yes / unknown would be OK if you can't work out
> what's in there, so that should hopefully cover that problem?
>

I do not think that military_service=yes or =unknown should be included in
the proposal.  For the "=unknown" situation, this is accomplished by simply
omitting the tag, and for the "=yes" situation, this is redundant with the
military=* tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

In general I have avoided proposing values for these "warning of something
ahead" signs that are at a non-trivial distance from the hazard, as I think
that is a controversial usage, deserving of a separate discussion and/or
proposal.  Since there is already a tag for cattle grids and there is no
usage under hazard=* in taginfo, I would not add a new value for these, and
I note that the traffic_sign key has a general facility for tagging of
standard traffic signs by traffic sign ID.

On Thu, Dec 10, 2020 at 5:00 PM Philip Barnes  wrote:

> On Thu, 2020-12-10 at 07:27 +1000, Graeme Fitzpatrick wrote:
> >
> > Grid: to warn that you are approaching a cattle grid - we already
> > have a tag for grids, do we also need a sign to warn that they're
> > coming up?
>
> Welsh example (I have never seen these in England).
> https://www.mapillary.com/map/im/NiGw-6hqC72o_jkcnxe4UQ
>
>
> > Graeme
> >
> > ___
> > 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] Proposed feature - RFC - Military Bases

>
>
> Services often cross functions; for example, the US Army operates air
>> fields[2].  Tagging this military_service=army would be accurate, but would
>> not convey that this is an air force base, but not an Air Force base.
>>
>> To get around all of this, we should tag military bases with their
>> function/component rather than solely grouping them by service owner.  For
>> the example[2], the base could conceivably be tagged something like:
>>
>> name=Wheeler Army Airfield
>> landuse=military
>> military=base
>> military_service=army
>> military_function=air
>> operator=United States Army
>>
>> I went with military_function over military_component in this example.
>>  "Component" is the more typical term in military doctrine but "function"
>> is probably better understood by mappers.
>>
>> military_function could include: ground/land, air, maritime, space,
>> law_enforcement, logistics ... etc as needed to cover military organization
>> in different countries.
>>
>> Having both aspects gives mappers in different countries the flexibility
>> to combine service and functional aspects of military bases to create a
>> more accurate tagging.  In addition, from a data consumer, there is a
>> difference between "show me all the air force bases" and "show me all of
>> the military air bases".
>>
>
> May also make things a bit awkward? eg Holsworthy Barracks that I think I
> mentioned earlier
> https://www.openstreetmap.org/way/474902706#map=14/-33.9772/150.9641, is
> an Army base, that has infantry here, artillery ther, armour across that
> side, engineers over the back, commandos down in the bush, together with an
> Army Aviation airfield. What do you call it in one simple word?
>

As a general rule, I think just "army base" is sufficient for a
hypothetical multi-function base occupied by an army service. However, I
note from Wikipedia's discussion of that base:

"Holsworthy Barracks (ICAO: YSHW) is an Australian Army military barracks
[...] is part of the Holsworthy military reserve, which is 22,000-hectare
(54,000-acre) training area and artillery range for the Australian Army,
[...] Holsworthy Military Airport is also located in the reserve."

It calls out "Holsworthy Barracks", "Holsworthy military reserve", and
"Holsworthy Military Airport" as separate places.  Wikipedia seems to think
these are different things, and it seems like we should have tagging that
can describe the differences.  "Holsworthy Military Airport" sounds like a
perfect example of an army base that is performing air component
functions.

>From a data consumer perspective, if I wanted to calculate the number of
hectares that Australia's military dedicates to aviation, it would be
desirable to have a way to do that by querying for both air force bases as
well as bases operated by other services that perform an air warfare or
aviation function.  Or perhaps I wish to generate detailed breakdowns of
how military land is allocated based on both service and function.

Don't take this as criticism, as I fully support the proposed
military_service tag.  But -- I can already envision the mis-tagging that
may occur the first time a mapper encounters a military base that "quacks
like a cow" and goes to the wiki and there isn't an obvious way to tag
these differences beyond the "name" tag.  We have an opportunity here to
make the tagging more fully descriptive to indicate both the service that
operates a base as well as the overall military purpose for bases that are
specialized.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed feature - RFC - Military Bases

> The Wikipedia pages on the Royal Navy, Royal Air Force and British Army
>> use "military service"
>>
> sometimes too, and mention the overall "British Armed Services", "Her
>> Majesty's Naval Service", etc.
>>
>
> The same goes for the dialect spoken by that page's author.
>
> However, whilst only the military services in the UK are armed forces,
> police in
> the US are generally armed.  So there would be confusion if we used UK
> terminology here.
>

There is no confusion in the US, the term "armed forces" specifically means
the military, and would never ever be confused with the local police, or
your armed neighbor Billy Bob.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed feature - RFC - Military Bases

"Service" is the right term for what is being described (e.g. army, navy,
air force, etc), and is consistent with UK terminology[1].

However, it also assumes that every country's military forces are neatly
grouped into these categories.  The Chinese military is particularly
complex - the Chinese navy and air force are part of the army.  Some
countries have domestic police forces that are part of the military.  Saudi
Arabia, for example, has a separate air force and air defense force
organzied as separate services, the latter being carved out of the army in
the 1980s; tagging both as military_service=air_force would not be quite
right.

Services often cross functions; for example, the US Army operates air
fields[2].  Tagging this military_service=army would be accurate, but would
not convey that this is an air force base, but not an Air Force base.

To get around all of this, we should tag military bases with their
function/component rather than solely grouping them by service owner.  For
the example[2], the base could conceivably be tagged something like:

name=Wheeler Army Airfield
landuse=military
military=base
military_service=army
military_function=air
operator=United States Army

I went with military_function over military_component in this example.
 "Component" is the more typical term in military doctrine but "function"
is probably better understood by mappers.

military_function could include: ground/land, air, maritime, space,
law_enforcement, logistics ... etc as needed to cover military organization
in different countries.

Having both aspects gives mappers in different countries the flexibility to
combine service and functional aspects of military bases to create a more
accurate tagging.  In addition, from a data consumer, there is a difference
between "show me all the air force bases" and "show me all of the military
air bases".

[1]
https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/389755/20141208-JDP_0_01_Ed_5_UK_Defence_Doctrine.pdf

[2] https://en.wikipedia.org/wiki/Wheeler_Army_Airfield

On Thu, Dec 10, 2020 at 12:08 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Wikipedia says: "The British Armed Forces, also known as Her Majesty's
> Armed Forces, are the military services responsible for the defence of the
> United Kingdom"... so perhaps the best British term is "military service"?
>
> The Wikipedia pages on the Royal Navy, Royal Air Force and British Army
> use "military service" sometimes too, and mention the overall "British
> Armed Services", "Her Majesty's Naval Service", etc.
>
> Disclaimer: I don't speak the British dialect of English (aka "Her
> Majesty's English?" :-) )
>
> -- Joseph Eisenberg
>
>
> On Thu, Dec 10, 2020 at 3:55 AM Paul Allen  wrote:
> >
> > On Thu, 10 Dec 2020 at 07:28, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >>
> >>
> >> So I suggest military_branch=* or military_service=* for the key.
> >>
> >> Though this is based on my US English understanding of the military
> terminology. Do they call them "military service branches" in British
> English too?
> >
> >
> > "British Armed Forces."  More formally, "Her Majesty's Armed Forces."
>  See
> > https://en.wikipedia.org/wiki/British_Armed_Forces  Not a suitable term
> for use
> > outside of the UK.  "Armed Forces" would be applicable outside the UK but
> > I'm not sure how well it would be understood by, say, the US.  The
> Wikipedia
> > article says that British Armed Forces are the military services in the
> UK,
> > so military_service might be the best option.  OTOH, the sidebar of
> > that article refers to the Navy, Army and Air Force as service branches,
> > so military_branch or military_service_branch would probably work.
> >
> > --
> > 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

>
> We have examples in the UK, even on major roads like the A346 between
> Marlborough and Swindon. I don't think they are tagged.



> with sophisticated routers issuing an alarm on approach might be
> something in the future. These dips are clearly signed.
>

You've just convinced me that this IS something that should be tagged!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

> Here are the ones that I think are worth considering:
>
>- Opening or swing bridge ahead
>
> This is already covered by the approved tag bridge:movable and its various
sub-keys that describe different types of movable bridges.  There were no
existing usages I could find under the hazard key, and the case of a
movable bridge _ahead_ sounds like a router problem.

>
>- Steep hill
>
> Covered by the approved key "incline"

>
>- Trams crossing ahead
>- Level crossing without barrier or gate
>- Frail (or blind or disabled) pedestrians crossing
>
> These are all versions of highway=crossing.  I have deliberately not
defined any crossing hazards as I feel they belong as part of that key,
which has its own hierarchy for different types of hazards.  If
highway=crossing and hazard= should be comingled, I think that is a
separate discussion that should be had.  But, to keep this "clean", I'm
specifically excluding highway=crossing hazards from consideration in this
go.  The only almost-exception is hazard=animal_crossing which is
specifically NOT a highway=crossing.

>
>- Pedestrians in road ahead [no sidewalk]
>
>  Already covered in the proposal with hazard=pedestrians

>
>- Overhead electric cable
>
> Overhead powerline cables are already mapped, it seems that would be
sufficient to know that there is an overhead cable.  There is zero existing
usage that I can find under any tag value for indicating this type of
hazard beyond the geometry of a power line drawn over the road.  As such, I
would exclude this case from this pass as potentially
controversial/duplicative with existing tagging.

>
>- Sharp deviation of route
>
> Already covered in the proposal as a hazard=turn.  I have not added
additional tagging to describe the sharpness of the turn because that fact
is already evident in the way geometry.

>
>- Ice
>
> This is a good suggestion, and I will add hazard=ice which has a handful
of usages.  It is distinctly different from hazard=frost_heave and will
cover the various versions of "bridge freezes before roadway" and so
forth.

>
>- Hidden dip
>
> Maybe.  There is a barely used tag hazard=dip.  Is this a permanent
feature?  I usually see these in relation to road construction.  Note that
speed dips are already covered under the key traffic_calming, so this would
have to describe a permanent, signed dangerous feature that wasn't put
there for traffic control reason.


> One not covered there is the warning that a route is unsuitable for long
> vehicles.  There are a few minor roads near me like that.  Drive a long
> vehicle along them and (at best) you have a long reverse or (at worst)
> you get stuck.
>

Since we have tags to describe the width of roads, and the ways making them
up have a geometry associated with them, it seems that this is something
that routers could simply calculate based on existing tagging.  In order to
avoid tags which might be controversial or redundant with other tagging, I
would not include this -- similar to a "narrow road" hazard which I have
chosen to exclude for the same reason.  I feel that these cases are
potentially more complex and deserve a separate consideration and/or
proposal.



> Also, in the UK, the sign for unexploded ordnance is the same as you
> have for minefields.  That symbol first appeared in UK Defence Standard
> 05-34, Marking of Service Matériel, and was called (bizarrely) "Unexploded
> explosive ordnance" (if it has exploded it would no longer be explosive,
> and if it's explosive then it must be unexploded).  In old money it
> would have been called "unexploded bomb."
>

Thanks!  This is not a sign I normally see on my daily commute :)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

> I'd suggest fallen_rock and low_flying_aircraft as tag values based upon
>
the common case but have the proposal mention their secondary application.
>

I actually have low_flying_aircraft in the proposal as a value, though I
just discovered that there is a more common value in use, "air_traffic" (88
usages).  However, I agree with the suggestions that low_flying_aircraft is
the better tag value and will add "air_traffic" to the deprecation list.

I will wait to see if I hear more from others about fallen vs falling
rocks, but I note your comments and Kevin's also.


> I think there may be other hazard warning signs in that document for you to
> consider.
>

Many of the signs on that list are already described by other tags.  For
example, the "yield" sign is covered by highway=give_way.  In general, I
think we have that list pretty well covered, though there may be one or two
more obscure cases.  Are there specific signs you feel are missing from the
hazard key?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

I have found examples of both falling rock[1] and fallen rocks[2] on
signage and it's not clear to me which is the more common.

There are >50 usages of hazard=falling_rocks and only 3 usages of "Fallen
rock" (with incorrect space and capitalization), so I went with what was
most commonly tagged.  I am not opposed to abandoning this minor usage of
falling_rock and replacing it with a new fallen_rock if that's the
consensus.

Are others in favor of dropping falling_rocks for fallen_rocks?

[1]
https://commons.wikimedia.org/wiki/File:Falling_Rock_-_Colorado_Mountains_(44651781425).jpg
[2] https://commons.wikimedia.org/wiki/File:NYS_NYW4-14.svg

On Wed, Dec 9, 2020 at 8:37 AM Paul Allen  wrote:

> On Wed, 9 Dec 2020 at 13:13, Brian M. Sperlongano 
> wrote:
>
> Add hazard=falling_rocks, landslide; deprecate rock_slide, rockfall
>>
>
> Kevin Kenny argued (I think convincingly) that the hazard is fallen, not
> falling, rocks.  There is a very slight risk that a rock will fall on your
> vehicle but the greater risk, by far, is that you will drive into a fallen
> rock.
>
> Editors could make both fallen and falling searchable, and identify
> the preset as "falling/fallen rocks," so we might as well make the
> value reflect the really big risk rather than the very small one.
>
> --
> 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] RFC - Hazards - 2 Week Update & RFC Summary