[Tagging] Feature Proposal - RFC - Street vendors

[map...@t-online.de]

Hi all,
 
I propose to deprecate street_vendor=* and to tag mappable street vendors 
with amenity=street_vendor + vending=* + opening_hours=* instead.


Please discuss this proposal on its Wiki Talk page.
 
Cheers,
 
Freetz
 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Graeme Fitzpatrick]

On Mon, 7 Nov 2022 at 09:30, Jmapb  wrote:

> "Lifeboat" is an ambiguous term  -- it even has a disambiguation page on
> Wikipedia  which lists https://en.wikipedia.org/wiki/Lifeboat_(shipboard)
> ahead of https://en.wikipedia.org/wiki/Lifeboat_(rescue) .
>
Yes, that is a possibility, although =lifeboat_station should remove any
ambiguity?


> Favoring emergency=marine_rescue seems sensible to me.
>
& turning that around, a number of previous comments were concerned that
"marine rescue" was only in the open sea, thus ignoring rescue groups in
inland rivers & lakes?

Thanks

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

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Jmapb]

On 11/6/2022 6:18 PM, Graeme Fitzpatrick wrote:



I definitely agree that it should be emergency=, rather than amenity=. 
I must also admit to a slight personal preference for =marine_rescue 
:-), but the vast majority of usage is in the UK & Western Europe, 
where =lifeboat seems to be the most popular, so I'm happy to go along 
with that.


I'll see if there's any other comments before starting a full RFC


"Lifeboat" is an ambiguous term  -- it even has a disambiguation page on 
Wikipedia  which lists 
https://en.wikipedia.org/wiki/Lifeboat_(shipboard) ahead of 
https://en.wikipedia.org/wiki/Lifeboat_(rescue) .


Favoring emergency=marine_rescue seems sensible to me.

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

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Graeme Fitzpatrick]

On Sun, 6 Nov 2022 at 19:08, Illia Marchenko 
wrote:

> One tag is enough. I prefer emergency=lifeboat_station  because
> "emergency" is a narrower key.
>

Thanks, Illia.

I definitely agree that it should be emergency=, rather than amenity=. I
must also admit to a slight personal preference for =marine_rescue :-), but
the vast majority of usage is in the UK & Western Europe, where =lifeboat
seems to be the most popular, so I'm happy to go along with that.

I'll see if there's any other comments before starting a full RFC

Thanks

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

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

[Minh Nguyen]

Vào lúc 04:43 2022-11-06, bkil đã viết:

That's an interesting problem. Does the mediawiki API support CORS? If
yes, we could easily create a very simple third party GUI form for it
just for voting or adding a new comment on the talk page.


In addition to the osm-proposals site, Martin is developing a MediaWiki 
extension that would make it easier to vote on a proposal. [1][2][3]


[1] 

[2] 

[3] 



--
m...@nguyen.cincinnati.oh.us



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

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

[ael via Tagging]

On Sun, Nov 06, 2022 at 08:15:05PM +0100, Mateusz Konieczny via Tagging wrote:
> > 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.
> >
> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
> I added link to it at
> https://wiki.openstreetmap.org/wiki/Proposal#Lists_of_proposals

Thanks.

ael


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

Re: [Tagging] Easy way to find proposals [was: Healthcare]

[Mateusz Konieczny via Tagging]

Note that any proposals from
https://wiki.openstreetmap.org/wiki/Category:Archived_proposals
will be skipped in this listing.

Nov 6, 2022, 18:13 by zelonew...@gmail.com:

> 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 <> tagging@openstreetmap.org> 
> > 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

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

[Mateusz Konieczny via Tagging]

Nov 6, 2022, 13:27 by tagging@openstreetmap.org:

> 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.
>
https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
I added link to it at
https://wiki.openstreetmap.org/wiki/Proposal#Lists_of_proposals

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

Re: [Tagging] Proposal process [was: healthcare]

[Minh Nguyen]

Vào lúc 03:26 2022-11-06, 
m...@marcos-martinez.net đã viết:
Some time ago I asked Alexander Borsuk (Organic Maps). The context was 
the debate on the "contact" controversy but it can be extended to other 
less heated topics... (The conversation was in the open OM Telegram 
channel and can be found by everyone, so I am not disclosing opinion, 
subject to privacy)


