Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

[osm.tagging]

I've just checked the history, and as far as I can tell, there has been a grand 
total of just 15 proposals put to voting since the beginning of the year (5 
months, so 3 per month on avg.)

Also, even with all the noise, there have been only about 28 messages per day 
on avg, which is less then most other mailing lists and forums I follow.

I agree that there has been some unnecessary noise, most of it caused by less 
than a handful of people.

Overall, I don't think there is any issue here that needs to be urgently 
addressed.

> -Original Message-
> From: Simon Poole 
> Sent: Sunday, 2 June 2019 18:48
> To: Tag discussion, strategy and related tools
> 
> Subject: [Tagging] A modest proposal to increase the usefulness of
> the tagging list
> 
> As a reader of this list I'm slightly overwhelmed by it right now.
> 
> Besides the longish off topic discussions that should have been held
> somewhere else, we've had a massive increase in the number of
> proposals and comments on these. As these typically will require
> looking at the proposal, potentially commenting on its talk page and
> here, the increase in noise has led to even a cursory examination of
> proposals for obvious flaws (see the police proposal) not being
> possible at the current rate of a new proposal every second day.
> 
> In the interest of keeping the list at least half usable, I would
> suggest that we all, starting now, voluntarily submit to:
> 
> - not posting more than 30 times per month (the 30 comes from the
> WMF mailing lists, where it seems to work quite well)
> 
> - not more than one proposal per person per month
> 
> - not more than 4 new proposals per month in total
> 
> Simon
> 




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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

Yes, but that’s not the point.

 

The presence or absence of markings do not change the fundamental operating 
principle of the crossing (go only when it’s green).

 

The strips shown in the image you linked do not mean that pedestrians have 
priority here and can just walk across any time, no matter what the signal says.

 

The crossing would work exactly the same with and without these strips.

 

 

From: Simon Poole  
Sent: Saturday, 25 May 2019 20:25
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: 
crossing=marked/unmarked vs crossing:markings=yes/no

 

 

Am 25.05.2019 um 02:18 schrieb Paul Allen:

 

+1 for "mutually exclusive."  Except, perhaps, in Poland.  I'm still waiting 
for an answer on that one.

 

 

Traffic signal controlled crossings with markings (including stripes of some 
colour) exist (not claiming that they are "common") at least all over central 
Europe (as pointed out in one of the contributions a couple of 100 postings 
back, they will typically control the vehicle traffic too). Random example 
https://www.mapillary.com/app/user/sp8962de?menu=false 

 
=photo=47.4040085=8.3944280902=15.17281376123384=true=zL2pXJc6T_RffQheFsdbYA
 

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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

From: Paul Allen  
Sent: Saturday, 25 May 2019 10:18
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: 
crossing=marked/unmarked vs crossing:markings=yes/no

 

The labels chosen for these 4 categories are : no, unmarked, uncontrolled, 
traffic_signals. But they may as well have been a, b, c, d. Don’t try to 
interpret anything more into the label.

 

e: controlled (crossing guard/lollipop person).

 

That is not one of the broad categories defined on the wiki. Though the value 
has been used about 1k times.

 

According to the wiki, the correct way to tag such a crossing would be to add a 
supervised=yes tag together with an appropriate crossing=* tag, This 
combination of crossing and supervised has been used 44k times, so seems to be 
significantly more popular.

 

Which makes some sense, because I’ve seen (in the real world) both unmarked and 
“uncontrolled” (which, granted, shows that that isn’t a particularly good label 
for the concept it’s meant to represent, if people try to interpret a meaning 
into it) crossings that at certain times are supervised. But such supervision 
is generally not present 24/7, so in other times it usually is simply a normal 
unmarked or uncontrolled crossing.

 

 

These are the 4 different mutually exclusive types of crossings that need to be 
distinguished.

 

+1 for "mutually exclusive."  Except, perhaps, in Poland.  I'm still waiting 
for an answer on that one.

 

I’m still thinking you’ve been misinterpreting the messages in that regard.

 

We may need clearer documentation, particularly country-specific documentation. 
 Maybe also

editor presets with country-specific intelligence.

 

Looking at the wiki, the documentation could definitely use some work. But the 
fundamental concepts of the existing tagging scheme seem fine.

 

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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

 

 

From: Warin <61sundow...@gmail.com> 
Sent: Saturday, 25 May 2019 09:49
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: 
crossing=marked/unmarked vs crossing:markings=yes/no

 

On 25/05/19 07:32, Paul Allen wrote:

On Fri, 24 May 2019 at 22:12, Kevin Kenny mailto:kevin.b.ke...@gmail.com> > wrote:


Yeah, there really are combinations around here:

does it have signs?
does it have traffic signals?
does it have specific pedestrian-facing traffic signals? (Some
intersections just have you cross at the same time as motor traffic in
your direction rolls)
are the traffic signals pedestrian- or cyclist-controlled? (Is there a
button for you to push?)
does it have pavement markings?


We also have;
tactile paving - a sequence of small raised bumps/dots on the paving that can 
be sensed by walkers/wheelchairs
audio warning - the button also has an audio output that signals when the 
traffic lights state to allow pedestrian crossing, and just before the 
pedestrian crossing closes.



And none of that matters for the broad classification that the crossing=* key 
does, which is:

 

*   You can’t cross here

 

*   You can cross here, but there is no special legal status to it

 

*   You can cross here, and it is a designated crossing place with some 
kind of special legal status (that in most jurisdictions prioritizes 
pedestrians over vehicles, specifics depend on local jurisdiction)

 

*   You can cross here, and there is a traffic signal that tells you 
exactly when you can and can’t cross that you have to follow

 

The labels chosen for these 4 categories are : no, unmarked, uncontrolled, 
traffic_signals. But they may as well have been a, b, c, d. Don’t try to 
interpret anything more into the label.

 

These are the 4 different mutually exclusive types of crossings that need to be 
distinguished. Additional tags can provide further details, but don’t 
fundamentally change the type of crossing from one of these 4.

 

In different jurisdictions, there may be multiple legally categorized 
variations of these 4 broad types. That’s what the crossing_ref tag is for.

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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

 

> What can be done here is to basically define that the different crossing=* 
> values imply default values for various other tags (the same way as the wiki 
> currently already documents what e.g. crossing=zebra or crossing=pelican 
> implies).

 

I'm interested in this, in theory, but doesn't it actually imply redefining 
those 2.5 million tags? Previous mappers were never told these meanings, nor do 
I think they had them in mind. Redefining those tags post-hoc is actually a 
harder problem to address via editors / QA / data consumption than deprecation.

 

Nothing I said changes the meaning of any existing tags. You seem to be one of 
very few people that is incapable of understanding the existing tags, and you 
shouldn’t be projecting your seeming inability to understand them onto all 
mappers.

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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

 

 

From: Paul Allen  
Sent: Saturday, 25 May 2019 06:17
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: 
crossing=marked/unmarked vs crossing:markings=yes/no

 

 

crossing=uncontrolled – there are road markings indicating this is a designated 
pedestrian crossing, but no traffic signals that explicitly tell pedestrians 
when they have to stop

 

Yes, but.  At least in the UK those road markings not only indicate a 
designated crossing but also

give the pedestiran right of way.  Once the pedestrian places a foot (or a 
wheel of a buggy or

wheelchair) on the crossing the motorist MUST stop.  If the pedestrian is not 
on the crossing

the motorist can blithely proceed.

 

Yes, I would assume that’s the same in most jurisdictions, designated 
pedestrian crossings give pedestrians priority.

 

In cases where the exact type of marking is important, that’s what the 
crossing_ref tag is for, which has to be interpreted under consideration of 
local legislation.

 

 

Yep.

 

That was how I interpreted it all until the Polish contingent threw a spanner 
in the works.  I'm

waiting for a response to see if it's a big spanner or a little spanner.

 

All other crossing=* values that are currently in use are either simply 
undefined in meaning, or, like the ones listed in the wiki (zebra, pelican, 
toucan, …) are shorthand for one of the 4 values above + implicit values for 
additional tags.

 

Depending on the answer from Poland, we may have to drastically revise that and 
explicitly

tag crossing types.  It depends if zebra stripes in Poland are only in 
conjunction with traffic signals

(cosmetic road markings) or if they can be independent of signals and have 
different meanings.

 

I think there is a miscommunication there. It’s common in many countries that 
you have signal controlled crossing, and zebra strips as road markings. That 
does NOT imply that pedestrians can just walk across at any time and have 
priority. As long as the traffic lights are present, they take priority, and 
red means red.

 

I’m pretty sure it’s the same in Poland.

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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

> Does any of this change in a jurisdiction where there is an implied
> crossing at every intersection unless posted otherwise?

Such purely implied crossings would be crossing=unmarked, and under the "do not 
map local legislation" rule, I would only map them if they have a physical 
presence (e.g. lowered kerbs).

> What sort of feature gets tagged crossing=no? Does one draw a line
> or node to represent the footway that isn't there?
It's a tag that should be rarely used, and it's primary purpose is if there is 
a context in which people may think that there should be crossing here, to 
indicated that there really isn't one. Mainly to keep armchair mappers from 
later coming along and thinking "hey, someone forgot to tag the crossing" and 
add some other crossing=* value.

It's important to mention that crossing=no does NOT get a highway=crossing tag, 
to prevent data consumer that only look for highway=crossing and not interpret 
the crossing=* value from wrongly thinking there is a crossing here.



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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

The way I see it:

 

crossing=no – crossing here is not legal/possible

 

crossing=unmarked – there are no road markings (or traffic signals) that 
indicate this is a designated crossing, but based on other factors, it’s a 
location where pedestrians common cross, e.g. because of lowered kerbs, or 
because the sidewalk on one side of the road ended

 

crossing=uncontrolled – there are road markings indicating this is a designated 
pedestrian crossing, but no traffic signals that explicitly tell pedestrians 
when they have to stop

 

crossing=traffic_signals – there are explicit traffic signals that tell 
pedestrians when to stop. There are very likely road markings, but even if not, 
the absence of road markings, in the presence of actual traffic signals, is 
irrelevant for how this crossing operates. 

 

All other crossing=* values that are currently in use are either simply 
undefined in meaning, or, like the ones listed in the wiki (zebra, pelican, 
toucan, …) are shorthand for one of the 4 values above + implicit values for 
additional tags.

 

 

 

From: Paul Allen  
Sent: Saturday, 25 May 2019 05:53
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: 
crossing=marked/unmarked vs crossing:markings=yes/no

 

 

On Fri, 24 May 2019 at 20:06, mailto:osm.tagg...@thorsten.engler.id.au> > wrote:

 

As you said, what others suggested, and what would be a welcome addition, is to 
leave the existing tag untouched (it seems to work fine for most people except 
you), and tag the special exception where a crossing=traffic_signals doesn’t 
have road markings with crossing:markings=no

 

I think this is the nub of the issue: what is meant by crossing markings.  I 
think Nick's interpretation

is different from that of some on this list.  However, your paragraph seems to 
conform to Nick's

interpretation.  What do you mean by a crossing with traffic signals AND with 
road markings?

 

Hint: crossing=unmarked is defined as being a crossing without road markings or 
traffic

lights.  Have you ever seen a crossing with lights AND zebra stripes?  Which of 
the two takes

precedence?  Motorists have right of way if their signal is green; pedestrians 
have absolute

right of way just by stepping on the crossing irrespective of the lights.  Does 
not compute.

 

However, if you include the zig-zag lines before and after the crossing that do 
NOT define

the interaction of pedestrian and motorist but impose conditions on the 
motorist alone (cannot

park, cannot wait, cannot load or unload, etc) as being crossing_markings=yes 
then you have

the dangerous situation that the map leads people to think that a 
light-controlled crossing

(pedestrians and motorists are controlled by the lights) is a marked crossing 
(like a zebra)

where pedestrians have priority.  See the problem?  But I suspect this is 
Nick;s interpretation

of what a marked crossing is - there are some marks on the road (I can't make 
sense of his

proposals without that interpretation).

 

I don't consider the zig-zag markings before or after the crossing to be 
relevant to tagging the

crossing.  Any more than I consider a white line down the centre of the road to 
mean that it's

a marked crossing.  Those markings do not define pedestrian/motorist 
interaction.

 

I agree with Nick (that will surprise him) that these things matter.  Somebody 
with macular

degeneration may have lost all of their central vision.  It may be far easier 
to spot a zebra

stripe than to see the lights on crossing signals because of relative sizes.  
In fact, you don't

even have to see the stripes, just know that they are there, because 
pedestrians have priority.

That's why it's a bad idea to tag in a way that could lead somebody to conclude 
that a crossing

with signals is a marked crossing.  Instead of hunting for the button and 
listening for the signal,

they'll just step into the road knowing (incorrectly) that traffic will stop 
for them.

 

Could we make the tagging more explicit?  For sure.  Could we improve the 
documentation?  Yep.

Should we say that light-controlled crossings are marked?  Nope.  
traffic_signals and marking

are NOT orthogonal, they are mutually exclusive alternatives.  Well, in the UK 
they are - it's possible

there's some country where you can have  zebra-light-controlled crossings.

 

-- 

Paul

 

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

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[osm.tagging]

This is not in line with hat others have suggested, and invalidating 2.5 
million existing crossing=* tags (everything with a value different from 
yes/no) is a complete no go.

 

As you said, what others suggested, and what would be a welcome addition, is to 
leave the existing tag untouched (it seems to work fine for most people except 
you), and tag the special exception where a crossing=traffic_signals doesn’t 
have road markings with crossing:markings=no

 

What can be done here is to basically define that the different crossing=* 
values imply default values for various other tags (the same way as the wiki 
currently already documents what e.g. crossing=zebra or crossing=pelican 
implies).

 

 

From: Nick Bolten  
Sent: Saturday, 25 May 2019 03:55
To: Tag discussion, strategy and related tools 
Subject: [Tagging] Non-orthogonal crossing=* tag proposals: 
crossing=marked/unmarked vs crossing:markings=yes/no

 

In contrast, crossing:markings=yes/no would let us avoid making decisions about 
the "type" of crossing entirely. If it were swapped out for the 
crossing=marked/unmarked proposal, it would result in this schema for crossings:

 

crossing=no (for crossings that should be specifically called out as not 
doable/allowed)

crossing:markings=yes/no

crossing:signals=yes/no

crossing_ref=* (unchanged)

 

There has also been the suggestion that crossing=* could be left unchanged, and 
these two new tags added as alternatives. I like that this potentially avoids 
conflict and therefore makes it easier to start mapping this data separately, 
but think it would result in competing schemas and redundant data.

 

So, what are you thoughts? Is crossing:markings=yes/no better than 
crossing=marked/unmarked? Are there any downsides/upsides I've missed? If 
crossing:markings were preferable, what should happen to the crossing=* tag?

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

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[osm.tagging]

I’ve read that whole previous discussion, and from my point of view it was just 
a whole bunch of completely useless noise, with everyone telling you that you 
aren’t making sense and you ignoring it and bulldozing your way forward.

 

From: Nick Bolten  
Sent: Monday, 20 May 2019 10:48
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] "Unambiguous crossings" proposals and related questions

 

It's a little disappointing to see these points rehashed given the lengthy 
recent discussions, but at the risk of creating a new massive thread I'd like 
to clear some things up.

 

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

Re: [Tagging] "Unambiguous crossings" proposals and related questions

[osm.tagging]

"The "traffic_signals" namespace is used to describe both vehicular traffic 
signals and pedestrian/bicycle traffic signals, to everyone's confusion."

This statement is simply completely factually wrong.

a) traffic_signals is the *value* here, not the name of the tag

b) there are 2 distinct tags to describe the presence of traffic signals for 
the road way and foot/cycle way:

highway=traffic_signals for signals controlling traffic on the road
crossing=traffic_signals for signals controlling crossing pedestrians

"To make matters worse, it forces mappers to choose between tagging a 
crossing's markings, [...], or whether it has signalization."

Personally, I can not remember having ever seen, in my whole life, a signal 
controlled pedestrian crossing that does not have road markings, excluding 
cases where there are temporarily no road markings at all because they haven't 
been painted yet after the road has just been laid down or resurfaced.

And even if there should really be signal controlled crossings that on purpose 
do not have any road markings, I would consider that to be basically completely 
irrelevant. The presence of signals that control traffic and pedestrian 
movement supersedes the meaning any road markings might have. If a signal 
controlled crossing has road markings or not does not in any way change its 
operation.

Deprecating a tag that has been used almost 60 times and has widespread 
software support, just to replace it with a different tag that means exactly 
the same seems somewhat insane to me, and while I can't speak for anyone else, 
I can guarantee to always vote no for this.

"Replacing crossing=island" 

I can agree with this one, but it's essentially a non-issue as this has already 
been done. At most the wiki might need slight editing to make it more clear 
that the use of crossing=island has been deprecated.

"Replacing crossing=uncontrolled and crossing=zebra with crossing=marked"

crossing=uncontrolled and crossing=zebra have been used a combined 1.25 million 
times. In practical usage, they mean exactly the same thing, and they have 
widespread software support already. Trying to replace them with a 3rd value 
that still means exactly the same things is a classical case of 
https://xkcd.com/927/

Looking at taginfo, there are already 168281 cases of crossing=marked right 
now, so the unfortunate reality is that we already have the case of 3 different 
values meaning the same thing and no matter how much you try to dictate the 
usage of a particular one by fiddling with the wiki, it's unlikely that there 
will ever be a day when all 3 aren't in widespread use synonymously.

As such the best that can be done is to slightly adjust the wiki to document 
the reality that all 3 values are used synonymously.

All this basically leaves the crossing key with the following possible values:

no - there is no crossing possible/legal here

unmarked - there are no road markings or traffic signals here, but this is a 
place where people are generally (legally) cross the road, e.g. because of 
lowered kerbs, or because the sidewalk on one side of the road stops here, or 
some other indication that this is a commonly used crossing point.

uncontrolled/zebra/marked - there are road markings, but no signals that 
control traffic flow, that make it clear to both road and pedestrian traffic 
that this is a designated crossing point

traffic_signals - there are traffic signals here that control traffic flow, it 
is extremely likely that there are also road markings, but their presence or 
absence is irrelevant as it would not change how the crossing operates

I think you'll find that any proposal that tries to completely throw over this 
well-established tagging scheme is doomed to failure.

> -Original Message-
> From: Markus 
> Sent: Monday, 20 May 2019 00:37
> To: Tag discussion, strategy and related tools
> 
> Subject: [Tagging] "Unambiguous crossings" proposals and related
> questions
> 
> Hi Nick, hi everyone,
> 
> I welcome these proposals (crossing=marked, crossing:signals=* and
> footway=island) [1] to bring order to the pedestrian crossing
> tagging.
> Thank you, Nick, for your efforts so far!
> 
> I have two questions, not about the proposals themselves, but about
> pedestrian crossing tagging in general:
> 
>   * When the crossing type is tagged on the way (e.g.
> highway=footway
> + footway=crossing + crossing=marked + crossing:signals=yes), should
> the crossing type also be tagged (duplicated) on the crossing node
> or are routers able to get that information from the crossing ways?
> 
>   * Should the road be split for short refuge islands into two one-
> way ways? This would result in unusual maps, especially at
> crossroads
> (example: [2]).
> 
> [1]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Unambiguous_cr
> ossings
> [2]:
> https://wiki.openstreetmap.org/wiki/File:Crossroads_with_traffic_isl
> ands.png
> 
> Regards
> 
> Markus
> 
> 