The key sentences for me are:

"A bigger problem is different public transport schemes, where it’s way 
harder to write a “converter” from one into another. For example, subway 
map in Vienna was missing because local community decided that it’s ok 
to have two different level platforms in one stop_area. That is really a 
pain."


"...the proper way would be to merge into multiple values for one chosen 
tag (and filter duplicate values, of course). That’s a bit of a hassle, 
but it is solvable."


"Of course it is easier if all tags have the same scheme. Then we don’t 
spend our time on the scheme differences, focusing on a better product 
instead."


Let me ask you then: Can you provide evidence or a few examples in which 
tag standardization is harmful or represents any disadvantage?


Data consumers aren't a monolith. Churn in our tagging schemes can break 
existing software and harm end users in the real world, unless we set up 
migration paths and raise awareness. Conversely, if we don't clean up 
our tagging schemes at all, then we make it harder for developers to 
adopt new kinds of OSM data effectively.


Fortunately, there aren't too many high-profile examples of tagging 
churn deliberately breaking data consumers. This community has been 
careful to preserve backwards compatibility -- you might say too 
careful. One example I'm aware of is that, for years, the definition of 
highway=trunk in the United States had differed from the global 
definition, focusing on physical characteristics, but since last year 
there has been an effort to harmonize the definition and shunt the 
physical characteristics over to expressway=yes. [1] This will require 
changes to some routers such as Valhalla that include highway=trunk in 
the "Avoid Highways" option, under the assumption that this tag 
consistently indicates an expressway.


Sometimes breakage happens unintentionally. Several years ago, I and 
other mappers in the U.S. and Canada started using 
restriction=no_left/right_turn_on_red to indicate a turn-on-red 
restriction, which up to that point had no established tagging. [2] This 
*_on_red suffix briefly broke OSRM, which had been relying on an obscure 
clause that someone inserted into the restriction=* page stating that 
data consumers could ignore everything after the no_* or only_* prefix. 
Since turn-on-red restrictions are very common in downtown areas, these 
restrictions effectively made it impossible to route through these 
areas. Whoever added this clause to the wiki had good intentions for 
making OSM easier and more elegant to use, but data consumers noticed it 
before mappers did. Ironically, it was a premature optimization: OSRM 
ultimately required nothing more than a one-line change. [3]


To the extent that we care about both new and existing data consumers, 
we should strive to balance their disparate needs. One reason that 
dual-tagging grace periods last so long is that we don't have a very 
clear understanding of who all is using OSM and how, but we know of 
plenty of software that's still in use but no longer maintained. 
Software engineers refer to Hyrum's law [4] as shorthand for the fact 
that churning an API will always break someone, even for the silliest of 
reasons. [5]


Breaking changes are sometimes unavoidable, but there should be a 
convincing reason for the breakage when the stakes are high. Otherwise, 
the impact to OSM's reputation would be higher than any upfront 
messiness, which we already mitigate by providing a critical mass of 
data that you can't find anywhere else. Sometimes a convincing reason 
could be that the old tag is getting in the way of mapping things we 
want to map but can't express using existing tags. The 
crossing:markings=* proposal didn't deprecate crossing=* [6], but I 
think future proposals could chip away at crossing=*, as we find that 
there are more crossing configurations that we can't express using that 
key alone.


[1] https://wiki.openstreetmap.org/wiki/United_States/Highway_classification
[2] https://wiki.openstreetmap.org/wiki/No_turn_on_red
[3] https://github.com/Project-OSRM/osrm-backend/pull/4811
[4] https://www.hyrumslaw.com/
[5] https://xkcd.com/1172/
[6] https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:markings

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

[Minh Nguyen]

Vào lúc 00:23 2022-11-06, 
easbar.m...@posteo.net đã viết:
Ok, sure, as far as I am concerned it doesn't have to be `unrestricted` 
and could just as well be `none` or `no`.


But at least there seems to be consensus that
a) The `except` tag could/should be replaced with such a 
`no/none/unrestricted` value for the `restricted:` key