Re: [Tagging] Feature Proposal - crossing=marked

[osm.tagging]

People do generally walk on this “grass” sidewalk.

 

From: Martin Koppenhoefer  
Sent: Tuesday, 14 May 2019 16:04
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - crossing=marked

 

 

sent from a phone


On 14. May 2019, at 02:24, Graeme Fitzpatrick mailto:graemefi...@gmail.com> > wrote:

https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png

 

That one, I would have terminated the crossing at the marked road, rather than 
taking it to the other side

 

 

the lowered kerb clearly indicates a crossing though - unlike the grass surface 
on the „footpath“ which seems to indicate that nobody is actually walking there 
;-)

 

Cheers, Martin 

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

Re: [Tagging] Feature Proposal - crossing=marked

[osm.tagging]

Haven’t checked if it shows up as an error, but technically, the grass on each 
side is the “sidewalk”, and it is simply a shortcoming of the current tagging 
schemes that it’s not possible to properly tag it as pedestrian routable area.

 

These lowered kerbs represents points with easy access from sidewalk to street 
for wheelchair users or people pushing prams, and I think it’s worthwhile to 
map them.

 

From: Graeme Fitzpatrick  
Sent: Tuesday, 14 May 2019 10:24
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - crossing=marked

 




 

On Tue, 14 May 2019 at 05:10, mailto:osm.tagg...@thorsten.engler.id.au> > wrote:

 

I must admit that I only map crossings when they are between formed footpaths eg

 

https://www.google.com/maps/@-28.070784,153.4361817,3a,75y,133.97h,57.19t/data=!3m6!1e1!3m4!1saeYx4cpvnikG8KXcdh0pGw!2e0!7i13312!8i6656
 

 

https://www.openstreetmap.org/way/553154851, not where there is only a grass 
footpath.

 

I do generally map crossings as long as they have lowered kerbs, like here:

https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png

 

That one, I would have terminated the crossing at the marked road, rather than 
taking it to the other side

 

or even:

https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png

 

& that I wouldn't have marked at all. Does it show up in OSMose / OSM Inspector 
etc as an error because it's not "attached" to anything?

 

Thanks

 

Graeme

 



https://www.openstreetmap.org/node/6465544169





___
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 - crossing=marked

[osm.tagging]

Forgot that part:

> On my walk yesterday, other than the implied crossing at every
> intersection (but see "don't map local law") I noted the following:

I do generally map crossings as long as they have lowered kerbs, like here:

https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png

or even:

https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png

https://www.openstreetmap.org/node/6465544169





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

Re: [Tagging] Feature Proposal - crossing=marked

[osm.tagging]

> 1. Combined foot/cycle crossing - a side path from a combined
> foot/cycleway onto a very lightly trafficked suburban street. Marked
> with signs bearing the silhouette of a bicycle about 50 m in advance
> of the crossing. No markings on the pavement. (This crossing is part
> of my daily commute. The street that it crosses is quite busy, and
> the sign with the bicycle silhouette has no apparent effect on the
> drivers. Pedestrians divide into the quick and the dead.)

On the intersection node between footway and road way:
highway=crossing
crossing=unmarked

You may tag the traffic_sign (here and in other cases) separately, how to do 
that is topic all it's own.

> 2. Combined foot/cycle crossing - a combined foot/cycleway crossing
> a busy two-lane street at grade. Signage both ~50 m in advance and
> at the crossing. Flashing yellow lights (meaning 'proceed with
> caution') flank the sign at the crossing. The lights can by turned
> on by a pedestrian or cyclist pushing a button. Zebra-stripe
> pavement markings.

On the intersection node between footway and road way:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

You may tag the traffic_sign separately

> 3. Zebra-stripe pavement markings at an intersection controlled by a
> 4-way STOP sign.

On the intersection node between footway and roadway:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

On a separate node on the road way placed at the stop line:
highway=stop (This tag is a big ugly like that, because it depends on consumers 
figuring out in what direction it applies based on proximity to the 
intersection, but again, that's a topic all it's own.)

(And additionally, given that this is specifically an all way stop, on the 
intersection node of the two road ways:
highway=stop
stop=all

> 4. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with no 'WAIT/WALK' pedestrian signals.

On the intersection node between footway and road way:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

Either on the intersection node of the two road ways, or if dual carriage, on 
separate nodes on the road ways placed at the stop line (coming into the 
junction):
highway=traffic_signals

> 5. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with 'WAIT/WALK' pedestrian signals, and a countdown
> timer giving the seconds remaining to cross.

On the intersection node between footway and road way:
highway=crossing
crossing=traffic_signals

Either on the intersection node of the two road ways, or if dual carriage, on 
separate nodes on the road ways placed at the stop line (coming into the 
junction):
highway=traffic_signals

> 6. The same, with the pedestrian or cyclist requesting the WALK
> signal by pressing a button.

On the intersection node between footway and road way:
highway=crossing
crossing=traffic_signals

If the pedestrians HAVE to push the button to get a WALK (not just "can push, 
which may make it faster or just be a placebo [more common than you think]"), 
also:
button_operated=yes

Either on the intersection node of the two road ways, or if dual carriage, or 
if dual carriage, on separate nodes on the road ways placed at the stop line 
(coming into the junction):
highway=traffic_signals

> 7. Zebra-stripe pavement markings, together with a sign displaying
> the silhouette of school children, in the middle of a block in front
> of a school. This crossing may be supervised during school
> arrival/departure times.

on the intersection node between footway and roadway:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

maybe:
supervised=(valid time expression)

> 8. Zebra-stripe pedestrian markings delineating the preferred
> footpath in a parking field, and running generally perpendicular to
> the parking aisles.

If there is no intersecting node between this way and a road way, then this is 
not a crossing, it's just a footway that happens to be marked using zebra 
stripe pattern.

If there IS an actual intersection between this way and a roadway, then the 
same as any other such crossing, on the intersection node between footway and 
road way:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

> And I'm now in confusion about how to tag any of them.

For all of these, if you want to go down into micromapping territory, in 
addition to the above:
2 nodes on the footway, where the footway crosses the kerb on either side of 
the street with:
barrier=kerb
kerb=lowered (if it is, other values otherwise obviously)
(if the kerb itself is mapped as a way, then these two nodes are the 
intersection nodes between the footway and the kerb way)

and the part of the footway between the two kerb nodes (with the 
highway=crossing node being between them along this way), split at the kerb 
nodes and tagged as:
highway=footway
footway=crossing
crossing=(whatever it is)




___
Tagging mailing list

Re: [Tagging] Golf tag combinations

[osm.tagging]

> -Original Message-
> From: Warin <61sundow...@gmail.com>
> Sent: Saturday, 21 July 2018 16:55
> To: Tag discussion, strategy and related tools
> 
> Subject: [Tagging] Golf tag combinations
> 
> using it that way surely is 'tagging for the render' as it is not the
> golf tag that is rendered.

Correct. And given that osm-carto just closed the "render golf tags" issue with 
the comment "won't do", that's not going to change. You can be sure that pretty 
much everyone that maps the detailed features of a golf course does so because 
they want to see it on the map. And they are going to add whatever tags it 
takes to make that happen.



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

Re: [Tagging] building=clubhouse

[osm.tagging]

Personally, for a golf club, I would consider the “club base” the area that the 
clubhouse and related infrastructure is on only, not including the actual holes.

 

From: Marc Gemis  
Sent: Thursday, 19 July 2018 15:10
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] building=clubhouse

 

I just wanted to point out that there are multiple levels that have to be 
mapped. 

 

- the golf course ( this does not include buildings, parkings, ...)

- the buildings (some of which are clubhouses (can also be sheds, ...))

- the sport complex as a whole (the course + parking + buildings)  
(leisure=golf_course)

- the club base, I wonder whether it is always the complete complex.

 

this applies to other sports as well. If you are improving the wiki page for 
golf, IMHO it should mention those 4 items 

 

Sorry if you think it is off-topic

 

On Thu, Jul 19, 2018 at 6:27 AM Warin <61sundow...@gmail.com 
 > wrote:

On 19/07/18 13:52, Marc Gemis wrote:

for the complete "base" of the club, the club page [1] recommends "The base of 
the club can be tagged amenity=community_centre with the type 
community_centre=club_home and possibly the target group 
community_centre:for=*; either on the containing building or the same element 
as the club itself."


It also says some thing about the grounds too ... so it may not be 'just' the 
building. 
Arr here it is "Draw an area   for 
the campus of the community centre, comprising buildings and outdoor areas."
link https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcommunity_centre

So a golf course would have this tag around the entire ground .. not just the 
building. And that would be a duplication of leisure=golf_course. 

I don't think that fits with golf courses .. and probably some other 
clubhouses. So that recommendation is not valid for golf at least.
 
And for tagging the club=* yes .. I would do that on a node not the building.. 
if necessary. 
But I think anything I could place under the club tag I could also put under 
the building tag?  
link https://wiki.openstreetmap.org/wiki/Key:club


The subject is building = clubhouse ... ? 




[1] https://wiki.openstreetmap.org/wiki/Key:club On Thu, Jul 19, 2018 at 5:16 
AM Warin   <61sundow...@gmail.com> wrote: 

Hi, With the golfing thing that I have on another thread there is the tagging 
of golf=clubhouse suggested on a building=yes. That is specific to golf, what 
about other clubhouses? Taginfo has uses of 557 building=clubhouse 479 
golf=clubhouse 121 tennis:clubhouse=* 98 amenity=clubhouse 9 building=Clubhouse 
6 designation=Clubhouse That is some 1,200 uses. Not vast by any means .. but 
if a combined tag were created with good documentation and links then I'd thing 
the numbers would take off .. there are a lot of football clubs with club 
houses around me ... umm what are tagged as they now? building=yes by the look 
of things. Would it not be best to combine all theses into building=clubhouse? 
Any associated sport could be specified with sport=*. A description could be - 
"A building that supports a club by providing a social area, amenities and/or 
specific facilities to support the clubs activities." I note that this was 
raised on the proposal of building .. but not taken up as 'pavilion' was 
pursued in its place. See 
https://wiki.openstreetmap.org/wiki/Proposed_features/building Thoughts? 
___ 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] building=clubhouse

[osm.tagging]

Sounds like something that could be tagged *in addition* to building=clubhouse 
to provide more detail?

 

From: Graeme Fitzpatrick  
Sent: Thursday, 19 July 2018 13:41
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] building=clubhouse

 

Not exactly clubhouse as such but did find 
https://wiki.openstreetmap.org/wiki/Key:club a little while back, which does 
also say  

* club=  sport +  
 sport=*

 

Usable?

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

Re: [Tagging] Golf wiki page

[osm.tagging]

> -Original Message-
> From: Warin <61sundow...@gmail.com>
> Sent: Sunday, 15 July 2018 18:41
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Golf wiki page
> 
> Devils advocate hat firmly on.
> 
> But what is intended? Not the height of the grass .. but the
> 'smoothness and regularity' of the playing surface?
> 
> I use http://www.cooberpedygolfclub.com.au/ as an example again.
> That golf course has no grown grass. They use sand and oil for the
> greens. They use artificial grass on the tees.
> The difference is the finish on the surfaces .. not the size of
> gains of sand nor size of the rocks nor the height of the grass...
> 
> I have just finished tagging that golf course .. fairways have
> surface=sand, colour=white; greens are surface=sand, colour=black.
> Humm I don't remember what I have tagged tees as? Should be
> colour=green, surface=artificial_grass and they should be square.
>   .
> I don't have the knowledge to tag the roughs, bunkers and some of
> the tees there so it is just a rough start.

All of which is pretty much totally irrelevant.

What you need is 
golf=green
golf=tee
golf=fairway
golf=bunker
golf=rough
...
for the appropriate areas.





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

Re: [Tagging] Golf wiki page

[osm.tagging]

Looks fine to me: 
https://www.dropbox.com/s/tks7yumfju0wz6q/1531564818315.jpg?dl=0

From: Yves  
Sent: Saturday, 14 July 2018 20:15
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Golf wiki page

You should pay attention to the message format, the last one is unreadable. 



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

Re: [Tagging] Golf wiki page

[osm.tagging]

From: Warin <61sundow...@gmail.com> 
Sent: Saturday, 14 July 2018 17:07
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Golf wiki page

 

On 14/07/18 15:11, osm.tagg...@thorsten.engler.id.au 
  wrote:

While page is not the best... you seem to misunderstand part of it.
 
The "level" reference doesn't have anything to do the level tag. Or any tag at 
all. It's just saying there are 3 levels of detail at which a golf course can 
be mapped.

In which case a different word can be used .. like 'order'. 
 
I didn’t write the page. I’m just saying you misinterpreted the use of the word 
“level”. The term “level of detail” is pretty common and means exactly what 
whoever authored that page is talking about.

 
As for the "How short is the grass" section, while maybe not expressed in the 
best way, that looks generally correct to me.

Why not use height? already exists and is understandable by all. 

 
 
golf=green or golf=tee_area has the shortest grass
nobody seems to map golf=fringe or golf=apron, so these should probably go
golf=fairway is slightly longer than the green, but still well maintained
golf=mown is hardly used, can probably go
golf=rough is the longer grass outside the fairway, it generally is still 
mowed, but noticeable longer
natural=scrub is for areas that are generally not longer mowed, so you get very 
long grass, some shrubs, ...
natural=wood, well, there are trees here
landuse=forest has no meaningful difference to natural=wood in this context and 
can go.
 
Generally speaking, you have areas for green, tee and fairway (green and tee 
are NOT inside the fairway), surrounded by rough, surrounded by scrub and/or 
wood.
 

Grooming is used for piste and may possibly be applied here.
https://wiki.openstreetmap.org/wiki/Key:piste:grooming
 
Comment: not all golf courses have grass...  
http://www.cooberpedygolfclub.com.au/
where "greens are black and the fairways are white"
So height of the grass cannot be used everywhere. 
 
Again, it’s not really about the “height of the grass”. Nobody cares about 
recording the “height of grass”. 
 
You have different areas with different meanings. Green and tee area. Fairway. 
Rough. (And yes, others, like bunkers [usually sand], and [usually water] 
hazards.) It’s just that for the probably 99% of golf courses that use grass, 
there is a direct correlation between these areas and the length of the grass. 
 
So for non-golfers (which includes me) the description of “If it’s very short 
and well maintained, it’s going to be a green or tee. If It’s slightly longer 
but still clearly mowed and maintained often, it’s a fairway. If it’s growing 
even longer, but still maintained grass, it’s rough. (And everything else is 
likely out of bounds)” Is probably easiest to understand.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Golf wiki page

[osm.tagging]

While page is not the best... you seem to misunderstand part of it.

The "level" reference doesn't have anything to do the level tag. Or any tag at 
all. It's just saying there are 3 levels of detail at which a golf course can 
be mapped.

As for the "How short is the grass" section, while maybe not expressed in the 
best way, that looks generally correct to me.

golf=green or golf=tee_area has the shortest grass
nobody seems to map golf=fringe or golf=apron, so these should probably go
golf=fairway is slightly longer than the green, but still well maintained
golf=mown is hardly used, can probably go
golf=rough is the longer grass outside the fairway, it generally is still 
mowed, but noticeable longer
natural=scrub is for areas that are generally not longer mowed, so you get very 
long grass, some shrubs, ...
natural=wood, well, there are trees here
landuse=forest has no meaningful difference to natural=wood in this context and 
can go.

Generally speaking, you have areas for green, tee and fairway (green and tee 
are NOT inside the fairway), surrounded by rough, surrounded by scrub and/or 
wood.

> -Original Message-
> From: Warin <61sundow...@gmail.com>
> Sent: Saturday, 14 July 2018 13:44
> To: Tag discussion, strategy and related tools
> 
> Subject: [Tagging] Golf wiki page
> 
> Hi
> 
> I have just come across a new mapper trying to map a golf course.
> Fine, but they can do with some guidance.
> Looking around for such guidance I came across this wiki page,
> https://wiki.openstreetmap.org/wiki/HOWTO_map_a_golf_course_2013
> 
> Looks to me .. well not the best.
> The idea that the level tag should be used in that way .. umm as a
> how to ? Err I'd vote no.
> Remember this is for new people too.
> 
> The idea that the height of the grass should be tagged in that way ??
> Again .. no.
> 
> The page does not link to the golf wiki pages.
> 
> I think it can do with a major rewrite, or should I just make a new
> page ? HOWTO_map_a_golf_course_v2 ?? :) Once done and people make
> their comments/changes then the original page can have a redirection
> to the newer page?
> I think a new page would probably be better as a fresh approach can
> be had.
> 
> Thoughts?
> 
> 
> ___
> 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] landcover=asphalt ; landuse=highway

[osm.tagging]

In my opinion:

 

area:highway=* for the actual road surface (there are some rules how exactly 
these areas should be segmented at intersections, and how these areas should be 
connected with the actual highway ways)

surface=* on these to describe the material the road surface is made of

if barrier=kerb lines have been traced, they can be used as part of a 
area:highway=* multipolygon. (And if they haven’t already been traced, then 
ways in the right position will become necessary to form the area:highway, so 
might as well properly tag them with barrier=kerb at that time).

 

landuse=highway is for the whole public right of way, including the road 
surface, footpath, verge, … So the outer edge of the landuse=highway area are 
the lot boundaries of the properties surrounding the road.

 

landcover=grass can be used for the area between the kerb and the outer edge of 
the landuse=highway area. (assuming there is grass growing there, otherwise 
whatever the landcover is obviously).

 

From: Martin Koppenhoefer  
Sent: Saturday, 14 July 2018 06:05
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] landcover=asphalt ; landuse=highway

 

 

sent from a phone


On 13. Jul 2018, at 15:43, Bryan Housel mailto:bhou...@gmail.com> > wrote:

>From what I remember people are already using  `area:highway=*` for detailed 
>street area mapping.

https://taginfo.openstreetmap.org/keys/area%3Ahighway 
 

 

 

+1, for the surface of roads, the tag „surface“ is common (landcover is not 
used for road surfaces).

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

Re: [Tagging] [tagging] Canoe route / nautical channels

[osm.tagging]

> -Original Message-
> From: Christoph Hormann 
> Sent: Tuesday, 3 July 2018 18:26
> To: Tag discussion, strategy and related tools
> 
> Subject: Re: [Tagging] [tagging] Canoe route / nautical channels
> 
> On Tuesday 03 July 2018, Multi Modaal wrote:
> > [...]
> >
> > Summary:
> > I would suggest using [waterway=canal] or [waterway=river] for
> > routable lines across bodies of water despite the fact that you
> > normally wouldn’t call them as such. This because of common current
> > practice for routable networks and other practical reasons.
> 
> Note Multi Modaal is trying to push this idea of tagging for the
> router into the wiki as established use of waterway=canal (which is
> obviously not).  Here what i added there explaining why this is a
> very bad idea:
> 
> Such use of waterway=canal is in fundamental conflict with the main
> purpose and primary use of the tag to map artificial physical
> waterways and is therefore strongly discouraged. It can primarily be
> considered Tagging for the renderer to place labels and tagging for
> the router.

Fully agree. 

waterway=canal or waterway=river are not appropriate for mapping either 
physically unmarked routes or routes marked with buoys inside larger bodies of 
water.

https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfairway does seem 
appropriate for the later. So that's basically the answer to the "nautical 
channels" thread.

A waterway=canal, waterway=river, or waterway=stream way inside a lake or pond 
is probably appropriate to connect an in-flow to an out-flow in a direct line, 
to allow software to easily trace waterways through lakes or ponds (which are 
essentially just widening of the waterway) without having to process areas. In 
this case the waterway going through the larger body of water should share a 
node with the outline of the lake at the in-flow and out-flow points where they 
way and the outline intersect.

> The commonly used method for mapping boat routes with regular service
> is route=ferry. Routes used casually, non-regularly and with wide
> variation in geometry by private boats are not verifiable and should
> therefore not be mapped in OSM.

Where you have a lake, and there are a pair of pretty clear points where it's 
possible to put your canoe (or similar sized boat) in or take it out of the 
water, I do think it's appropriate to connect these points with a route=canoe 
way if it is part of a route=canoe relation (which includes both water sections 
and sections on land).
So that's basically the answer to the "canoe route" thread.

> I hope there will be community consensus not to abuse waterway=canal
> or other waterway tags this way and we can remove the whole paragraph
> again.
> 
> On a general note and as a suggestion to mappers who might be
> irritated about how to deal with OSMs free form tagging system:
> 
> * inventing new tags so far not used and documented is fine - but you
> should document them.
> * adding new uses to secondary tags (like using surface=* or usage=*
> on features it is so far not commonly used on) is also fine if it
> matches previous use in meaning.
> * adding new uses to existing primary tags is highly sensitive and
> should usually be discussed first.  Creating a new tag is almost
> always a better idea.

I agree with all of that.



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

Re: [Tagging] nautical channels

[osm.tagging]

Maybe following the same scheme as for highways:

 

waterway=navigable_channel (for way along the middle of the channel)

area:waterway=navigable_channel (for area bound by buoys, with an intersecting 
node at both ends between the area and the middle line way)

 

From: osm.tagg...@thorsten.engler.id.au  
Sent: Sunday, 1 July 2018 11:25
To: 'Tag discussion, strategy and related tools' 
Subject: Re: [Tagging] nautical channels

 

I think it’s slightly different.

 

For canoe routes, there is generally no infrastructure along the route.

 

While navigable channels are marked with buoys, which makes them closer to a 
“highway” on land than a route. So I think it’s something that belongs in the 
waterway namespace.

 

If navigable channel is the correct nautical term, then the obvious would be 
waterway=navigable_channel

 

The real question becomes: tagging as a way in the middle of the channel? 
Tagging as an area (by mapping the buoys as seamarks, then connecting them to 
form an area)? Both? Either?

 

From: Graeme Fitzpatrick mailto:graemefi...@gmail.com> 
> 
Sent: Sunday, 1 July 2018 11:10
To: Tag discussion, strategy and related tools mailto:tagging@openstreetmap.org> >
Subject: Re: [Tagging] nautical channels

 

& as I've just mentioned on the Canoe Route thread, we're discussing two things 
that are pretty well the same!

 

https://lists.openstreetmap.org/pipermail/tagging/2018-June/037677.html

 

https://lists.openstreetmap.org/pipermail/tagging/2018-July/037729.html

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

Re: [Tagging] nautical channels

[osm.tagging]

I think it’s slightly different.

 

For canoe routes, there is generally no infrastructure along the route.

 

While navigable channels are marked with buoys, which makes them closer to a 
“highway” on land than a route. So I think it’s something that belongs in the 
waterway namespace.

 

If navigable channel is the correct nautical term, then the obvious would be 
waterway=navigable_channel

 

The real question becomes: tagging as a way in the middle of the channel? 
Tagging as an area (by mapping the buoys as seamarks, then connecting them to 
form an area)? Both? Either?

 

From: Graeme Fitzpatrick  
Sent: Sunday, 1 July 2018 11:10
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] nautical channels

 

& as I've just mentioned on the Canoe Route thread, we're discussing two things 
that are pretty well the same!

 

https://lists.openstreetmap.org/pipermail/tagging/2018-June/037677.html

 

https://lists.openstreetmap.org/pipermail/tagging/2018-July/037729.html

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

Re: [Tagging] Canoe route

[osm.tagging]

It might be best to adapt the same language used in the access tag:

 

https://wiki.openstreetmap.org/wiki/Key:access

 

Water-based transportation

* access=* (category: any water-based transportation mode)

*   boat=* (covers small 
boats and pleasure crafts, including yachts)

*   motorboat=* 
(boats and yachts using motor, on    
also for sailing boats using the motor)

*  

 sailboat=* (boats and yachts using sails, on  
  doing way with sail, not using the 
motor (according to the definition of the Colreg))

*   canoe=* (boats 
without sail or motor, such as small dinghies, canoes, kayaks, etc.)

 

So “canoe” is the generic term used for any such small boats, including kayaks.

 

route=canoe seems fine in that case. maybe route=boat if it’s also suitable for 
motorboat or sailboat.

 

 

From: Clifford Snow  
Sent: Sunday, 1 July 2018 08:29
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Canoe route

 

I'd like to suggest not creating a very specific tag like route=canoe, instead 
use something more general that would apply to more water crafts like kayaks, 
small boats, canoes, and rafts. route=marine_trail would be more fitting. 
Related tag could include motorized=(yes/no). 

 

Kayaking around my area is bigger than canoes with a number of trails in the 
area. 

 

Best,

Clifford

 

On Sat, Jun 30, 2018 at 2:40 PM Paul Allen mailto:pla16...@gmail.com> > wrote:

On Sat, Jun 30, 2018 at 10:15 PM, Yves mailto:yve...@mailbox.org> > wrote:

 

There is a way to avoid tagging the way with the route tag:

whitewater:section_grade=0

See https://wiki.openstreetmap.org/wiki/Whitewater_sports#Grades

I consent your canoe practice on a lake is perhaps far from 'whitewater' 
practice, but grade 0 describes a lake perfectly. And if the route follows a 
river with grade 1, then map it as such.

 

Unless I misunderstand the wiki page, whitewater:section_grade is only 
documented as applying to waterway=river.

There is nothing there implying it is valid to use it with anything other than 
rivers.

Whereas route=* applies to any route which isn't rigidly defined: boat travel, 
aeroplanes, driving across a desert.

Anywhere you need to join points A and B with a way that is not rigidly defined 
but merely a suggestion.

Yes, you could modify the documentation so whitewater:section_grade also 
applies to lakes, oceans and seas but

then you'd need to emphasise that grades higher than 0 must not be used on 
anything other than rivers.  And it

still doesn't apply to aircraft or driving across a desert or pistes.

You're trying to bash a square peg into a round hole here, and doing so when 
somebody has already handed you a

round peg of the correct size.

-- 

Paul

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




 

-- 

@osm_seattle

osm_seattle.snowandsnow.us  

OpenStreetMap: Maps with a human touch

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

Re: [Tagging] nautical channels

[osm.tagging]

Without being familiar with the topic at all, and seeing that there don’t seem 
to be any matching tags yet, maybe something like waterway=dredged_channel ?

 

From: Volker Schmidt  
Sent: Sunday, 1 July 2018 01:42
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] nautical channels

 

 

On Sat, 30 Jun 2018, 14:03 Paul Allen, mailto:pla16...@gmail.com> > wrote

 

The way to handle navigable channels across lagoons/lakes is covered at 
https://wiki.openstreetmap.org/wiki/Key:route

(you might have to invent route=boat or route=ship). 

 

I am aware the route relations for, e.g., ferry boats.

What I want to tag are not routes but the water-equivalent of roads. The 
ferry-boat route (in the lagoon of Venice) uses the navigation channels 
("canali") like a bus line follows roads.

At present (always on the lagoon of Venice) mappers would map each "vaporetto" 
(water bus) route as a separate way plus the "canali" as separate, more or less 
parallel, ways.

I would think that the roads plus bus route relations model should be applied 
also to navigation channels and water-based transport in the, admittedly, very 
specific context of the Laguna Di Venetian.

 

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

Re: [Tagging] tagging religion-based access

[osm.tagging]

This right there is a major reason why it was a bad idea to allow 
“transportmode=accessvalue” and not always require 
“access:transportmode=accessvalue”…

 

From: Mateusz Konieczny  
Sent: Saturday, 30 June 2018 04:36
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] tagging religion-based access

 

I thought about it but it is not clear that it refers to access. Also, it would 
cause problems

for anybody processing popular tags (like access) and not processing very rare 
new tags

(muslim).

 

For example

 

amenity=place_of_worship

muslim=yes

religion=muslim

access=no

 

would be quite unclear, with muslim=yes looking like duplicate of 
religion=muslim.

 

 

 

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

Re: [Tagging] Feature Proposal - RFC - highway strip

[osm.tagging]

Don't really have a strong opinion on it either way, just to raise a point for 
discussion... but if it's for emergencies, should it have some tag in the 
emergency=* namespace?

> -Original Message-
> From: Jyri-Petteri Paloposki 
> Sent: Tuesday, 26 June 2018 00:56
> To: 'Tag discussion, strategy and related tools'
> 
> Subject: [Tagging] Feature Proposal - RFC - highway strip
> 
> Hi,
> 
> proposing a new value aeroway=highway_strip for landing strips that
> are normally used as a part of a highway, but can be closed either
> because of a military exercise or emergency landing for aeroplane
> landing. The tag should only be used when the strip has been
> dedicated as an emergency landing strip, other possibly suitable
> emergency landing strips should not be tagged.
> 
> Currently there are a few highway strips that have been tagged with
> aeroway=highway_strip (in addition to the proper highway=* tag).
> Others have been tagged as aeroway=runway, which causes the strip to
> be rendered the same way as an aerodrome runway, which isn't sensible.
> There should be a way to separate strips that have been dedicated as
> emergency landing strips but are otherwise in use as a highway and
> normal runways / dedicated emergency landing strips.
> 
> The proposal can be found at
> https://wiki.openstreetmap.org/wiki/Proposed_features/highway_strip .
> 
> Best regards,
> --
> Jyri-Petteri Paloposki
> 
> ___
> 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] shop=discount

[osm.tagging]

I remember about 20 years ago when I was still living in Germany I regularly 
went to a shop that was selling (mostly) food stuff "from the pallet", 
sometimes with slight transport damage (cans with dents, that type of thing).

That's what I would expect to find for a shop=discount


> -Original Message-
> From: Martin Koppenhoefer 
> Sent: Monday, 25 June 2018 06:17
> To: Tag discussion, strategy and related tools
> 
> Subject: Re: [Tagging] shop=discount
> 
> 
> 
> sent from a phone
> 
> > On 24. Jun 2018, at 22:00, Mateusz Konieczny
>  wrote:
> >
> > It sounds like any type of shop may have discount shop variation.
> 
> 
> usually the term discount shop refers to shops selling food “from the
> pallet”, i.e. a smaller selection and less laborious presentation,
> tending to bigger packages, for a cheaper price.
> Sometimes also with supposed inferior quality. Nowadays also
> typically sell occasionally selected non-food stuff according to the
> season (like tools, clothing, toys, even electronics like 1 laptop or
> 1 phone), but usually only from 2-3 boxes, it does not take
> significant space.
> 
> 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] shop=health

[osm.tagging]

The first thing that came to mind when reading shop=health is:

 

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

 

Not sure what the appropriate tag for that is.

 

I agree that shop=health is very ambiguous.

 

From: Mateusz Konieczny  
Sent: Sunday, 24 June 2018 19:15
To: Tagging 
Subject: [Tagging] shop=health

 

I described it on wiki as a poor idea as quite obviously this tag is really 
unclear.

 

Hopefully nobody thinks that this tag is a good idea.

 

It is unclear whatever shop=medical_supply or amenity=pharmacy or shop=herbalist

meaning was intended.

 

If someone is aware about more potential meanings or has some other ideas how

wiki page may be improved - see

https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dhealth 

 =edit

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

Re: [Tagging] tower:type=suspension

[osm.tagging]

I was more thinking about the possibility of mapping above ground phone/data 
cables. Not sure if any of them are strung on what could be considered a 
“tower” or if it’s always a “pole”…

 

So while there currently is primarily a power=tower + tower:type=*

 

I could see something like telecom=tower + tower:type=* also showing up at some 
point.

 

And to keep the possibility open that other types of “towers that hold cables 
up” are defined in the future, I don’t think tower:type=suspension should 
automatically imply power=tower if not explicitly tagged as such.

 

From: Mateusz Konieczny  
Sent: Sunday, 24 June 2018 18:16
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] tower:type=suspension

 

23. Jun 2018 15:44 by osm.tagg...@thorsten.engler.id.au 
 :

Not in any way involved with power mapping, but I don’t think tower:type should 
have necessarily any implications about what it is that’s being transmitted 
over the suspended cables.

 

I agree, in principle any power:type may be use to transmit any type of power 
(or not be used at all). 

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

Re: [Tagging] tower:type=suspension

[osm.tagging]

Not in any way involved with power mapping, but I don’t think tower:type should 
have necessarily any implications about what it is that’s being transmitted 
over the suspended cables.

 

In the specific case of power=tower, while I guess tower:type=suspension might 
be considered the “default” value, the default, still needs to be a “defined” 
value. Tagging of tower:type=suspension can then be a way to indicate that 
someone actually looked at it and made a determination in regards to what type 
of tower it is, while the absence of the tag means that while it probably is a 
suspension tower, no body has looked close enough to make sure yet.

 

As for the wiki page, it should probably show the same information that 
https://wiki.openstreetmap.org/wiki/Key:tower:type shows for 
tower:type=suspension, that is:

 

“A tower which supports the conductors vertically using suspension insulators. 
This is the default type and need not be tagged. However it may be useful to 
tag a suspension tower if it is used as an angle tower (an anchor tower would 
normally be expected here)”.

 

From: Martin Koppenhoefer  
Sent: Saturday, 23 June 2018 23:24
To: Tag discussion, strategy and related tools 
Subject: [Tagging] tower:type=suspension

 

One of the most used values for tower:type is "suspension". Is this an 
alternative way of saying power=tower or is there more behind it?

 

If you can provide information, please amend the wiki page stub:

https://wiki.openstreetmap.org/wiki/Tag:tower:type%3Dsuspension

 

Cheers,

Martin

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

Re: [Tagging] public transport through service

[osm.tagging]

> -Original Message-
> From: Michael Tsang 
> Sent: Saturday, 23 June 2018 01:36
> 
> I have raised this topic two years ago but it seems that there is
> no community consensus here. My problem is "How should we tag a
> public transport through service route?"
> 
> In my city there are the following cases:
> 
> 1. A simple circular route where a passenger can normally stay on
> board through the end / start point unless the vehicle is taken out
> of service.
> 
> Example:
> https://www.openstreetmap.org/relation/2941692

My assumption has always been that this is what roundtrip=yes is supposed to 
mean

> 2. A route where the vehicle always enter another specific route
> unless the vehicle is taken out of service, and the passenger can
> stay aboard.
> 
> Example (the vehicle on one of the following routes will enter the
> other reaching the end where the passenger can stay on board):
> https://www.openstreetmap.org/relation/5955257
> https://www.openstreetmap.org/relation/5955258

I don't think there is anything currently defined for mapping that.

I would guess one possibility to map this would be to add a member of role 
"vehicle_continues_on" after the last stop/platform member, referencing the 
next route relation. This might also model your case 1 as you could add the 
relation to itself (I think, not sure if that's valid.)

> 3. A service where the vehicle runs a part of the route, and enters
> another
> mid-route:
> 
> Example: A particular departure on route 751 below will enter route
> 507 upon reaching Choy Yee Bridge in order to cope with passenger
> demand at that particular time, the ref shown will be changed at
> that en-route stop:
> 
> https://www.openstreetmap.org/relation/2926506 (751)
> https://www.openstreetmap.org/relation/6481316 (507)

This sounds like they are route variations.

That is: 

Create a copy of 2926506 that ends where the ref changes. 
Create a copy of 6481316 that starts where the ref changes.
(Make sure both copies are part of the appropriate route master.)
Then follow suggestion for case 2 to link these two together.

> 4. A service, due to operational reasons, changes the ref in
> particular fixed points along the route (e.g. when crossing system
> boundary), but marketed as one route on promotional materials (e.g.
> the train from Foshan to Kowloon, which operates as Z806 between
> Foshan and Guangzhou and Z803 from Guangzhou to Kowloon, but it is
> a single trip with absolutely no alighting allowed at
> Guangzhou)

If there was an actual stop at Guangzhou, this could again be modelled using 
the approach for case 2. But if the changeover point is not actually a stop, 
things get difficult.

Are there stops between Foshan and Guangzhou? And between Guangzhou and Kowloon?

The best you can probably do is just specify both refs: 

ref=Z806;Z803

Though I'm not too happy with that.

Cheers,
Thorsten



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

Re: [Tagging] public_transport=platform rendering on osm-carto

[osm.tagging]

> -Original Message-
> From: Martin Koppenhoefer 
> Sent: Friday, 22 June 2018 08:03
> 
> a bus stop usually didn’t have a highway=platform, just
> highway=bus_stop, only for platforms on stations the former is
> suggested.
> It is only a fraction (94k) of all bus stops (2M) that could be
> seen as simpler after a change.

And the ones that used to have only a highway=bus_stop node only require a 
public_transport=platform node instead now. No increase in complexity. So some 
are the same, and some are simpler, none are required to be more complex. So 
overall, it's simpler.



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

Re: [Tagging] public_transport=platform rendering on osm-carto

[osm.tagging]

As I previously said, I would consider this vandalism.

> -Original Message-
> From: marc marc 
> Sent: Friday, 22 June 2018 01:23
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] public_transport=platform rendering on osm-
> carto
> 
> Le 21. 06. 18 à 16:27, Paul Allen a écrit :
> > Platforms are mapped but stop positions aren't (somebody who
> thinks
> > they shouldn't be there cleaned up after me).
> > https://www.openstreetmap.org/relation/7620346
> 
> if want to known who destroy stop_position in the relation, look at
> version #18 changet 59355804 23 days ago.
> PS: Polyglot=Jo
> 
> The destruction of perfectly valid tags is really a problematic
> behavior despite all the sympathy I have for Jo in many other
> threads.
> Fixing some stuff in a relationship does not need to destroy valid
> info that another mapper had added previously.
> ___
> 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] public_transport=platform_edge

[osm.tagging]

I've noticed that while there is a
https://wiki.openstreetmap.org/wiki/Tag:railway=platform_edge there is no
generalized public_transport=platform_edge.

 

I would propose that we allow public_transport=platform_edge as the exact
same concept applies equally well to e.g. island platforms at bus stations.
And if railway=platform get changes to public_transport=platform in the
future, it makes no sense that the individual edges are still tagged with
railway=platform_edge.

 

I would further propose that we consider allowing adding
public_transport=platform_edge to route relations (but only a platform_edge
OR platform for each stop, not both, using the platform role).

 

Cheers,

Thorsten

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

Re: [Tagging] public_transport=platform rendering on osm-carto

[osm.tagging]

Everything you write is no different between PTv2 and the old tagging scheme.

 