"Replaced" is too strong for now. I'd suggest pairing it with except=* 
until after a transition period, because the except=* key is already so 
entrenched among data consumers. The consequences of missing an 
exception are pretty severe. Dual tagging also mitigates the fact that 
this discussion has only involved a few of us. You never know what 
concerns will come out of the woodwork after the fact.


The length of the transition period is an open question. See the other 
thread about deprecating amenity=hospital in favor of healthcare=hospital...


b) Using `restriction:` and `restriction` for the same relation should 
be discouraged except for using `restriction:xyz=no/none/unrestricted`


This is an interesting way of putting it, that a key should have only 
one possible value, apart from conditionals. But I guess we already have 
some keys like that, such as noname=*.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Easy way to find proposals [was: Healthcare]

[ael via Tagging]

On Sun, Nov 06, 2022 at 12:13:01PM -0500, Brian M. Sperlongano wrote:
> You should bookmark this site to keep track of proposals:
> 
> https://osm-proposals.push-f.com/

Thanks for that, but it doesn't work. Not on firefox with noscript
enabling the site.

It does seem to work on palemoon.

But I am not going to remember to look through my bookmarks in a year or
so: that link or whatever need to be on the wiki is an obvious place.

ael



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

[Tagging] Easy way to find proposals [was: Healthcare]

[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

Re: [Tagging] Proposal process [was: healthcare]

[mail]

Hi Martin,

you are comparing the wrong things.

What I tried to say: Generally speaking we should strive for improving 
things. As we are talking about a database, standardization can be part 
of the solution and should be something considered desirable. It 
shouldn't be a valid argument against it to say "we can also use a 
workaround, you see? It's only requires a little more effort and still 
provides the same result." Give me one reason for not doing it right 
from the start.


I didn't compare OSM with sand and didn't advocate at all to move it 
with a caterpillar. But let me take it further:


The sandcastle is actually a pretty good example for how OSM works. At 
the beginning people started to put the big chunks at the bottom, they 
were few and pretty soon were able to agree on building some kind of 
solid foundation (highways and buildings are generally speaking a de 
facto standardization right now) but with time more and more people got 
involved and started doing their own things and it has become 
increasingly difficult to agree on how to build them, making it more 
unstable (nowadays the only thing we know for sure when tagging 
something as " forest" or "wood" is that you will probably find some 
trees there. Additional value doesn't exist). More and more details and 
decoration is being built on top of it and the castle is more and more 
shaking. To fix things you now must use a tiny spoon to prevent the 
whole construction from coming down. Something that will happen on it 
sown the higher you build it without a proper structure below.


Can we change it without destroying the whole castle? Sure, it is up to 
us. We should be able to decide what should be the means, the time and 
extend of what we want to amend, modify and improve according to its 
importance within the castle and its benefits. We should be able to 
decide that at least from now on we want any addition to be more 
structured and agreed on, if necessary with documented, local variations 
and exceptions, so that other people can build more safely on top. As I 
say, it is up to us and this community is full of competent and 
dedicated people, capable of finding the right balance.


But only if we wanted to, because right now this doesn't exist and the 
castle keeps growing in size and instability.


Cheers

Am 06.11.2022 13:00, schrieb Martin Koppenhoefer:


sent from a phone


On 6 Nov 2022, at 12:34, m...@marcos-martinez.net wrote:

Regarding standardization: First of all, I hope we all work on the 
basis that we want to improve things. Can you move a ton of sand with 
a spoon?


thing is, we don't have just a heap of sand, we have hundreds of 
thousands of people having contributed by adding small parts of a 
gigantic castle like structure made of sand, and these people expect 
following mappers to use spoons so that the initial work isn't 
inadvertently destroyed, as would be the case when moving the castle 
with a caterpillar.


They also object to people who propose changing the sand underneath the 
visible structure with sand of a different color, because they fear it 
could make the whole structure collapse and because it won't be visible 
anyway. ;-)

___
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 - Healthcare 1.1 - General comment

[bkil]

That's an interesting problem. Does the mediawiki API support CORS? If
yes, we could easily create a very simple third party GUI form for it
just for voting or adding a new comment on the talk page.

On Sun, Nov 6, 2022 at 1:31 PM 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.
>
>
> I would also comment that when I had decided to vote on another
> proposal some time ago, it was not an easy process and seemed to involve
> editing a page in what was not an immediately obvious way. I gave up for
> lack of time. Note that I do program in several languages, so I
> possibly have more expertise and experience than many mappers.
>
> There are only a tiny number of people who vote on these proposals,
> and while there is maybe a small audience on this list who even know,
> I wonder how many even then are put off by the non obvious voting
> process. Or is it just me?
>
> 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] Feature Proposal - Voting - Healthcare 1.1 - General comment