FIRST, all the stops, in order. THEN, all the ways that make up the route, in 
order.

 

As far as I’m aware, there hasn’t been a route tagging scheme before that mixes 
the stops into the route before.

 

The actual PTv2 proposal documents that quite well:

 

https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant

 

“Each stop is included with two elements (if available): first the  
 
stop_position tagged with role stop and immediately followed by the 
corresponding  
 platform 
tagged with role platform. The stops (stop_positions and platforms) should be 
inserted beginning with the initial stop_position/platform and ending with the 
terminal stop_position/platform. The ordering of the stop positions in the 
relation will determine the direction of the route.

 

…

 

After all the stops all the used ways should be inserted into the relation with 
an empty role. The ways should be inserted beginning with the way at the 
initial stop position and ending with the way at the terminal stop position.”

 

I fully agree that the individual pages for tags are a total mess, mixing 
together information both from previous tagging schemes and PTv2.

 

When evaluating PTv2 and mapping according to it, the actual accepted proposal 
(which I linked above) should be considered normative.

 

If you read through the actual proposal that was accepted, it’s actually pretty 
clear and well structured.

 

All the individual pages should probably be cleaned up, and only and clearly 
contain the information from the PTv2 proposal. That would greatly clear up the 
confusion people seem to have. But I understand that would greatly upset people 
that outright reject PTv2 despite it being newest voted on and accepted 
proposal.

 

 

 

From: Paul Allen  
Sent: Thursday, 21 June 2018 04:21
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] public_transport=platform rendering on osm-carto

 

 

On Wed, Jun 20, 2018 at 6:53 PM, mailto:osm.tagg...@thorsten.engler.id.au> > wrote:
 

So, valid minimal tagging under PTv2 is very simple:

 

You have one node (if there is no clear platform) or a way (along the platform 
edge) or area (the whole platform), which is tagged as 
public_transport=platform (plus whatever mode of transport is served at the 

platform, so bus=yes or tram=yes, or …)

 

Which all sounds fine, until I try to make sense of the relation.  Something 
(or somebody) seems to like

shoving all platforms at the start of the relation, then the ways in order.
Which would work (just) for a routeing
algorithm, if you throw enough CPU at it, but is inefficient.  It also gets 
very confusing when you have a route which is

circuitous and doubles back on part of its earlier route in the same direction, 
causing some stops to be in the

relation twice.  The route I'm thinking of has a stop on that revisited section 
which is NOT used on the first

traversal but IS used on the second.  It's hard to figure out what's going on 
unless the stops appear in the

relation next to their ways rather than all lumped together at the beginning.


And it gets worse.  Suppose I have a simple route, from X to Z with a stop at Y.

  X --- bat street --- o --- cat street --- o --- dog street --- Z

X is at the start of bat street, Z is at the end of dog street.  Y is in the 
middle of cat street, not at either of its 

junctions with the other two streets.

The choices I have for relation ordering (I'm still learning/battling JOSM to 
do it) are X, Y, Z, bat street, cat street,

dog street; or X (which appears to be how it's ordered by default), bat street, 
Y, cat street, dog street, Z;
or X, bat street, cat street, Y, dog street.  None of which make it clear to a 
mapper or consumer what the reality is
without also looking at the map (simple inspection of the data is not enough).  
Or should cat street be split at Y
so I can have X, bat street, cat street 1, Y, cat street 2, dog street, Z?

Or does it simply not matter where the stops appear in the relation?  If not, 
does it even matter what order they're

in?  I would have thought that for efficiency of routeing you'd NEED stop 
positions on highways too, otherwise

there's an extra search outwards from the platform until it finds the way.  Oh, 
and the nearest portion of the

way may not actually be reachable from the platform because of obstacles.

 

I'm confused.  The wiki doesn't seem to make it clear and nor do the tools.  Am 
I entirely missing the point?

Probably.

I would appreciate somebody with a deep understanding of this stuff clarifying 
matters, here or on the wiki.


-- 

Paul

___
Tagging mailing list
Tagging@openstreetmap.org

Re: [Tagging] public_transport=platform rendering on osm-carto

[osm.tagging]

I fully agree with everything marc said.

But I think Jo's confusion comes primarily from the fact that 
public_transport=platform replaces BOTH highway=platform AND highway=bus_stop.

So under the old tagging scheme you could have a highway=platform way or area, 
AND a highway=bus_stop node.

In places where there was only a highway=bus_stop node, this is often now dual 
tagged with public_transport=platform as well (which is correct).

In places where there was only a highway=platform way/area, this is often now 
dual tagged with public_transport=platform was well (correct too).

But in places that have both a highway=platform and a highway=bus_stop, dual 
tagging both with public_transport=platform is wrong. The two should be merged 
into only a single way/area with public_transport=platform. The problem then is 
that you can't really dual tag that anymore, because the highway=platform and 
highway=bus_stop tags are in direct conflict and can't be tagged on the same 
object.

And because the lack of rendering in osm carto, many people are not going to 
use PTv2 properly in this case, because they can't dual tag it so that it will 
properly show up on the map.

The lack of rendering support for public_transport=platform *as a replacement 
for highway=bus_stop and similar tags* is what prevents widespread adaption of 
PTv2 and deprecation of the old tagging scheme.

Implementing public_transport=platform rendering purely as a 1:1 replacement of 
highway/railway=platform, without properly supporting it as a replacement of 
bus_stop, tram_stop, and so on is not going to fix that issue.

> -Original Message-
> From: marc marc 
> Sent: Thursday, 21 June 2018 02:53
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] public_transport=platform rendering on osm-
> carto
> 
> Le 20. 06. 18 à 17:44, Jo a écrit :
> > Actually I have started to remove public_transport=platform from
> WAYS
> > with highway=platform and railway=platform. As far as I am
> concerned
> > public_transport=platform goes on NODES
> 
> sorry I didn't understand why (or maybe yes I prefer to not
> understand) Zverik's propal that you clone to request that
> public_transport=platform as way should be downgraded to a node-
> only HAS FAILED !
> So if another mapper extend the node to better match the geometry
> of the plateform, why are you revert it ?
> yes wiki is ambigous. but for almost (?) all objects the extend
> from a node into a more precise geometry has always been considered
> an improvement, not a mistkae that need to be fixed.
> So the next contributor will probably add the PTv2 tags you deleted.
> 
> > Removing those tags from ways comes from the objection of some
> people
> > that there would be both a way and a platform with the
> > public_transport=platform tag.
> 
> I remember this talk about that on tranport (french-speaking
> transit) mailing when it became apparent that duplicate objects
> were so common in France that they affected stats at a regional
> scale.
> This resulted in a collective work to add missing PTv2 tags, many
> contributors spent many hours for that and fix a lot of mistake.
> Currently the region of french capital is nearly 100% PTv2 and at
> the country scale in france, there is almost no highway=plateform
> tag left that does not also have its PTv2 equivalent.
> 
> Of course one stop in one direction should have :
> - only one plateform per "passenger waiting area" (including all
> variant public_transport=platform highway=platform and
> railway=platform) and/or
> - one stop_position
> 
> having one "passenger waiting area" mapped as a node + as a way + a
> MP like I already see, with tags randomly distributed or duplicated
> between these osm objects that represent the same thing, it is a
> mess
> 
> and PTv1 tag should of course be put only on one of the same objets.
> If not, you make duplicate objet for the same feature... like
> currently.
> 
> > In other words, the rendering of *=platform on WAYS is just fine
> as it is.
> 
> of course that it is the continuation of Zverik's failed proposal.
> but check current pratice :
> the supremacy of public_transport=platform over highway=platform is
> even clearer if we take into account the duplicate tag 900k for
> public_transport=platform without (highway=platform or
> railway=platform)
> 84k highway=platform + public_transport=platform only 9k
> highway=platform without public_transport=platform the community
> has already twice rejected this unintelligible wish to have a
> PTv2custom with different rules totally useless depending on the
> transport mode.
> PTv2 consists precisely in making things more HOMOGENEOUS.
> So please reconsider your modifications and take into account that
> highway=plateform and public_tramsport=plateform are 2 tags for the
> same concept (a passenger waiting area for a public transport),
> even if the render support only the oldest and less common schema
> for *=platform
> 
> Regards,
> Marc
> 

Re: [Tagging] public_transport=platform rendering on osm-carto

[osm.tagging]

>From my reading of the wiki (I wasn’t involved when PTv2 was designed), the 
>situation as envisioned in PTv2 would be that you have only one node, way, or 
>area with public_transport=platform. So the existing highway=bus_stop and 
>highway=platform (in cases where both are present) are merged into a single 
>public_transport=platform (on the way or area that currently is the 
>highway=platform, and the highway=bus_stop goes away completely).

 

But this requires proper rendering support. That is, the way or area should be 
rendered like highway=platform was, AND it should render an icon in the middle 
of the way like highway=bus_stop did. Because public_transport=platform 
replaces both of these.

 

Trying to see and implement public_transport=platform only as a 1:1 replacement 
for existing highway=platform and/or railway=platform is going to make the 
situation worse, not better.

 

From: Jo  
Sent: Thursday, 21 June 2018 01:45
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] public_transport=platform rendering on osm-carto

 

Actually I have started to remove public_transport=platform from WAYS with 
highway=platform and railway=platform. As far as I am concerned 
public_transport=platform goes on NODES next to the ways in combination with 
highway=bus_stop or railway=tram_stop.

 

Removing those tags from ways comes from the objection of some people that 
there would be both a way and a platform with the public_transport=platform tag.

 

In other words, the rendering of *=platform on WAYS is just fine as it is.

 

Polyglot

 

 

Op wo 20 jun. 2018 om 17:02 schreef Daniel Koć mailto:daniel@ko%C4%87.pl> >:

W dniu 19.06.2018 o 17:40, osm.tagg...@thorsten.engler.id.au 
  pisze:
> But I do not think that it is reasonable to add rendering for it, and at the 
> same moment drop rendering for highway=platform, railway=platform, 
> highway=bus_stop, railway=tram_stop and everything else that 
> public_transport=platform is meant to replace.
>
> This absolutely needs to be a two step process. Add rendering for 
> public_transport=platform first, then let people work on migrating existing 
> data. At some point in the future it might then become possible to drop 
> rendering for existing tags.

I want to make just one step now - replace *=platform with
public_transport=platform. Next steps might be very different and i
don't see them clearly now. It might even need PTv3 - I don't know, so I
won't touch it.

We could of course migrate by adding new type and removing old ones
after some time and I would do it. However on osm-carto we have a strong
opposition to rendering multiple similar tags (fear of fragmentation),
so I prefer to start with announcing the planned change and then make
the switch in rendering. It's just a different way of migration and if
it won't create (unnecessary in this case) tension and makes the whole
thing more probable to happen, I vote for it.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
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] public_transport=platform rendering on osm-carto

[osm.tagging]

I would very much welcome rendering of public_transport=platform. 

But I do not think that it is reasonable to add rendering for it, and at the 
same moment drop rendering for highway=platform, railway=platform, 
highway=bus_stop, railway=tram_stop and everything else that 
public_transport=platform is meant to replace.

This absolutely needs to be a two step process. Add rendering for 
public_transport=platform first, then let people work on migrating existing 
data. At some point in the future it might then become possible to drop 
rendering for existing tags.


> -Original Message-
> From: Daniel Koć 
> Sent: Wednesday, 20 June 2018 00:30
> To: tagging@openstreetmap.org
> Subject: [Tagging] public_transport=platform rendering on osm-carto
> 
> Hi,
> 
> When discussing rendering public_transport=platform on default
> OSM.org map style (osm-carto):
> 
> https://github.com/gravitystorm/openstreetmap-carto/pull/3232
> 
> I realized that highway=platform is not only marked on wiki as much
> less popular, but is also really 10 times less popular in the
> database. The same is true for railway=platform. Moreover this is
> true for years, before even osm-carto was created!
> 
> I think it's good to make a rendering shift then and drop both old
> schemes in favor of the public_transport=platform, with some grace
> period to not make anything in a hurry and allow smooth migration
> for the whole ecosystem. That might include deprecating message on
> both wiki pages to make things more clear.
> 
> Any comments on that?
> 
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
> 
> 
> 
> ___
> 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] emergency=lifeguard

[osm.tagging]

I just randomly checked out 20 of the places currently tagged with 
emergency=lifeguard_base and none of them looked like something for which 
office=lifeguard would seem appropriate, but all of them looked like what I 
expected, a place where you can find lifeguards, just with more equipment and 
infrastructure than a lifeguard_tower.

> -Original Message-
> From: marc marc 
> Sent: Tuesday, 19 June 2018 22:24
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] emergency=lifeguard
> 
> Le 19. 06. 18 à 13:56, Bryan Housel a écrit :
> >> the lifeguard base is defined for storage and administration
> 
> > It could be `office=lifeguard`
> 
> that look like a good idea at least for the administration
> ___
> 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] emergency=lifeguard

[osm.tagging]

From: Martin Koppenhoefer  
Sent: Tuesday, 19 June 2018 18:24
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=lifeguard

 

IMHO, if you want to tag the former, be explicit, do not use amenity=lifeguard 
because it is ambiguous, use something like amenity=lifeguard_station (or 
emergency rather than amenity).

 

 

 

The whole purpose of this thread is to move from emergency=lifeguard_base to 
emergency=lifeguard + lifeguard=base.

 

And the existing existing=water_rescue_station seem to be identical in meaning 
to lifeguard_base, as such should be changed into emergency=lifeguard + 
lifeguard=base.

 

Cheers,

Thorsten

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

Re: [Tagging] emergency=lifeguard

[osm.tagging]

Something like that is exactly what I as looking for…

 

From: Graeme Fitzpatrick  
Sent: Tuesday, 19 June 2018 14:24
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=lifeguard

 

 

On 19 June 2018 at 08:45, Graeme Fitzpatrick mailto:graemefi...@gmail.com> > wrote:

 

That's the concern I have with "place" - our lifesavers operate out of a surf 
club, a permanent building behind the beach (lifeguard=base). Each morning, 
they will decide the safest part of the beach, so will set up 200 m's right of 
the club this morning, but tomorrow they may be 100 m's left - that shouldn't 
be a lifeguard=place

 

Just had a thought as I'm starting to work on a wiki page.

 

Could we use lifeguard=area (or similar) to show that there is a lifeguard on 
duty somewhere in this area, but not at an exact location, or too messy?

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

Re: [Tagging] `amenity=shelter` implies `building=yes`?

[osm.tagging]

Personally, I would tag most bus shelters as building=roof. 

 

But for e.g. sun_shelter (which are usually just fabric spanned between poles) 
building=roof would be wrong.

 

From: Bryan Housel  
Sent: Tuesday, 19 June 2018 00:47
To: Jo Willems ; osm-tagging 
Subject: Re: [Tagging] `amenity=shelter` implies `building=yes`?

 

Thanks for clarifying Jo - I think this is all ok as long as we give users the 
option to say whether they think their `amenity=shelter` is a building or not.  
 For the bus shelters I could see it as either way but would not override a 
local mapper’s choice.

 

Maybe we should start a separate thread for “what is a `building=*` really” 
because this is something I see frequent confusion over.

 

Thanks, Bryan

 

 





On Jun 18, 2018, at 10:29 AM, Jo mailto:winfi...@gmail.com> > wrote:

 

shelter=yes on a highway=bus_stop NODE indicates there is a shelter nearby, but 
says nothing about where it is exactly nor its size.

 

amenity=shelter

shelter_type=public_transport

 

on a CLOSEDWAY

 

indicates where the shelter is. height is not super important. I guess most are 
about 2.3m high. If it is considered important I'll go out and measure one and 
start tagging that on them. But that still doesn't make them buildings. They 
are more like containers with glass wall panels and a metal roof on a slab of 
concrete. Relatively easy to move and relatively small in size.

 

Polyglot

 

Op ma 18 jun. 2018 om 15:28 schreef Bryan Housel mailto:bhou...@gmail.com> >:

There are also picnic shelters .. here they can have no walls just a roof to 
shelter from the heat of the sun or the occasional bit of rain. 
e.g. 
https://www.riversideca.gov/park_rec/sites/riversideca.gov.park_rec/files/pictures/Picnic%20Shelter%20Hunter%20hobby.JPG

 

I would tag that as:

 

amenity=shelter

building=roof( <— this tag is really the point of the thread)

 

 

The following three are no buildings from my point of view because they
have one wall only. Either the two other walls do not fully stretch from
the ground to the roof or the shelter itself can be removed easily.
 
https://www.mapillary.com/app/?lat=49.08680549357706 

 =9.078079866007897=17=90pd5WuYg8zOk_L8dxLFFQ=photo
https://www.mapillary.com/app/?lat=49.08985722389377 

 =9.07931005221235=17=oXQHKqb3Lc3Ae9IXj-5PHw=photo
https://www.mapillary.com/app/?lat=49.10616167487336 

 =9.121348618135698=17=8xUGL_VKp45sOfd9VW7dUw=photo

I would not use `amenity=shelter` at all and instead tag those as 

https://wiki.openstreetmap.org/wiki/Tag:highway=bus_stop

 

highway=bus_stop

public_transport=platform

bus=yes

shelter=yes

bench=yes

 

 

There is building=roof but I would not use it for such shelters. They
are not treated as buildings by the cadastre, why should I do? (If they
are larger and have no walls, they

Anything that should show up on a 3D map needs a `building` tag and maybe a 
`height`.





I think that nobody of us knows the whole world and that's why I ask you
not to decide on the default values of the whole world. If local mappers
think that a shelter is a building, they will tag it as such. If they
think that it does not qualify to be a building, they will not add the tag.

In iD, the things we provide as presets, and how we render those things on the 
screen influence how people map.

 

It sounds like from the discussion that we should not assume that shelters are 
buildings, and instead provide a field so that mappers can decide.  Once we 
provide this field, we can expect a lot of people to use it.  (I’m trying to 
engage the tagging list a lot more so that people feel consulted when I change 
things in iD.)

 

Thanks, Bryan

 

 

 

___
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] emergency=lifeguard

[osm.tagging]

From: Andrew Harvey  
Sent: Monday, 18 June 2018 21:17
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=lifeguard

 

Do we have any tagging scheme for “an area in which it is likely for a 
lifeguard to be”? I’m not sure if simply tagging an area with 
emergency=lifeguard lifeguard=place is appropriate for that.

 

  supervised=* to indicate 
if the beach has a lifeguard (yes, no, interval - in the format of  
 opening_hours=*) 
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbeach

 

 

 

Well, take as an example this beach: https://www.openstreetmap.org/way/17960956

 

I don’t think a blanket supervised=yes or lifeguard=yes is appropriate for that.

 

But there are multiple areas, each maybe a few 100m, somewhere in which a 
lifeguard is going to put down their flags, beach chair, umbralla, whatever 
regularly.

 

So the question becomes, what’s the appropriate tagging scheme for these areas?

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

Re: [Tagging] [talk-au] Mapping houses and addresses in Sydney

[osm.tagging]

Oops. Sorry, that went to the wrong mailing list :/

 

From: osm.tagg...@thorsten.engler.id.au  
Sent: Monday, 18 June 2018 21:07
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] [talk-au] Mapping houses and addresses in Sydney

 

From: Warin <61sundow...@gmail.com  > 
Sent: Monday, 18 June 2018 20:57
To: talk...@openstreetmap.org  
Subject: Re: [talk-au] Mapping houses and addresses in Sydney

 

On 18/06/18 20:30, Andrew Harvey wrote:

On 18 June 2018 at 19:21, Dion Moult mailto:d...@thinkmoult.com> > wrote:

Thanks Andrew for your reply!

 

1. Thanks for the link to the import guidelines. My responses to the import 
guidelines below:

 

First up I think any changesets that import addresses in this way should have 
an extra changeset tag so if we need to we can identify which changesets did 
the import (so more than just source=LPI NSW Base Map). Something like 
import=NSW Address Points or something.


source:import=LPI API via ?? something like that?



 

 

Following the import guidelines and using a dedicated account for such imports 
should already make it clear?

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

Re: [Tagging] [talk-au] Mapping houses and addresses in Sydney

[osm.tagging]

From: Warin <61sundow...@gmail.com> 
Sent: Monday, 18 June 2018 20:57
To: talk...@openstreetmap.org
Subject: Re: [talk-au] Mapping houses and addresses in Sydney

 

On 18/06/18 20:30, Andrew Harvey wrote:

On 18 June 2018 at 19:21, Dion Moult mailto:d...@thinkmoult.com> > wrote:

Thanks Andrew for your reply!

 

1. Thanks for the link to the import guidelines. My responses to the import 
guidelines below:

 

First up I think any changesets that import addresses in this way should have 
an extra changeset tag so if we need to we can identify which changesets did 
the import (so more than just source=LPI NSW Base Map). Something like 
import=NSW Address Points or something.


source:import=LPI API via ?? something like that?




 

 

Following the import guidelines and using a dedicated account for such imports 
should already make it clear?

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

Re: [Tagging] emergency=lifeguard

[osm.tagging]

No worries.

 

For what it’s worth, I fully agree with you. Any emergency=lifeguard[_*] that’s 
not anywhere close to water is pretty much guaranteed to be a tagging error.

 

While on the topic of lifeguards, lifeguard=place on a node doesn’t really fit 
to beaches where there a lifeguard place is usually, but it can be anywhere in 
a larger section of the beach on a day by day basis, depending on the weather 
and sea conditions at that moment.

 

Do we have any tagging scheme for “an area in which it is likely for a 
lifeguard to be”? I’m not sure if simply tagging an area with 
emergency=lifeguard lifeguard=place is appropriate for that. 

 

From: Warin <61sundow...@gmail.com> 
Sent: Monday, 18 June 2018 20:44
To: tagging@openstreetmap.org
Subject: Re: [Tagging] emergency=lifeguard

 

On 18/06/18 18:39, osm.tagg...@thorsten.engler.id.au 
  wrote:

From: Warin   <61sundow...@gmail.com> 
Sent: Monday, 18 June 2018 17:35
To: tagging@openstreetmap.org  
Subject: Re: [Tagging] emergency=lifeguard

 

On 18/06/18 16:24, osm.tagg...@thorsten.engler.id.au 
  wrote:

From: Graeme Fitzpatrick   
 
Sent: Monday, 18 June 2018 16:01
To: Tag discussion, strategy and related tools  
 
Subject: Re: [Tagging] emergency=lifeguard

 

while some show a shape in one image, but other's, possibly during the northern 
winter, show an empty deserted beach.

 

 

I would consider lifeguard=place to be still acceptable for these if there is 
some defined time when a lifeguard is present. Maybe specified with a seasonal 
tag or opening_hours (e.g. only on weekends or something like that).

 

If it is not near water .. then how does it match the general perception of 
'lifeguard'? 

Definition of lifeguard - an expert swimmer employed to rescue bathers who get 
into difficulty at a beach or swimming pool.

 

Where did I ever say something else?

 

Apologies .. me reading things that are not there?? 

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

Re: [Tagging] emergency=lifeguard

[osm.tagging]

> -Original Message-
> From: Marc Gemis 
> Sent: Monday, 18 June 2018 17:59
> To: Tag discussion, strategy and related tools
> 
> Subject: Re: [Tagging] emergency=lifeguard
> 
> If you use Google translate from English "lifeguard" to Russian,
> you get Спасатель Doing the translation in the other direction, (so
> from Спасатель to
> English) you get first "rescuer" and as a second "lifesaver".
> Perhaps this has something to do with the lifeguards found away
> from water in e.g . Russia ? Something that is "lost in
> translation" ?

Yeah, most likely. Which is why the OP suggested improving the wiki... With 
which I fully agree.



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

Re: [Tagging] emergency=lifeguard

[osm.tagging]

From: Warin <61sundow...@gmail.com> 
Sent: Monday, 18 June 2018 17:35
To: tagging@openstreetmap.org
Subject: Re: [Tagging] emergency=lifeguard

 

On 18/06/18 16:24, osm.tagg...@thorsten.engler.id.au 
  wrote:

From: Graeme Fitzpatrick   
 
Sent: Monday, 18 June 2018 16:01
To: Tag discussion, strategy and related tools  
 
Subject: Re: [Tagging] emergency=lifeguard

 

while some show a shape in one image, but other's, possibly during the northern 
winter, show an empty deserted beach.

 

 

I would consider lifeguard=place to be still acceptable for these if there is 
some defined time when a lifeguard is present. Maybe specified with a seasonal 
tag or opening_hours (e.g. only on weekends or something like that).

 

If it is not near water .. then how does it match the general perception of 
'lifeguard'? 

Definition of lifeguard - an expert swimmer employed to rescue bathers who get 
into difficulty at a beach or swimming pool.

 

Where did I ever say something else?

 

The one particular case I quoted, and for which I said lifeguard=place might 
still apply is “where a shape is visible in some imagery, but not in other” 
showing an “empty deserted *beach*”. Which pretty clearly implies that it’s 
near water.

 

I don’t think just because a lifeguard=place isn’t there 24/7, 365 days a year 
means it isn’t a lifeguard=place.

 

Which is why I said that tags like seasonal (e.g. only in summer) or 
opening_hours (e.g. only on weekend, only in specific know times, …) might 
apply.

 

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

Re: [Tagging] emergency=lifeguard

[osm.tagging]

From: Graeme Fitzpatrick  
Sent: Monday, 18 June 2018 16:01
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=lifeguard

 

while some show a shape in one image, but other's, possibly during the northern 
winter, show an empty deserted beach.

 

 

I would consider lifeguard=place to be still acceptable for these if there is 
some defined time when a lifeguard is present. Maybe specified with a seasonal 
tag or opening_hours (e.g. only on weekends or something like that).

 

 

Maybe the wiki's need to be modified (consolidated?) to emphasize that 
"lifeguard" refers to rescue of swimmers in the water?

 

 

 

I didn’t check it out myself, but, based on what you wrote, probably. Also, 
probably means that it’s not a good idea to just do a mechanical edit from the 
current tags to the new ones without reviewing all of them.

 

Cheers,

Thorsten

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

Re: [Tagging] Street exits

[osm.tagging]

They DO have exactly this type of living street in the Netherlands too, see 
https://nl.wikipedia.org/wiki/Woonerf

 

But the particular street Peter is talking about is, on purpose, NOT such a 
living street.

 

The street itself is a normal residential street, with sidewalks and raised 
kerbs. You can easily see that if you follow it along with streetview.

 

The only thing “special” about it is the way how they designed the point where 
it exits into the other street.

 

I can’t remember having seen this particular design (exit into another street 
designed like a living street or driveway, but the street itself being just a 
normal street) anywhere else.

 

Cheers,

Thorsten

 

From: yo paseopor  
Sent: Saturday, 16 June 2018 01:59
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Street exits

 

In Spain when we have this kind of exit applies the traffic sign and the rules 
of living street, as you can see in 
https://www.google.nl/maps/@41.2187293,1.7332079,3a,44.9y,155.43h,88.86t/data=!3m9!1e1!3m7!1swoQsNOW-rj_haPcAnawoYw!2e0!7i13312!8i6656!9m2!1b1!2i40
 , a normal street becomes living at the end and the exit to another "normal 
street". In OSM is https://www.openstreetmap.org/#map=19/41.21845/1.73337

I'm wondering if instead of not having the same traffic sign it would be the 
same thing...

 

Salut i mapes

yopaseopor

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

Re: [Tagging] Street exits

[osm.tagging]

From: Peter Elderson  
Sent: Friday, 15 June 2018 16:29
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Street exits

 

The street is residential, but the exit is over a sidewalk, with a dropped 
curb. That's the piece I'm talking about: not the street, just the exit.

 

Rules (legally) implied are that traffic can pass over this sidewalk, but has 
to give way to all sides and all others including pedestrians. Speed is limited 
to 15 Kmph (living_street rules).

 

 

Only for that part where it crosses the sidewalk, or for the whole street 
behind it?

 

As I’m normally mapping the kerb lines (way along the position of the kerb, 
with barrier=kerb and kerb=raised/lowered/rolled/flush) I would in this place 
have the highway crossing that kerb line, and would create an intersecting node 
(again tagged as barrier=kerb, kerb=lowered) (the same as when I’m mapping 
individual driveways, see: 
https://www.openstreetmap.org/edit#map=21/-27.21152/153.02620 ). But not 
everyone wants to map to this level of detail.

 

Maybe just a single barrier=kerb, kerb=lowered node on the highway to indicate 
that it has to cross the kerb?

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

Re: [Tagging] Street exits

[osm.tagging]

A quick search shows that it's probably not a "living street", as the concept 
does exist in the Netherlands, but does require explicit signs like in Germany:

https://nl.wikipedia.org/wiki/Woonerf

Also, in my experience "living streets" usually lack a clear kerb and 
distinction between road and sidewalk, which this street has if you follow it.

> -Original Message-
> From: Martin Koppenhoefer 
> Sent: Friday, 15 June 2018 16:17
> To: Tag discussion, strategy and related tools
> 
> Subject: Re: [Tagging] Street exits
> 
> 
> 
> sent from a phone
> 
> > On 15. Jun 2018, at 08:04, Peter Elderson 
> wrote:
> >
> > "If it looks like a driveway exit, treat it like a driveway exit"
> is the idea. Don't bother with signs, just use more sidewalk
> pavement.
> 
> 
> For me this piece of street does not look like a driveway, I would
> call it a residential street. In Germany it would probably be a
> living street.
> 
> Are there particular rules implied by the paving?
> 
> 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] Street exits

[osm.tagging]

If you follow the road in SV, you can see that it’s a normal road with it’s own 
name, and connections to other roads.

 

My first impulse was also “if it’s treated like a driveway, tag it as a 
driveway”, but it clearly isn’t one once you are actually in the road.

 

It’s only the part where it connected to the other road “like a driveway” 
instead of like a normal road.

 

From: Graeme Fitzpatrick  
Sent: Friday, 15 June 2018 16:18
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Street exits

 

Sorry if I've misunderstood Peter, but is there any difference between this & a 
normal driveway?




Thanks

 

Graeme

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

Re: [Tagging] maxweight=* specified for different axle counts

[osm.tagging]

Based on the documentation for conditional tags, I would say:

 

maxweight=10 st

maxweight:conditional=17 st @ (axles >= 4), 16 st @ (axles = 3)

 

it’s best to put the lowest limit as default into the non-conditional tag, so 
that if a software doesn’t or can’t parse the conditional tag it’s not going to 
exceed the limit, no matter what the situation.

 

From: David Wang  
Sent: Thursday, 14 June 2018 07:41
To: tagging@openstreetmap.org
Subject: [Tagging] maxweight=* specified for different axle counts

 

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

 

The situation in question is here:

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

 

For those who cannot see the image, the sign says

: WEIGHT LIMIT

: 2 axle - 10 tons

: 3 axle - 16 tons

: 4 axle + - 17 tons

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

 

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

 

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

 

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

 

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

 

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

 

Thanks,

David

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

Re: [Tagging] I can't support transit:lanes

[osm.tagging]

From: Paul Johnson  
Sent: Thursday, 14 June 2018 08:00
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] I can't support transit:lanes

 

So how is this different from placement=transition, then? 

 

 

 

placement=* defines the relation between the position of the way that defines 
that is used to specify the position of the road to the lanes.

 

Without a placement tag, the assumption is always that the way is in the exact 
centre the total width of all lanes.

 

with values like left_of:1, right_of:2, middle_of:3 you can specify that the 
way is at the left, right, or middle of a specific lane (lanes always counted 
from left to right, and matching the lanes defined in the :lanes suffix tags, 
not the lanes=x “full-width motorized” lanes.

 

You can see the effect of that in this screenshot from JOSM with the “lane and 
road attributes” mapstyle active:

https://www.dropbox.com/s/f18xbtvdcjg8syo/1520437709804.jpg?dl=0

https://www.dropbox.com/s/o5mgkj7bdmwe6rx/1523175198420.jpg?dl=0

 

Where possible, I’ve simply kept the ways following a specific on the ground 
lane, even when lanes are added and removed, by using that appropriate 
placement=* values. Otherwise, to be absolutely correct, the way would have had 
to wiggle left and right every time a lane is added or removed for a short 
section to keep the position of the way in the centre of the total width of all 
lanes.

 

placement=transition indicates that the way is not actually in a fixed position 
to the lanes for this segment. This is required at places where ways split or 
merge because we are using lines (the ways) to define the position of areas 
(the actual road surface).

 

For a concrete example, see (from the 2nd screenshot, motorway_link coming up 
in the bottom right corner): https://www.openstreetmap.org/way/577734615

 

At that point, it has 4 lanes, these lanes split into two 2 lane ways. For the 
short section where the split takes place, it’s impossible to define a correct 
placement value, as the way for the 4 lane section is in the middle of the 4 
lanes, while the way for the later 2 lane sections is also in the middle of 
each.

 

So for the two small sections where the way is not actually correctly 
positioned, you specify placement=transition, to basically tell the data 
consumer “you’ll have to figure this out based on how the lanes connect”:

 

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

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

 

transit:lanes on the other hand defines how the lanes connect from one way to 
another. While this information can, partially, in some cases, with some 
guessing, be derived by analysing the placement, and :lanes tags,  it’s much 
easier if the information is directly defined. 

 

It essential defines “if you are currently in a specific lane of way A and you 
go from way A to way B, what lane of way B will you be on without having to 
change lanes (crossing a lane dividing road marking)”. 

 

Cases where it’s definitely impossible to determine that from placement and 
other :lanes tags is the difference between a new lane being added (so you have 
to change lanes to get into it) and a lane forking (the lane gets wide enough 
to be two lanes, then a new dividing line is starting in the middle, you can 
essentially arrive at either of the two new lanes without changing lanes). As 
well as the same in reverse, a lane merging (the lane ends, you have to cross a 
dividing line to get out of it) or two lanes joining (the lane dividing road 
marking simply stops, going from two lanes to one double width lane, which then 
shrinks to normal lane width, in which case from both original lanes you will 
end up in the new lane without crossing a lane divider).

 

Take for a simple general example this way (also from the 2nd screenshot): 
https://www.openstreetmap.org/way/577734617

 

A motorway_link splits off: https://www.openstreetmap.org/way/577671984 while 
the way itself continues: https://www.openstreetmap.org/way/577671983

 

The lane connectivity from that first way to the two splitting ways is defined 
in two transit relations:

 

For the slipway: https://www.openstreetmap.org/relation/8189793

transit:lanes=continue|leave|leave

because it’s a :lanes suffix key, the number of | separated values must match 
the number of lanes defined in the other :lanes keys on the from way.

The value tells you that the left-most lane of the “from” way continues to the 
left-most (only in this case) lane of the to way. While the two lanes on the 
right do not connect to the “to” way at all (they go to some other way).

 

And for the through road: https://www.openstreetmap.org/relation/8189792

transit:lanes=leave|continue|continue

The value tells you that the left-most lane leaves to some other way, while the 
middle lane connects to the left-most lane of the “to” way and the right-most 
lane connects to the 2nd (and right-most) lane of the “to” way.

 

 

Another 

Re: [Tagging] RFC: amenity=waiting_room and amenity=waiting_area

[osm.tagging]

I would go for waiting_room=yes/no

 

And if we have waiting_room=foo/bar subtypes (no idea what subtypes there may 
be) for amenity=waiting_room in the future, then this naturally also applies to 
waiting_room tags on other features with any value other than no implying that 
there is a waiting room.

 

So you could have on its own node:

amenity=waiting_room

waiting_room=foo

 

or:

amenity=doctors

waiting_room=foo (implies waiting_room=yes)

 

 

From: Martin Koppenhoefer  
Sent: Wednesday, 13 June 2018 22:30
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] RFC: amenity=waiting_room and amenity=waiting_area

 

I had forgotten to name the property for things that provide a waiting room. 
Current proposal is "has_waiting_room" (it is less ambiguous than 
"waiting_room=*" which might also be used for subtypes, but it isn't how we 
usually operate). Please comment on this as well (same for the waiting area).

 

Cheers,

Martin

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

Re: [Tagging] RFC: amenity=waiting_room and amenity=waiting_area

[osm.tagging]

These both look pretty straight forward. I don’t see anything objectionable at 
first glance.

 

It might be interesting to explore how these interact with 
public_transport=platform. (e.g. train station, you got the platform edge, and 
behind that you have benches or individual seats along most of the platform, 
does the qualify as a waiting area? What about if there are no benches/chairs, 
is it still a waiting area?)

 

It might also be interesting to explore how you can indicate, beyond just being 
near it, what (separately mapped) service/event/thing you are waiting for at 
that area.

 

From: Martin Koppenhoefer  
Sent: Wednesday, 13 June 2018 20:45
To: Tag discussion, strategy and related tools 
Subject: [Tagging] RFC: amenity=waiting_room and amenity=waiting_area

 

I am asking for your comments on 

amenity=waiting_room 

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

 

and 

amenity=waiting_area

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

 

 

Please preferably comment on the discussion pages of the proposals.

 

Thank you,

Martin

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

Re: [Tagging] The endless debate about "landcover" as a top-level tag

[osm.tagging]

From: Mateusz Konieczny  
Sent: Wednesday, 13 June 2018 19:49
To: Tag discussion, strategy and related tools 
Cc: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] The endless debate about "landcover" as a top-level tag

 

13. Jun 2018 11:36 by marc.ge...@gmail.com  :

And landuse=grass doesn't make any sense at all. I'm not aware of any place 
where "grass" would be an appropiate land*use*.

And that is why landuse=grass is used to map landcover - not land use.

 

https://i.chzbgr.com/full/9175618304/hD5996842/

 

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

Re: [Tagging] The endless debate about "landcover" as a top-level tag

[osm.tagging]

For me, the situation (as it should be, not as it is) is pretty clear.

 

 

 

Landuse describes how the land is used. 

 

residential, industrial, commercial, retail, military, farmland, forestry, ...

 

None of these have a fixed implication of what's on the land.

 

 

 

Landcover describes what's on the land.

 

grass, scrub, trees, concrete, ...

 

None of these have a fixed implication if the landcover is natural or man made 
or managed.

 

 

Any point on the map has one actual landuse and one actual landcover.

 

 

You can have an area tagged as landuse=forestry and inside that area (or 
partially overlapping it) you have a mix of areas with landcover trees, grass, 
scrub, rock, whatever.

 

 