[ael via Tagging]

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.


I would also comment that when I had decided to vote on another
proposal some time ago, it was not an easy process and seemed to involve
editing a page in what was not an immediately obvious way. I gave up for
lack of time. Note that I do program in several languages, so I
possibly have more expertise and experience than many mappers.

There are only a tiny number of people who vote on these proposals,
and while there is maybe a small audience on this list who even know,
I wonder how many even then are put off by the non obvious voting
process. Or is it just me?

ael


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

Re: [Tagging] Proposal process [was: healthcare]

[Martin Koppenhoefer]

sent from a phone

> On 6 Nov 2022, at 12:34, m...@marcos-martinez.net wrote:
> 
> Regarding standardization: First of all, I hope we all work on the basis that 
> we want to improve things. Can you move a ton of sand with a spoon?


thing is, we don’t have just a heap of sand, we have hundreds of thousands of 
people having contributed by adding small parts of a gigantic castle like 
structure made of sand, and these people expect following mappers to use spoons 
so that the initial work isn’t inadvertently destroyed, as would be the case 
when moving the castle with a caterpillar. 

They also object to people who propose changing the sand underneath the visible 
structure with sand of a different color, because they fear it could make the 
whole structure collapse and because it won’t be visible anyway. ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal process [was: healthcare]

[mail]

Hi Brian,

I appreciate all the effort you underwent with the "river tagging 
scheme. I do mean it. And I support it. Now, the process to achieve it 
seems ridiculously hard. You say people "reached out across many 
channels to discuss the proposed changes",  "I had to discuss the 
specifics of river tagging with many many people. Those people talked to 
other people." They "generated statistics, procedures, and 
visualizations of our progress". And in spite of 99% completion I 
personally could just go out and tag the old way with anyone having the 
right to "correct" it if I was willing to fight for it. This is why the 
process is dysfunctional. It is dysfunctional because there is no 
established path which people you need to talk to, which software 
support you need and how to do it, how many people you need to convince, 
etc.


Sometimes you can be lucky. People like you can make a huge effort and 
what is proposed is overwhelmingly convincing. I won't deny that in 
those cases things can happen. At least from what I see here, if this 
isn't the case there is no way to reach any decision that really means 
something.


I still don't understand why we are not able to create a space where all 
these people you mention can come together, discuss a scheme and the 
community finally adopts it - or not. It would be exactly the same as 
what you have done but in less time, with less effort, more transparent 
an inclusive. A space where regular mappers, software developers and any 
other stakeholders know that THIS is the space where we come together to 
add, improve, modify things, a space where decisions are made and 
everybody can be heard. And most importantly to finally reach a 
conclusion on how we want to do things.


Regarding standardization: First of all, I hope we all work on the basis 
that we want to improve things. Can you move a ton of sand with a spoon? 
Sure, but it will take you days and with an excavator you are done in 5 
minutes. My point is that you CAN do something or that somethings WORKS 
doesn't mean we can do something or make that somethings works better.


Some time ago I asked Alexander Borsuk (Organic Maps). The context was 
the debate on the "contact" controversy but it can be extended to other 
less heated topics... (The conversation was in the open OM Telegram 
channel and can be found by everyone, so I am not disclosing opinion, 
subject to privacy)


The key sentences for me are:

"A bigger problem is different public transport schemes, where it's way 
harder to write a "converter" from one into another. For example, subway 
map in Vienna was missing because local community decided that it's ok 
to have two different level platforms in one stop_area. That is really a 
pain."


"...the proper way would be to merge into multiple values for one chosen 
tag (and filter duplicate values, of course). That's a bit of a hassle, 
but it is solvable."


"Of course it is easier if all tags have the same scheme. Then we don't 
spend our time on the scheme differences, focusing on a better product 
instead."