If you have some trees in a backyard, that's landcover=trees in 
landuse=residential.

 

 

If you have a forest that's just been completely logged and is just starting to 
regrow, that's landuse=forestry, landcover=scrub (probably, I'm sure someone 
can come up with a proper sequence of landcovers for an area that goes from 
trees to stumps and back to trees).

 

 

That landuse=forestry is what landuse=forest should be, but it has been 
completely burned by misuse to paint the map green and there is no way to 
recover from that really.

 

And landuse=grass doesn't make any sense at all. I'm not aware of any place 
where "grass" would be an appropiate land*use*. 

 

If you are growing grass for animals, that's farmland or meadow. If you are 
growing it because you want to sell it as rollout grassm that's farmland. 

 

If it's beside a road, that's either landuse=highway (if it's still part of the 
public right of way) or part of whatever landuse (residential, commercial, ...) 
describes the area outside the road.

 

If it's "municipal greenery" it's probably either landuse=highway (if it's 
still part of the public right of way) or landuse=recreation_ground.

 

No matter what, *grass* is not a land*use*. It's what happens to *cover* the 
land to fullfil some other *use*.

 

 

From: Martin Koppenhoefer  
Sent: Wednesday, 13 June 2018 19:24
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] The endless debate about "landcover" as a top-level tag

 

btw., we have only been discussing the term forest for landcover=trees, but 
there are other places where trees grow, e.g. orchards, groves, copses, bosks, 
thickets. We do have orchard as a tag, but we do not have anything specific for 
copses and groves (some might be mapped as orchards?). Thickets are generally 
mapped as natural=scrub? Bosk is a synonymon for grove?

 

What about the distinction "forest" and "wood"? Is a wood smaller and a forest 
denser?

 

Cheers,

Martin

 

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

Re: [Tagging] I can't support transit:lanes

[osm.tagging]

No you don’t. 

 

transit:lanes describes how the lanes from the end of one way connect to the 
end of another way in the direction of traffic flow.

 

For each pair of from/to ways, there is going to be exactly one node where they 
connect. That is your via node.

 

From: Paul Johnson  
Sent: Wednesday, 13 June 2018 08:46
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] I can't support transit:lanes

 

You'd have more than one via way for the transit:lanes relation. 

 

On Tue, Jun 12, 2018, 01:11 Mateusz Konieczny mailto:matkoni...@tutanota.com> > wrote:


11. Jun 2018 23:02 by ba...@ursamundi.org  :

On Sun, Jun 10, 2018, 23:43 Bryan Housel mailto:bhou...@gmail.com> > wrote:

The only way I’ll be able to support lane transitions would be as a relation 
that has similar semantics to turn restrictions.. from/via/to.  Keep it simple 
(no multi via ways please).  This is already an understood way of tagging 
things that connect 2 ways. 

 

Driveway in the middle of a lane transition with turn restrictions.  What now?

 

No problem? Why it would be an issue? 

___
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] I can't support transit:lanes

[osm.tagging]

From: Simon Poole  
Sent: Tuesday, 12 June 2018 01:44
To: tagging@openstreetmap.org
Subject: Re: [Tagging] I can't support transit:lanes

 

 

You are seriously telling me that if you have two ways that share a node, you 
are unable to figure out what that node is without having it explicitly listed 
as a totally redundant member of the relation?

No, we are all quite capable of figuring that out. The issue is having to 
hardwire semantics for one tag out of 1000s and while there are a lots of 
special cases, mainly when reversing ways, this would be a first for splitting 
(and merging likely too).   

Simon




 

Talking about two different things here.

 

You are talking about transition tags on ways. Fine. As long as editors provide 
an easy way to create, see and change transition information in relations 
without having to manually create these relations, there is no need for 
transition tags on ways. Their whole purpose was to make possible for mappers 
to tag this without going crazy (which they are going to if you disallow the 
tags on the ways without providing real editor support that hides away the 
complexity of the relations).

 

 

Bryan says he is unable to handle a type=transition relation with only a from 
and to way as member, without a via node member.

 

 

I’m saying that different from turn restrictions, transitions can’t have ways 
as vias or multiple vias. So the rule is simply: for a transition relation to 
be valid, the from and to way need to have single node that’s shared between 
them. That node is always the via node. There is no need to explicitly specify 
it in the relation. It’s already given by the from and to ways.

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

Re: [Tagging] I can't support transit:lanes

[osm.tagging]

 

 

From: Bryan Housel  
Sent: Tuesday, 12 June 2018 01:12
To: osm-tagging 
Subject: Re: [Tagging] I can't support transit:lanes

 

Two issues here.

First, the tag is not “transit:lanes” the tag is “transit” and it can be used 
with the generalized “:lanes” suffix. 

There are general rules for the :lanes suffix which can be added to pretty much 
any tag you would have on a highway were the value could be different for 
different lanes. See   
https://wiki.openstreetmap.org/wiki/Lanes

It’s the same with e.g. “turn:lanes” (a “turn” key with the “:lanes” suffix) or 
“access:lanes” (a “access” key with the “:lanes” suffix).

 

.. none of this matters because the tag can’t go on a way anyhow.

 

 

 

It matters very much, as the person was proposing to use a lanes:something tag 
to tag information that is clearly belonging into a :lanes tag (as it will 
has to provide per lane information, following exactly the same rules as any 
other :lanes tags)

 

 

 

Second, the “transition” tag is already in use:  
 
https://taginfo.openstreetmap.org/keys/transition

Now, as far as I can tell, these are pretty much all transition=yes tags on 
power=tower or power=pole nodes. These seem to be left-overs from a previous 
tagging scheme, which has been replaced by the use of the 
location:transition=yes tag (and at 342 vs 13388 uses that seems to have been 
well accepted by now). 

So I guess it might be possible to coordinated with people that are involved in 
power mapping to have these remaining ones retagged to free up the transition 
key.

The type=transition value is currently unused, so in that regard the change 
would be fine.

 

Ok, so add a new type of relation and call it `type=lane_transition`

https://wiki.openstreetmap.org/wiki/Types_of_relation

 

 

 

you are mixing relation type and the tag used to describe the transition here.

 

type=transition has 0 uses and there is no problem using it.

 

There are currently 342 transition=* tags being used (for something totally 
different), but they all should be location:transition tags anyway by now as 
far as I can tell.

 

 

 

 

 

I agree that this tag when used on ways is problematic from an editor 
perspective. 

Though by following pretty simple rules, the editor could prevent the 
transit(ion):lanes tag on a way from breaking:

 

Maybe seems simple to you, but I’m not going to do it, and the JOSM and 
Vespucci folks have also already said no too. 

 

 

 

As I said, if you have proper editor support for transitions so that people 
don’t have to fiddle around with manually creating relations, then there is no 
need for transit(ion) tags on ways. If such editor support is missing and the 
quick and simple tagging on the ways is eliminated, then it’s going to be DOA 
because nobody is going to be crazy enough to create all these relations by 
hand.

 

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

Re: [Tagging] I can't support transit:lanes

[osm.tagging]

From: Bryan Housel  
Sent: Tuesday, 12 June 2018 01:12
To: osm-tagging 
Subject: Re: [Tagging] I can't support transit:lanes

 

I’ve already written plenty of code to deal with turn restrictions.  There are 
lots of rules for splitting and joining things to other things depending on 
where the via node is. 

 

If you are curious, here is a recent commit where I tried to improve iD’s 
handling of this.

https://github.com/openstreetmap/iD/commit/87841fc4035c7de9e0f58ca50f05f65723ad5226

 

In other words if this new relation works like a turn restriction, it’s already 
mostly supported… Otherwise expect basic editing (like splits, joins, 
connections) to break it.

 

 

You are seriously telling me that if you have two ways that share a node, you 
are unable to figure out what that node is without having it explicitly listed 
as a totally redundant member of the relation?

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

Re: [Tagging] emergency=fire_alarm_box

[osm.tagging]

Well, I’ve often seen their location marked on emergency plans. I agree that 
they aren’t something that should normally be rendered at most of the usual 
zoom levels used for OSM, but once you get into detailed indoor mapping, I 
think they are something that’s worthwhile mapping.

 

From: Paul Allen  
Sent: Tuesday, 12 June 2018 01:00
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=fire_alarm_box

 

On Mon, Jun 11, 2018 at 3:50 PM, mailto:osm.tagg...@thorsten.engler.id.au> > wrote:

And many other places, yes… that’s why I was surprised to see that 
emergency=stop_button has only been used a single time worldwide and there 
don’t seem to be any other similar values in the emergency key.

 

The thing about emergency stop buttons is that they tend to be highly visible, 
in obvious locations, and there are

often big signs. You shouldn't need a map to help you find one because they're 
for rapid use in an emergency.

Maybe for petrol stations it's a good idea, if there's only one such button for 
all the pumps.  But even then you're

not going to look at a map to find it, you'll look for the sign.

So I'm not surprised they haven't been mapped very often.

-- 

Paul
 

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

Re: [Tagging] emergency=fire_alarm_box

[osm.tagging]

And many other places, yes… that’s why I was surprised to see that 
emergency=stop_button has only been used a single time worldwide and there 
don’t seem to be any other similar values in the emergency key.

 

From: Philip Barnes  
Sent: Tuesday, 12 June 2018 00:26
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=fire_alarm_box

 

Stop buttons are also found on escalators.

Phil (trigpoint) 

On 11 June 2018 15:16:59 BST, osm.tagg...@thorsten.engler.id.au 
  wrote:

From: Warin <61sundow...@gmail.com  > 
Sent: Monday, 11 June 2018 17:34
To: tagging@openstreetmap.org  
Subject: Re: [Tagging] emergency=fire_alarm_box

 

On 11/06/18 15:29, osm.tagg...@thorsten.engler.id.au 
  wrote:

On a remotely related note, while looking through taginfo, I was surprised that 
emergency=stop_button has only 2 uses and there don’t seem to be any other 
values to tag something of that nature.

 

On Wikipedia it’s documented at https://en.wikipedia.org/wiki/Kill_switch

 

A tag for this would certainly be useful e.g. for petrol stations to mark the 
location of the emergency stop button for the pumps…

 

Stop buttons are also used in workshops - to stop rotating machinery without 
getting near it, can save a life. 

 

Yes, that was my point.  Emergency stop buttons aka kill switches (Not-Aus in 
German) are something that should be of general interest to map, and the ones 
for the pumps at a petrol station is just one possible example.

In addition to just tagging the position of the emergency=stop_button, some 
scheme to define what exactly is affected by it might be useful.

e.g. something like a type=effect relation, with effect=stop (or 
emergency_stop) and the emergency=stop_button node (role = effecter or maybe 
source) and man_made=fuel_pump nodes (role = empty or maybe target).

That general scheme could be applied to pretty much everything. If someone 
wants to go wild with indoor mapping and map light fixtures and switches, no 
problem. Call buttons for elevators, door bells, whatever.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Tagging] emergency=fire_alarm_box

[osm.tagging]

From: Warin <61sundow...@gmail.com> 
Sent: Monday, 11 June 2018 17:34
To: tagging@openstreetmap.org
Subject: Re: [Tagging] emergency=fire_alarm_box

 

On 11/06/18 15:29, osm.tagg...@thorsten.engler.id.au
  wrote:

On a remotely related note, while looking through taginfo, I was surprised
that emergency=stop_button has only 2 uses and there don't seem to be any
other values to tag something of that nature.

 

On Wikipedia it's documented at https://en.wikipedia.org/wiki/Kill_switch

 

A tag for this would certainly be useful e.g. for petrol stations to mark
the location of the emergency stop button for the pumps.

 

Stop buttons are also used in workshops - to stop rotating machinery without
getting near it, can save a life. 

 

Yes, that was my point.  Emergency stop buttons aka kill switches (Not-Aus
in German) are something that should be of general interest to map, and the
ones for the pumps at a petrol station is just one possible example.

In addition to just tagging the position of the emergency=stop_button, some
scheme to define what exactly is affected by it might be useful.

e.g. something like a type=effect relation, with effect=stop (or
emergency_stop) and the emergency=stop_button node (role = effecter or maybe
source) and man_made=fuel_pump nodes (role = empty or maybe target).

That general scheme could be applied to pretty much everything. If someone
wants to go wild with indoor mapping and map light fixtures and switches, no
problem. Call buttons for elevators, door bells, whatever.

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

Re: [Tagging] Feature Proposal - RFC - Lounges

[osm.tagging]

From: Stephen Doerr  
Sent: Monday, 11 June 2018 21:18
To: Tag discussion strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - RFC - Lounges

My experience may be different from yours, but no one I know talks about a 
'waiting room' in an airport. The general waiting area is quite often referred 
to as the 'departure lounge', in fact. 

Agreed. Though despite it being called a “departure lounge” I wouldn’t consider 
that an amenity=lounge. That’s just the airport trying to make themselves sound 
more fancy than they are.

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

Re: [Tagging] I can't support transit:lanes

[osm.tagging]

From: Jo  
Sent: Monday, 11 June 2018 17:47
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] I can't support transit:lanes

 

Name should indeed be changed, but I'd go for lanes:transition, so it 
groups with the other lanes related tags. Not sure if that is a good type for 
the relation though.

 

 

 

Two issues here.

 

First, the tag is not “transit:lanes” the tag is “transit” and it can be used 
with the generalized “:lanes” suffix. 

 

There are general rules for the :lanes suffix which can be added to pretty much 
any tag you would have on a highway were the value could be different for 
different lanes. See https://wiki.openstreetmap.org/wiki/Lanes

 

It’s the same with e.g. “turn:lanes” (a “turn” key with the “:lanes” suffix) or 
“access:lanes” (a “access” key with the “:lanes” suffix).

 

So changing it to lanes:whatever would totally change the semantics of the key.

 

Second, the “transition” tag is already in use: 
https://taginfo.openstreetmap.org/keys/transition

 

Now, as far as I can tell, these are pretty much all transition=yes tags on 
power=tower or power=pole nodes. These seem to be left-overs from a previous 
tagging scheme, which has been replaced by the use of the 
location:transition=yes tag (and at 342 vs 13388 uses that seems to have been 
well accepted by now).

 

So I guess it might be possible to coordinated with people that are involved in 
power mapping to have these remaining ones retagged to free up the transition 
key.

 

The type=transition value is currently unused, so in that regard the change 
would be fine.

 

 

From: Simon Poole  
Sent: Monday, 11 June 2018 18:43
To: tagging@openstreetmap.org
Subject: Re: [Tagging] I can't support transit:lanes

 

Just as Bryan does, I can see supporting special casing transit relations (as 
we already have to do the same for turn restrictions). I am -very

 

 

The transit:lanes proposal goes into a lot of details about why it can be 
tagged on both relations and ways, and I’m not going to repeat all that. 

 

It boils down to that tagging it on a way is much simpler for the mapper (for 
cases where the from and to ways are unambiguous from context). With current 
tools, creating a type=transit relation manually is at least an order of 
magnitude more work than just tagging it on the way.

 

IF transit(ion) relations would have first class editor support, at the level 
of the turn restriction editor in iD. Then I would see no need for keeping 
support for transit:lanes on ways. 

 

 

 

From: Bryan Housel  
Sent: Monday, 11 June 2018 14:42
To: osm-tagging 
Subject: [Tagging] I can't support transit:lanes

 

I’ve had a few recent conversations about this proposal:

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

 

Unfortunately I can’t support it.

 

Not only is the name bad (it should be named `transition:lanes` but whatever), 
the bigger problem is that, as proposed, the tag can be placed on either a way 
or a relation.

 

 

See above for feedback on both these points.

 

 

 

The problem with tagging these on ways is that if you split the way, the tag 
breaks.  

 

No other tag works this way (except maybe for address interpolation lines, but 
presumably anybody splitting one of those would know that they need to adjust 
the numbers on the endpoints).  

 

I’m not going to add a special rule in iD to warn people if they are splitting 
a way with a lane transition tag.  I don’t want to speak for the JOSM devs, but 
I doubt they would implement something like this either.

 

 

 

I agree that this tag when used on ways is problematic from an editor 
perspective. 

 

Though by following pretty simple rules, the editor could prevent the 
transit(ion):lanes tag on a way from breaking:

 

https://pastebin.com/BGWvp6QU

 

IF there is proper first class editor support for creating/maintaining 
transit(ion) information, then there would be no need to allowing to tag it on 
ways directly.

 

 

The only way I’ll be able to support lane transitions would be as a relation 
that has similar semantics to turn restrictions.. from/via/to.  Keep it simple 
(no multi via ways please).  This is already an understood way of tagging 
things that connect 2 ways.  (could you imagine if we tagged turn restrictions 
as  maybe-a-relation or maybe-a-way-tag ?? nope!)

 

 

Transit relations have no via, and they don’t need a via. The from and to way 
should always touch at exactly one node. Otherwise they are invalid. So you can 
always determine the “implicit” via node from that.

 

Other then that, yes, they should be treated pretty much like turn restriction 
relations.

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

Re: [Tagging] Fwd: Feature Proposal - Voting - Dog poop area (dog_toilet)

[osm.tagging]

There is already:

 

amenity=waste_basket + waste=dog_excrement

 

often co-located with a:

 

https://wiki.openstreetmap.org/wiki/Tag:vending%3Dexcrement_bags

 

Tagging of collection bags and bins should probably make use of existing tags 
for such features instead of adding new ones.

 

Same in regards to availability of water, though I haven’t looked into what if 
any existing tags are already used for that.

 

From: José G Moya Y.  
Sent: Monday, 11 June 2018 15:49
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Fwd: Feature Proposal - Voting - Dog poop area 
(dog_toilet)

 

Hi!

Just a question. I think someone else (or maybe myself) asked it on a previous 
discussion. You provide means to tag collection bags and bins. 

How do we tag when we only have the bins (but not a dedicated poop area)? 

 

Thanks.

 

Greetings from Madrid,

 

José Moya

 

El lun., 11 de junio de 2018 0:54, Warin <61sundow...@gmail.com 
 > escribió:

On 11/06/18 02:51, Mateusz Konieczny wrote:




10. Jun 2018 14:50 by joost.schou...@gmail.com 
 :

The four options could be moved somewhere else; I just left them for reference. 
What should I do with them? I'd hate to just delete it. 

 

I edited page to describe them as considered and rejected alternatives. 


I would move them (all the detail) to the 'discussion page' to remove clutter. 
Leave a comment on it on the main page referring to the discussion page if they 
want more info. 

___
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] emergency=lifeguard

[osm.tagging]

From: Andrew Harvey  
Sent: Monday, 11 June 2018 15:31
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=lifeguard

 

> Also, water_rescue_station is probably identical to lifeguard_base

 

Agree based on the description given at 
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dwater_rescue_station it 
sounds like lifeguard_base.

 