Let me ask you then: Can you provide evidence or a few examples in which 
tag standardization is harmful or represents any disadvantage?


Cheers

Am 06.11.2022 01:00, schrieb 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 

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

[Cartographer10 via Tagging]

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

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Illia Marchenko]

One tag is enough. I prefer emergency=lifeboat_station  because "emergency"
is a narrower key.

вс, 6 нояб. 2022 г., 9:17 Graeme Fitzpatrick :

> Some time ago, I raised a proposal for Marine Rescue stations:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Marine_rescue.
> After a few weeks, I returned it to draft status, pending the resolution of
> the Military Bases proposal which was also going through at that time, but
> despite that, it’s now in use ~250 times!
>
>
> One of the concerns that were raised at the time was the existence of two
> other, similar tags: emergency=lifeboat_station 
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeboat_station
> &
> 
> also amenity=lifeboat_station
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlifeboat_station, both
> of which were created by the same mapper on the same day, & neither of
> which were apparently ever discussed?
>
>
> These two tags have been used a similar number of times (400 – 450), but
> when I’ve looked at a number of them at random, both tags have been used
> together on a lot of locations e.g
> https://www.openstreetmap.org/way/260096274,
> https://www.openstreetmap.org/way/894864797, &
> https://www.openstreetmap.org/way/444884651.
>
>
> It would seem somewhat ridiculous to have three virtually identical tags
> describing the same thing, as well as two tags on the same POI, so I am
> suggesting that they all be consolidated into one tag, with the other two
> being deprecated.
>
>
> Before proceeding with that discussion though, is there any reason to tag
> something as both an amenity= & also emergency=?
>
>
> 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] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

[easbar . mail]

Ok, sure, as far as I am concerned it doesn't have to be `unrestricted` 
and could just as well be `none` or `no`.


But at least there seems to be consensus that
a) The `except` tag could/should be replaced with such a 
`no/none/unrestricted` value for the `restricted:` key
b) Using `restriction:` and `restriction` for the same relation should 
be discouraged except for using `restriction:xyz=no/none/unrestricted`


?

On 01.11.22 19:03, Minh Nguyen wrote:


I do like this idea for its elegance. I goofed up above, intending to 
add both except:network and except:network:wikidata, but you get the 
gist. Perhaps "unrestricted" could be simplified to just "none" for 
consistency with maxweight:*=none, which has been suggested for 
representing some weight restriction exceptions signposted in the U.S. [1]


This restriction:*=unrestricted idea would probably need to be paired 
with except=* usage for some time, just in case. Turn restrictions are 
so critical to routing that we should be very careful about introducing 
a new representation for exceptions. Back when 2013 when the 
type=restriction:* and day/hour_on/off syntaxes were deprecated, there 
wasn't any appreciable usage of turn restrictions for routing yet, but 
now there are a lot of users who rely on turn restrictions, especially 
in complex environments like the ones we're discussing.


[1] 
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2428787#United_States




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

[Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Graeme Fitzpatrick]

Some time ago, I raised a proposal for Marine Rescue stations:
https://wiki.openstreetmap.org/wiki/Proposed_features/Marine_rescue. After
a few weeks, I returned it to draft status, pending the resolution of the
Military Bases proposal which was also going through at that time, but
despite that, it’s now in use ~250 times!


One of the concerns that were raised at the time was the existence of two
other, similar tags: emergency=lifeboat_station
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeboat_station
& also amenity=lifeboat_station
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlifeboat_station, both of
which were created by the same mapper on the same day, & neither of which
were apparently ever discussed?


These two tags have been used a similar number of times (400 – 450), but
when I’ve looked at a number of them at random, both tags have been used
together on a lot of locations e.g
https://www.openstreetmap.org/way/260096274,
https://www.openstreetmap.org/way/894864797, &
https://www.openstreetmap.org/way/444884651.


It would seem somewhat ridiculous to have three virtually identical tags
describing the same thing, as well as two tags on the same POI, so I am
suggesting that they all be consolidated into one tag, with the other two
being deprecated.


Before proceeding with that discussion though, is there any reason to tag
something as both an amenity= & also emergency=?


Thanks

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