Just based on the tag name I thought it meant something like 
https://en.wikipedia.org/wiki/Coast_guard. The wikipedia page seems to indicate 
coast_guard is a common term internationally (even though many of the agencies 
worldwide aren't known as the "Coast Guard", it seems like it's common enough 
for emergency=coast_guard.

 

 

That was my first thought too, but then I looked at the description on the wiki 
and it very much sounds like a life guard base and not a coast guard station.

 

 

I wonder if any of the current water_rescue_station's are really coast guards?

 

 

That’s certainly possible. If the decision is made to merge these keys, they 
will probably all need to be manually checked.

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

Re: [Tagging] emergency=fire_alarm_box

[osm.tagging]

Just because something “can be found just about anywhere” isn’t really a valid 
argument for not mapping it.

 

If someone is doing detailed indoor mapping of building and wants to map 
emergency features, the location of fire alarms is certainly something I would 
consider to be worthwhile mapping.

 

Also, when someone is looking for a fire alarm, I don’t think it really matters 
if it’s fire alarm box nailed to a pole on the street or one of these small 
ones you find inside buildings. Either one will get the fire fighters informed 
and into roughly the right location.

 

From: Graeme Fitzpatrick  
Sent: Monday, 11 June 2018 15:22
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] emergency=fire_alarm_box

 

The first thing fire alarm box brought to my mind was the common "Break glass" 
fire alarms 
http://www.az100years.org/wp-content/uploads/2018/01/photodune-781034-fire-alarm-s.jpg,
 which are found just about everywhere, so would be virtually unmappable?

 

Is there risk of confusion between the two?




Thanks

 

Graeme

 

 

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

Re: [Tagging] emergency=fire_alarm_box

[osm.tagging]

I noticed there are also 24 uses of emergency=fire_callbox, which I assume
is something similar. And, surprising, just 1 uses of a more generic
fire_alarm.

 

I'm not sure if there really is an important enough distinction between a
fire alarm box and a fire alarm as you find them inside buildings and it
might be worthwhile to just merge all 3 tags into a single
emergency=fire_alarm. If necessary a subtag fire_alarm=* could be added.

 

 

On a remotely related note, while looking through taginfo, I was surprised
that emergency=stop_button has only 2 uses and there don't seem to be any
other values to tag something of that nature.

 

On Wikipedia it's documented at https://en.wikipedia.org/wiki/Kill_switch

 

A tag for this would certainly be useful e.g. for petrol stations to mark
the location of the emergency stop button for the pumps.

 

From: Bryan Housel  
Sent: Monday, 11 June 2018 14:29
To: osm-tagging 
Subject: [Tagging] emergency=fire_alarm_box

 

I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency today.

 

Someone just made this page for emergency=fire_alarm_box a few weeks ago

https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_alarm_box
 

 

It seems like a good idea.  Should it be a thing?

 

Thanks , Bryan

 

 

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

Re: [Tagging] emergency=lifeguard

[osm.tagging]

These are different things, and the differentiation should definitely not 
simply thrown away.

 

Though I’m not fundamentally opposed to making it a hierarchical tag along the 
lines of:

 

emergency=lifeguard

lifeguard=base/place/platform/tower

 

Also, water_rescue_station is probably identical to lifeguard_base

 

All the usual arguments for and against trying to change tags “by decree” apply…

 

From: Bryan Housel  
Sent: Monday, 11 June 2018 14:22
To: osm-tagging 
Subject: [Tagging] emergency=lifeguard

 

I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency today.

 

We have too many tags for different kinds of lifeguards.  This is too confusing.

I don’t want to have to show all these choices to iD users.

 


tag

uses


  
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_base

202


  
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_place

39


  
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_platform

24


  
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_tower

424


  
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dwater_rescue_station

197

 

 

More details here:

https://github.com/openstreetmap/iD/issues/4918#issuecomment-374611561

 

 

Let’s just use one tag `emergency=lifeguard`

We can change this before the tags gain too much more traction (a few hundred 
uses is not very many)

 

If people really want to map whatever the lifeguard sits on, they can use a 
different tag for that.

`lifeguard_type=platform`  or `tower` or something.

 

 

Thanks, Bryan

 

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

Re: [Tagging] emergency=first_aid_kit

[osm.tagging]

That seems reasonable to me.

 

From: Bryan Housel  
Sent: Monday, 11 June 2018 14:08
To: osm-tagging 
Subject: [Tagging] emergency=first_aid_kit

 

I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency today.

 

Can we add a tag for `emergency=first_aid_kit` ?

 

thanks, Bryan

 

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

Re: [Tagging] Feature Proposal - RFC - Sauna

[osm.tagging]

It might be interesting to tag the presence of a cold plunge pool/dunking pool.

> -Original Message-
> From: Jyri-Petteri Paloposki 
> Sent: Monday, 11 June 2018 01:47
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - Sauna
> 
> On 10.06.2018 18:34, Johnparis wrote:
> > You might (or might not) want to reconcile this with
> > https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bath
> 
> Thanks for the suggestion! A sauna, at least in Finland, is quite
> different from a public bath. These two might of course exist in
> the same place: A sauna nicely adds to a public bath, but most
> saunas in Finland are just the sauna room next to the bathroom –
> and quite often even without, for example at cabins that allow you
> to wash yourself in the water. So I think we should change the
> division; though I'll probably edit the Related tags -description
> in amenity=public_bath, it's a bit misleading.
> 
> Best regards,
> --
> Jyri-Petteri Paloposki
> 
> ___
> 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 - Lounges

[osm.tagging]

I fully agree that something like a “normal” waiting area, like the area at the 
gate for an airport, or the waiting room at a hospital, dentist or whatever is 
not a lounge. Nobody proposed to tag these as amenity=lounge.

 

The proposal is for “A distinct tag for lounges, such as those in airports and 
at stations.”

 

and:

 

“Lounges are found not only in airports (although some users might associate 
lounges primarily with airline-branded offerings), but also train/bus stations, 
hotels (often called an "Executive lounge") and ferry terminals. These are 
generally places offering shelter, food/drink, sometimes shower and sleeping 
facilities. A major transport hub can feature a number of lounges.

 

Considering the quantity of such POIs and, often, their importance to a 
traveller, it makes sense to have a custom tag for them. It is an amenity 
distinct from others, despite offering services that can often be associated 
with e.g. a bar, buffet or cafe.”

 

Nowhere here does it say that the waiting room at your local doctor should be 
tagged as an amenity=lounge.

 

But for the things that the proposal specifically targets, amenity=lounge seems 
an adequate label to me.

 

If there is one thing I find objectionable in the proposal, it’s the “A simpler 
lounge at DXB” example. THAT is not something I would consider a lounge. 

 

From: Paul Allen  
Sent: Monday, 11 June 2018 00:56
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - RFC - Lounges

 

 

 

On Sun, Jun 10, 2018 at 3:20 PM, mailto:osm.tagg...@thorsten.engler.id.au> > wrote:


At Stations

The First Class lounges are open Monday to Friday and are a great place to work 
or relax while you're waiting for a train. They offer complimentary 
refreshments, WiFi, fax and phone services are available.

 

Again, these are NOT waiting rooms.  They REQUIRE a purchase for use.  In this 
instance, the purchase of a

first-class ticket.  They cannot be used without payment.

They're an argument for a subtag, perhaps (purchase_required, or free=no or 
some such) but they are not arguments

for tagging waiting rooms amenity=lounge.  Perhaps an argument for 
amenity=lounge as well as
amenity=waiting_room but I suspect that would cause more problems than it 
solves.

I can be convinced.  Point me to evidence of widespread hospital lounges, 
doctors' surgery lounges, dentists'

lounges, etc. and I will change my mind.  Until then, it appears that the vast 
preponderance of waiting rooms

at railway stations compared to a handful of lounges, means that 
amenity=waiting_room is the way to go.

-- 

Paul

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

Re: [Tagging] Feature Proposal - RFC - Lounges

[osm.tagging]

> -Original Message-
> From: ael 
> Sent: Sunday, 10 June 2018 23:26
>
> In British English, a lounge first and foremost is a room in a
> private dwelling. Other uses have "leaked in" from other dialets
> and while now fairly well understood in a limited number of
> contexts, they are still unnatural.

Well, in the context of airports, I've never heard these referred to by any 
other names.

See e.g.:

https://www.gatwickairport.com/at-the-airport/flying-out/Airport-lounges/

or

https://www.heathrow.com/airport-guide/terminal-facilities-and-services/lounges

The term seems also to be common in the context of railways:

http://www.nationalrail.co.uk/stations_destinations/44863.aspx

At Stations

The First Class lounges are open Monday to Friday and are a great place to work 
or relax while you're waiting for a train. They offer complimentary 
refreshments, WiFi, fax and phone services are available.

Lounges are available at:

London's St Pancras International on the upper concourse, near the statue 
of Sir John Betjeman
Nottingham Platform 4 / 5
Derby on Platform 4
Leicester on Platform 3





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

Re: [Tagging] Feature Proposal - RFC - Sauna

[osm.tagging]

If you are tagging one individual leisure=sauna, it makes sense that the sauna 
key has only one value. 

But if you are tagging sauna=* on a hotel or other larger object that contains 
a sauna, there might be different ones available.

In that case, there should be some defined way to allow multiple values, 
probably either:

sauna=hot;steam;dry

or

sauna:hot=yes
sauna:steam=yes
sauna:dry=yes

The 2nd variant has the advantage that it invites easy extensions like:

sauna:hot:count=3
sauna:steam:opening_hours=16:00:22:00



> -Original Message-
> From: Jyri-Petteri Paloposki 
> Sent: Sunday, 10 June 2018 22:36
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - Sauna
> 
> On 10.06.2018 15:14, Mateusz Konieczny wrote:
> > What is the point of adding sauna=yes to leisure=sauna?
> 
> None. sauna=yes is currently apparently used when tagging other
> features than leisure=sauna that also have a sauna (hotels etc.)  I
> amended the proposed description to state that sauna=yes should
> only be used with features other than leisure=sauna.
> 
> Best regards,
> --
> Jyri-Petteri Paloposki
> 
> ___
> 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 - Lounges

[osm.tagging]

A “waiting room” is something very different from an airport lounge.

 

In the context of an airport, a waiting room (or rather, waiting area) is 
something like this:

 

https://upload.wikimedia.org/wikipedia/commons/8/8d/Kolkata_Airport_New_Terminal_gate_waiting_area.jpeg

 

They are part of the normal infrastructure of the airport, operated and 
maintained by the airport and accessible to everyone.

 

An airport lounge on the other hand is something like this:

 

https://www.gatwickairport.com/globalassets/passenger-facilities/no1-lounges-gatwick-south-terminal-6.jpg

 

It’s very common for them to be operated by a specific airline or by a company 
that specifically operates one or more airport lounges instead of the airport. 
Entrance is generally limited, by a fee at the entrance, holding the right type 
of ticket from the right airline, membership card, … it varies.

 

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

 

This is a very specific term for a very specific service.

 

I’m very sure that at any airport in the world, if you are speaking English, 
and ask for the way to the “lounge” after finishing your check-in, the staff 
will politely explain to you how to get the lounge for their airline, bit if 
you ask for the way to the “waiting room”, they’ll either send you off to your 
gate or look at you in incomprehension.

 

 

 

From: Paul Allen  
Sent: Sunday, 10 June 2018 22:17
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - RFC - Lounges

 

On Sun, Jun 10, 2018 at 12:40 PM, Yves mailto:yve...@gmail.com> > wrote:

I don't necessarily want to get rid of the word lounge, but an 
amenity=airport_lounge leaves very little doubt about what it is.

 

Actually, it does leave doubt.

Airport lounge as in waiting room?  A place with seats and (maybe) a coffee 
machine but you don't have to

buy anything to sit there?

Or airport lounge as in a bar where you have to buy a drink to sit there?

Lounge, at least in my part of the world (the UK) doesn't mean what you want it 
to mean.  Nor does "airport lounge."

Waiting room, however, is EXACTLY what you want to describe.  Hospitals and 
doctors' surgeries have waiting rooms.
So do train stations and bus stations.

The second-worst thing about airport_lounge is that you'll then need 
train_station_lounge, bus_station_lounge,

hospital_lounge, etc., when they could all be waiting_room because that is what 
those things are called in British

English.  Tell somebody to sit in the hospital lounge and they'll wonder what 
you mean; tell them to sit in the

waiting room and they'll know exactly what you mean.

Perhaps, in your language, lounge is the correct word,  In which case 
translations for editor presets would

use "waiting room" in my language and "lounge" in yours.  The wiki would use 
"waiting room" on the English page
and "lounge" for the same page in your language.  The underlying tag in the 
database, however, would use
"waiting_room."

I am firmly, solidly and unswervingly opposed to "lounge" for this proposal.

-- 

Paul

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

Re: [Tagging] Access=no for bus lanes

[osm.tagging]

Depending on the exact situation, it might be necessary to do something like:

 

access=no

bus=designated

foot=yes

 

or

 

vehicle=no

bus=designated

 

or

 

motor_vehicle=no

bus=designated

 

or any number of other variants.

 

It’s important to look closely at the transport mode tree.

 

From: Martin Koppenhoefer  
Sent: Friday, 8 June 2018 22:19
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Access=no for bus lanes

 

2018-06-08 10:44 GMT+02:00 François Lacombe mailto:fl.infosrese...@gmail.com> >:

 

it's written that dedicated bus lanes should get access=no and I find this too 
restrictive.

Such lanes can also be accessible by cabs, bikes or by foot.

It's sounds to be a mean to prevent cars only to take those lanes actually

 

 

for bus _lanes_ access=no will typically make sense, for bus _roads_ (i.e. only 
busses allowed on the road, but there might be other non-lanes included in the 
highway, like sidewalks) I have sometimes found this applied by error, because 
mappers forgot about the pedestrians.

 

Cheers,

Martin

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

Re: [Tagging] Lifeguards

[osm.tagging]

I agree that the 5 different values shown on the wiki describe distinctly 
different things and should all be retained.

 

From: Andrew Harvey  
Sent: Friday, 8 June 2018 20:41
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Lifeguards

 

I strongly disagree that they are the same, they are used to map different 
things, as noted on the wiki by the detailed descriptions 
https://wiki.openstreetmap.org/wiki/Key%3Aemergency#Lifeguards.

 

Low usage is likely just because there aren't that many of these in the real 
world and not many people have been mapping them.

 

So in my option we should continue to support the existing tags and keep 
mapping with them. I've been mapping the areas I know using the current defined 
schema.

 

"should be rendered" -> do you mean on the default OpenStreetMap style? Did you 
want to open a ticket on the stylesheet issue tracker 
https://github.com/gravitystorm/openstreetmap-carto/issues?utf8=%E2%9C%93 

 =is%3Aissue+is%3Aopen+lifeguard

 

+1 for having presets in the iD editor too.

 

On 8 June 2018 at 08:54, Graeme Fitzpatrick mailto:graemefi...@gmail.com> > wrote:

Hi

 

Just raised (or re-raised) the suggestion that lifeguard stations 
https://wiki.openstreetmap.org/wiki/Key%3Aemergency should be rendered 
https://github.com/openstreetmap/iD/issues/4918#event-1668877116, as it could 
be a potentially life-saving addition to the map.

 

Bryan had quite correctly pointed out that there are lot of similar, but all 
pretty rarely used (<1000) tags for essentially the same thing, so has 
suggested replacing them all with a simple emergency=lifeguard.

 

I can't see any major problem with doing that, but also keeping 
emergency=life_ring for those places (boardwalks, jetties etc) where an 
unaccompanied life ring is positioned.

 

What does everybody think?




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] Access=no for bus lanes

[osm.tagging]

To be a bit more specific about it:

 

All access tags follow the pattern:

 

transport mode = access value

 

All the different transport modes form a tree, as can bee seen here: 
https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation

 

“access” is the key used for the transport mode at the root of the tree.

 

To find out the effective access value for a specific transport mode (a leaf 
node in the tree of transport nodes) you start at that transport mode and check 
if there is a tag defining an access value, if not, you go to the parent in the 
transport mode tree and repeat the check, until you either find a tag (which is 
then the effective access value) or you checked for the “access” tag (the root 
of the tree) and didn’t find it.

 

So if you tag something as e.g.:

 

access=no

psv=designated

 

and you want to know the access value for e.g. a normal car, you check:

 

motorcar -> not found

motor_vehicle -> not found

vehicle -> not found

access=no

 

your effective access value for motorcar is no.

 

If instead you want to check for bus, you check:

 

bus -> not found

psv=designated

 

your effective access value for bus is designated.

 

If you would tag something (very wrongly) as 

 

access=designated

 

that would mean that any check that reaches the root of the tree would result 
in the access value of designated. Which makes the highway designated for every 
possible type of transport. And anything that's everything is nothing…

 

From: Lionel Giard  
Sent: Friday, 8 June 2018 19:30
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Access=no for bus lanes

 

Yes the idea behind access=* is a general tag - it indicate for every other 
transport types (except if another more specific tag is used) : so 
access=private just say that for every type of transport it is a private 
access, and if you add foot=yes, it became "private for everyone except people 
on foot that can walk freely). There is a hierarchy as shown on the wiki where 
a more specific access tag override restriction. 

 

2018-06-08 11:25 GMT+02:00 marc marc mailto:marc_marc_...@hotmail.com> >:

about "Bus-only roads"

Le 08. 06. 18 à 11:00, François Lacombe a écrit :
> highway=unclassified + access=designated + bus=yes + cycle=yes

access=no + bus=designated (+ cycle=yes and/or taxi in some country)

___
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 endless debate about "landcover" as a top-level tag

[osm.tagging]

I don’t think anyone has asked for the deprecation of landuse=forest, 
landuse=grass or natural=scrub or whatever.

 

Instead, to focus back down to the original issue, what is asked for is proper 
support for landcover in the default map style (in addition to whatever is 
already in there) equivalent to what the grandfathered existing tags have, to 
give people at least a real option to use semantically more appropriate tags.

 

The current situation forces mappers to keep using semantically incorrect tags. 
And even worse, these tags then directly conflict with the actual landuse tag 
they would want to use.

 

There are many places where I would have wanted to tag landuse=highway and 
landcover=grass (road verge, part of the official right of way, covered in 
grass), but if I want it to show up on the map, I’m currently forced to tag it 
landuse=grass.

 

From: Mateusz Konieczny  
Sent: Thursday, 7 June 2018 23:36
To: Tag discussion, strategy and related tools 
Cc: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] The endless debate about "landcover" as a top-level tag

 




7. Jun 2018 11:53 by selfishseaho...@gmail.com 
 :

On 7 June 2018 at 10:46, Christoph Hormann mailto:o...@imagico.de> > wrote:

There are tons of established tags in OSM where the key makes no sense
at all. Don't get me started on 'waterway' for example. But that is
how OSM works. Get over it, accept that people have made bad choices
of keys when choosing tags and concentrate on encouraging and helping
people to choose suitable keys when newly creating tags (in a
productive way of course, not just by rejecting any idea as bad).


And what's wrong with getting rid of these bad choices?

 

 Cost, effort and confusion is not worth positive effects.

 

Revolutions are really rarely worth costs.

 

Making tagging more consistent is not one of this cases.

 

Improvements are possible but not when it starts from "deprecate landuse=forest 
because it is not used to tag land use".

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

Re: [Tagging] RFC proposed water property key 'ephemeral '

[osm.tagging]

I would like to repeat (slightly extended) the contents of my previous post of 
how to interpret these tags:

 

The default state (no tags) is:

water (usually) always present

 

The seasonal, intermittent and ephemeral tags (allowing season or month 
timeframes in addition to yes) say:

 

The value yes and no define a new default state for the whole year (based on 
tag).

 

Other values define:

For these times, the explicit state is: the water (usually) always present, is 
intermittent, or is ephemeral

For all other times, the default state is: (usually) never present.

 

Always present overrides intermittent overrides ephemeral overrides not present.

Explicit state always overwrites default state.

 

These specific rules would result in exactly the interpretation you’ve given 
below.

 

intermittent=summer

In summer: explicit state = intermittent

Otherwise: default state = not present

 

intermittent=yes

default state = intermittent

 

seasonal=summer

in summer: explicit state= always present

otherwise: default state = not present

 

in combination:

in summer: explicit state= always present

otherwise: default state = intermittent

 

From: Warin <61sundow...@gmail.com> 
Sent: Wednesday, 30 May 2018 08:32
To: tagging@openstreetmap.org
Subject: Re: [Tagging] RFC proposed water property key 'ephemeral '

 

On 29/05/18 20:52, Paul Allen wrote:

On Tue, May 29, 2018 at 12:06 AM, Warin <61sundow...@gmail.com 
 > wrote:


Adding intermittent=yes to seasonal=yes adds no usefull information either. 

That depends how you interpret it.  Which would depend, to some extent, how it 
was documented. 

The seasonal=yes says it is non perennial all by it self. 

 

You're interpreting seasonal as being a specific case of intermittent: 
sometimes there is water

and sometimes there isn't; the water is present (for example) in summer but not 
other times of year.

 

Try this alternative interpretation which is meaningful: there is water there 
in summer but not

at other times of year however, even in summer, that flow is intermittent.


In that case I would tag

intermittent=summer 

The tag is much clear than 
intermittent=yes 
seasonal=summer
that could be taken (and how I would interpret it) to have a summer water 
presence with intermittent water at other times of the year. 




 

That, i think, would make such a combination meaningful.  Not necessarily how 
people

would interpret it without further explanation, which would be an argument 
against such

use, but meaningful.


The tags should 'make sense' without requiring further explanation ... as that 
generates these kind of problems. 

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

Re: [Tagging] roundtrip

[osm.tagging]

The real question, which as far as I can tell you haven’t answered, is: Does 
that same vehicle, after completing its route, start at the beginning of the 
same route again?

 

Based on your description, the route as mapped is A1->B->C->D->E->A2.

 

Can I get on at E, stay on the vehicle, and get off at B? (In which case I 
would expect that after finishing at A2, the vehicle goes to A1, and you can 
remain on board during that time. A2 may be (but doesn’t have to) an “exit 
only” and A1 and “entry only” stop).

 

If yes, then it is roundtrip=yes. And you shouldn’t just remove an existing tag 
that actually applies.

If no, then the roundtrip=yes is wrong and should be removed.

 

From: Jo  
Sent: Monday, 28 May 2018 15:13
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] roundtrip

 

An example of a (bus) route that goes out and comes back to the same location. 
It's not circle shaped at all, but that shouldn't matter for circular route.

 

I removed roundtrip=yes and replaced it with

 

circular_route=yes

closed_loop=no

 

If the last way wouldn't be in there, closed_loop would be yes. But the first 
and the last bus stops are not exactly opposite one another.

 

Jo

 

 

2018-05-27 6:22 GMT+02:00 Paul Johnson  >:

On Fri, May 25, 2018 at 5:41 AM, Peter Elderson  > wrote:

I wish you a happy trip on that bus, hope it has toilets and a tolerable coffee 
machine

 

Oh, you sweet, summer child.  Someone's never tried to take a suburban route in 
the US, even in a "transit oriented" American city... 


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

[osm.tagging]

From: Philip Barnes  
Sent: Sunday, 27 May 2018 03:53



I enjoy linear walks from a to b as you can cover more ground, or at least more 
diverse ground, 2.pi.r and all that.

Generally they involve public transport for one of two parts but its still a 
round trip.

Bus from A to B, walk from B to C, train from C to A. If using trains you can 
even take your bike.



 

YOU are making a roundtrip, but the routes involved are not itself roundtrip 
routes. You are using multiple different linear routes (and most likely only 
parts of them in case of bus or train as it’s unlikely you ride them all from 
first to last stop in the relation).

 

A route relation marked as roundtrip means that you can join it at any stop (or 
for type of routes that don’t have stops at any point along the route) and if 
you keep following it (the last way segment should connect to the first way 
segment, so that you can “keep following it” by continuing at the first way 
segment when you reach the last way segment) you will get back to the point 
where you joined the route.

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

Re: [Tagging] roundtrip

[osm.tagging]

If the route as a whole is a roundtrip, then exactly that point.

 

Let’s assume the route has stops:

 

A1

B

C

D

E

A2

 

A1 and A2 may be exactly the same point or close to each other, but that 
doesn’t matter, because for a roundtrip route, I would expect the vehicle to 
visits:

 

A1

B

C

D

E

A2

A1 (if different from A2)

B

C

D

E

A2

…

 

And so on, until end of service (of the vehicle)

 

If I get on at B, and it’s a roundtrip route, I would expect to be able to 
later get off at B again.

 

From: Peter Elderson  
Sent: Friday, 25 May 2018 20:40
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] roundtrip

 

Exactly that point or in the vicinity? No matter the payment, ticketing and 
boarding rules?

 

2018-05-25 12:32 GMT+02:00  >:

Or to express it even more general:

 

If you start at any stop, and remain on the vehicle, you will at some later 
point get back to the stop you started on.

 

From: osm.tagg...@thorsten.engler.id.au 
   > 
Sent: Friday, 25 May 2018 20:23
To: 'Tag discussion, strategy and related tools'  >
Subject: Re: [Tagging] roundtrip

 

I interpret roundtrip as “you can get from a stop to another stop that’s 
*before* it in the list of stops by simply remaining in the vehicle”.

 

You can have routes where the start and stop are the same location, but this is 
not true (as the vehicle always goes on to serve another route after arriving 
at the last stop).

 

From: Peter Elderson  > 
Sent: Friday, 25 May 2018 15:48
To: Tagging list OSM  >
Subject: [Tagging] roundtrip

 

What is the use of the key:roundtrip? 

Explanations just say  


  roundtrip=yes/no

(optional) Use roundtrip=no to indicate that a route goes from A to B. Use 
roundtrip=yes to indicate that the start and finish of the route are at the 
same location (circular route).

It seems rather pointless to tag an obvious a-b route with roundtrip=no, or an 
abvious roundtrip with roundtrip=yes. 

Why would you tag an a-b route as roundtrip=yes, or a closed route as 
roundtrip=no?


 

The only use case I can imagine is when a roundtrip has one ore more access 
ways which are included in the route relation. But even then, what is the 
purpose? 

 

Allowing apps to select only "official" roundtrips? Is that a valid reason for 
tagging?

 

-- 

Peter Elderson


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





 

-- 

Vr gr Peter Elderson

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

Re: [Tagging] roundtrip

[osm.tagging]

Or to express it even more general:

 

If you start at any stop, and remain on the vehicle, you will at some later 
point get back to the stop you started on.

 

From: osm.tagg...@thorsten.engler.id.au  
Sent: Friday, 25 May 2018 20:23
To: 'Tag discussion, strategy and related tools' 
Subject: Re: [Tagging] roundtrip

 

I interpret roundtrip as “you can get from a stop to another stop that’s 
*before* it in the list of stops by simply remaining in the vehicle”.

 

You can have routes where the start and stop are the same location, but this is 
not true (as the vehicle always goes on to serve another route after arriving 
at the last stop).

 

From: Peter Elderson  > 
Sent: Friday, 25 May 2018 15:48
To: Tagging list OSM  >
Subject: [Tagging] roundtrip

 

What is the use of the key:roundtrip? 

Explanations just say  


  roundtrip=yes/no

(optional) Use roundtrip=no to indicate that a route goes from A to B. Use 
roundtrip=yes to indicate that the start and finish of the route are at the 
same location (circular route).

It seems rather pointless to tag an obvious a-b route with roundtrip=no, or an 
abvious roundtrip with roundtrip=yes. 

Why would you tag an a-b route as roundtrip=yes, or a closed route as 
roundtrip=no?


 

The only use case I can imagine is when a roundtrip has one ore more access 
ways which are included in the route relation. But even then, what is the 
purpose? 

 

Allowing apps to select only "official" roundtrips? Is that a valid reason for 
tagging?

 

-- 

Peter Elderson

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

Re: [Tagging] roundtrip

[osm.tagging]

I interpret roundtrip as “you can get from a stop to another stop that’s 
*before* it in the list of stops by simply remaining in the vehicle”.

 

You can have routes where the start and stop are the same location, but this is 
not true (as the vehicle always goes on to serve another route after arriving 
at the last stop).

 

From: Peter Elderson  
Sent: Friday, 25 May 2018 15:48
To: Tagging list OSM 
Subject: [Tagging] roundtrip

 

What is the use of the key:roundtrip? 

Explanations just say  


  roundtrip=yes/no

(optional) Use roundtrip=no to indicate that a route goes from A to B. Use 
roundtrip=yes to indicate that the start and finish of the route are at the 
same location (circular route).

It seems rather pointless to tag an obvious a-b route with roundtrip=no, or an 
abvious roundtrip with roundtrip=yes. 

Why would you tag an a-b route as roundtrip=yes, or a closed route as 
roundtrip=no?


 

The only use case I can imagine is when a roundtrip has one ore more access 
ways which are included in the route relation. But even then, what is the 
purpose? 

 

Allowing apps to select only "official" roundtrips? Is that a valid reason for 
tagging?

 

-- 

Peter Elderson

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

Re: [Tagging] RFC proposed water property key 'ephemeral '

[osm.tagging]

That is actually pretty strongly dependant on El Nino:

http://www.bom.gov.au/climate/updates/articles/a008-el-nino-and-australia.shtml

The shift in rainfall away from the western Pacific, associated with El Niño, 
means that Australian rainfall is usually reduced through winter–spring, 
particularly across the eastern and northern parts of the continent. 

Nine of the ten driest winter–spring periods on record for eastern Australia 
occurred during El Niño years. 

vs. La Nina:

http://www.bom.gov.au/climate/updates/articles/a020.shtml

The increased rainfall and cloudiness in the western Pacific associated with La 
Niña usually means above-average winter–spring rainfall for Australia, 
particularly across the east and north. 

The six wettest winter–spring periods on record for eastern Australia occurred 
during La Niña years.

 

From: Graeme Fitzpatrick  
Sent: Friday, 25 May 2018 14:12
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] RFC proposed water property key 'ephemeral '

 

 




Thanks

 

Graeme

 

On 25 May 2018 at 13:34, Warin <61sundow...@gmail.com 
 > wrote:

  
I'd not put a season on any of them .. too variable for me to determine a 
season. 

 

& that's the killer.

 

In Queensland, summer is supposed to be wet & winter dry, but something like 6 
years out of the last 12, we've had flood rains over winter?

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

Re: [Tagging] RFC proposed water property key 'ephemeral '

[osm.tagging]

The way I interpret it:

 

The default state (no tags) is:

 

water always flows

 

The seasonal, intermittent and ephemeral tags says

 

For these times, the explicit state is: the water always flows, is 
intermittent, or is ephemeral

For all other times, the default state is: the water never flows

 

Explicit state always overwrites default state.

 

The only thing left to specify now is the priority of the 3 keys. If two or 
more of them overlap in their explicit state for the same timeframe, which one 
has priority, or is it simply considered a tagging error?

 

From: Mateusz Konieczny  
Sent: Thursday, 24 May 2018 17:08
To: Tag discussion, strategy and related tools 
Cc: 'Tag discussion, strategy and related tools' 
Subject: Re: [Tagging] RFC proposed water property key 'ephemeral '

 




24. May 2018 06:39 by osm.tagg...@thorsten.engler.id.au 
 :

If I’ve understood it correctly, I would tag that as:

 

seasonal=winter,spring,autumn

ephemeral=summer

 

Yes, it would work. 

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

Re: [Tagging] RFC proposed water property key 'ephemeral '

[osm.tagging]

If I’ve understood it correctly, I would tag that as:

 

seasonal=winter,spring,autumn

ephemeral=summer

 

From: Mateusz Konieczny  
Sent: Thursday, 24 May 2018 16:28
To: Tag discussion, strategy and related tools 
Cc: tagging@openstreetmap.org
Subject: Re: [Tagging] RFC proposed water property key 'ephemeral '

 




22. May 2018 22:53 by 61sundow...@gmail.com  :

Is that clear? 

 

Do how easiest that is

- flowing during winter, spring, autumn

- generally not flowing during summer but with possible ephemeral flows

 

should be tagged?

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

Re: [Tagging] Sample tagging for highways with no lane markings

[osm.tagging]

From: Javier Sánchez Portero  
Sent: Wednesday, 23 May 2018 17:27
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Sample tagging for highways with no lane markings

 

Anyway, for your example of the LR-333 road, most of the time it isn't enough 
wide for two cars to pass comfortably (see here 
https://goo.gl/maps/6PC2Wfkfw7A2 like the van has to put the wheel in the 
border line and probably stop). In this case, lanes=1, oneway=no is the best 
tagging. 

 

I agree that for this particular road lanes=1 is appropriate. Some people may 
tag it as lanes=1.5. But I find non-integer values for lanes quite problematic.

 

You could use lanes:both_ways=1 (in addition to lanes=1) to be explicit about 
it, but that is sort of implied. (In the absence of oneway=yes or an explicit 
lanes:forward or lanes:backward, if the lanes count is odd, it’s assumed the 
middle lane is both_ways while the remaining lanes are evenly split between 
forward and backward).

 

 

Would you tag the same in GC-210 road?: 
https://www.mapillary.com/map/im/v_G65XwwVnjf0u3i0RxRqA

What I suggest is that the tagging division=no is correct for examples like 
this.

 

 

This one looks like the prototypical:

 

lanes=2

divider=no

 

I don’t think anyone could argue this is a lanes:both_ways=1 (which would be 
implied by lanes=1 oneway=no, even if not explicitly tagged).

 

Cheers,

Thorsten

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

Re: [Tagging] opening_hours:sign=no - RFC

[osm.tagging]

> -Original Message-
> From: Warin <61sundow...@gmail.com>
> Sent: Wednesday, 23 May 2018 09:31

> >> Could not this information be included in the note tag?
> > note is free text for mapper
> > unsigned is also used by tools like http://qa.poole.ch/
> 
> I don't think any data consumer will use this information, so it is
> for the mapper .. so that fits in the note key. If may not be easy
> to automate it, but is that required?

A tool could make recommendations about what to survey, which might point out 
business that don't have an opening_hours tag.

If there is an easily automatable tag indicating that the opening_hours are not 
signed at the premises, the tool could either not recommend that location for a 
survey or specifically list that opening hours might have to be looked up 
online or inquired about in some other way.

So I'm in agreement that it's worthwhile to tag this information in a fixed 
way, not using the note tag for it.

Instead of making that specific about opening_hours, I would suggest we 
establish one of the following pattern:

:sign=yes/no/disused
(disused = sign is present but unreadable or known to be out of date and not 
matching the real situation)

or:

unsigned:=yes/no
(disused would sound wrong in this context, though I would like to be able to 
map that information in some way)

There are other tags (like source) that already follow the 2nd pattern. On the 
other hand, the first pattern keeps the information that should stay together 
better in one place when looking at a sorted list of tags.

I might be worthwhile to also consider how this would interact with 
last_checked (not that commonly used, but probably useful in combination with 
this tag):

:sign:last_checked=
last_checked::sign=

unsigned::last_checked=
last_checked:unsigned:=

Personally I would prefer the first over the last choice, and the middle two 
just look wrong.

Cheers,
Thorsten



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

Re: [Tagging] Sample tagging for highways with no lane markings

[osm.tagging]

 

 

From: yo paseopor  
Sent: Wednesday, 23 May 2018 04:11
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Sample tagging for highways with no lane markings

 

oneway=no

lanes=1

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

 

 

I would consider that wrong.

 

lanes=1

oneway=no 

 

is a road that is so narrow that opposing traffic can only pass by slowing down 
and making use of shoulder/verge to pass each other. Or maybe even has the need 
to look for a https://wiki.openstreetmap.org/wiki/Tag:highway=passing_place to 
be able to pass each other (like the example image shown on that page).

 

What your image above shows is pretty clearly a lanes=2, which you can see very 
well by just following the street a few meters:

 

https://www.mapillary.com/map/im/6QXgHLK26FTMlmovwuaxfg

 

as you can see, there are clear road markings establishing two lanes.

 

 

Here is an example of the roads I mean that should be tagged with

 

lanes=2

divider=no

(oneway=no is normally implicit, so no need to tag it when there is no reason 
to wrongly assume a road should be oneway)

 

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

 

You can see that the roads generally have no marked lanes, but at the 
T-intersection there are markings that make it clear the road is intended to be 
a two lane road.

 

Cheers,

Thorsten

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

Re: [Tagging] Sample tagging for highways with no lane markings

[osm.tagging]

Personally, I tend to tag roads that are wide enough for 2 lanes (two cars can 
pass each other without noticeably slowing down) and which are clearly meant to 
be two lane (one lane each direction) roads with:

lanes=2
divider=no

Yes, I know that is in violation of the strict reading of the wiki, but I feel 
it makes sense, and as far as I can determine, tagging roads that are meant to 
have two lanes with lanes=2 even in the absence of such road markings seems to 
be pretty widespread practice. (The use of the divider tag isn't very 
widespread, but again, I feel it makes sense in this context.)

Cheers,
Thorsten

> -Original Message-
> From: Tod Fitch 
> Sent: Wednesday, 23 May 2018 01:18
> To: Tag discussion, strategy and related tools
> 
> Subject: [Tagging] Sample tagging for highways with no lane
> markings
> 
> In reviewing the wiki in preparation to fixing some of my older
> mapping, it seems there is an inconsistency in how to tag a road
> that is wide enough to two lanes of traffic but is lacking lane
> striping.
> 
> In the lanes description [1] it says "the lanes=* key should be
> used to specify the total number of marked lanes of a road." But in
> the out of town highway tagging sample page [2] with a photo
> described as "smaller road, maybe tertiary with appropriate
> administrative status" it shows a lane count on a road with no
> markings.
> 
> Am I correct in believing that the example photo should have its
> tagging changed, dropping the lanes=2 and adding a width tag (if
> the width is known or can be reasonably estimated)?
> 
> My current interest is in fixing the tagging for residential roads
> that are wide enough for bi-directional traffic with legal parallel
> parking but have no markings on the pavement. I don't see a exact
> match to that in either the urban [3] or rural highway [2] tagging
> example pages.
> 
> To use the street I live on as an example, am I correct that a
> residential road with bidirectional traffic and parallel parking
> with no markings should be tagged as:
> 
> highway=residential
> surface=asphalt
> parking:lane:both=parallel
> width=40’0"
> maxspeed=25 mph
> 
> If, and only if, a center strip is added then lanes=2 should be
> added. (I actually measured the width in this case but for hope to
> be able to use the measurement tool on aerial imagery in JOSM for
> most cases).
> 
> Is my current understanding correct? If so, I will update the wiki
> pages for both the urban and rural highway tagging examples to
> reflect that and will take some photos of the roads in my area to
> make additional examples.
> 
> 
> [1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
> [2]
> https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/out_of_
> town
> [3]
> https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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