date:20180618

On 19 June 2018 at 08:34, Tod Fitch  wrote:

>
> Might want to check if there is some sort of tag indicating seasonal
> before removing from the map.
>
> On the beach near me many of the lifeguard structures are built on what
> amounts to a sledge and are dragged to storage at the end of the summer
> season. In summer they are placed in the same locations each year, if
> nothing else so that the communications and power connections don’t need to
> be relaid. But even if they don’t need power and communications, the
> visitor use patterns remain fairly constant so the location of lifeguard
> stations/towers/structures remains fairly constant.
>
> In any even, depending on the season the aerial imagery was taken you may
> see only an empty stretch of beach. Or you may see what looks like a small
> building from above.
>

Thanks Tod - sorry, I missed your post earlier.

I haven't seen any seasonal tags on any of the stations I've looked at so
far.

A portable tower that get's put away over Winter then goes back in the same
spot next year is a new one on me, but could well explain some of the shots
that appear to show a structure, which then isn't there in other shots.
What area are you in?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

On 19 June 2018 at 16:30, Marc Gemis  wrote:

> > I'll take a stab at ambulance / paramedic / emergency rescue or
> something along those lines, but I think we're agreed it's not a
> "lifeguard"?
>
>
> I agree, but perhaps we should involve the Russian community to
> improve the wiki, as part of the mistagging is happening there.
>

Yep, good idea.

How? :-)

Just a post on the RU list? Does it need to be in Russian, because I
certainly can't speak (or write) it!

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

2018-06-18 Thread Marc Gemis

> I'll take a stab at ambulance / paramedic / emergency rescue or something 
> along those lines, but I think we're agreed it's not a "lifeguard"?


I agree, but perhaps we should involve the Russian community to
improve the wiki, as part of the mistagging is happening there.

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

Re: [Tagging] emergency=lifeguard

I've had a go at starting a wiki page for info & discussion:
https://wiki.openstreetmap.org/wiki/Emergency%3Dlifeguard

This is my first attempt at a wiki, so please be kind! :-)

All input welcome from those of you who actually know how to do it!

Thanks

Graeme

On 19 June 2018 at 14:58,  wrote:

> 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 <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] emergency=lifeguard
>
>
>
>
>
> On 19 June 2018 at 08:45, Graeme Fitzpatrick 
> 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
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

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

On 19 June 2018 at 08:45, Graeme Fitzpatrick  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] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

> On Jun 18, 2018, at 8:16 PM, Paul Allen  wrote:
> 
> On Tue, Jun 19, 2018 at 12:36 AM, Eugene Alvin Villar  > wrote:
> 
> Just to comment on the Microsoft side angle here….

Please try to stay on topic. 
We’re not going to change our approach to GitHub anytime soon.
If you don’t want to discuss tagging, please follow the link at the bottom of 
this message to unsubscribe.

Thanks, Bryan

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

Re: [Tagging] Street exits

2018-06-18 Thread Paul Johnson

I wouldn't call it unmarked; uncontrolled would be more like it.  The
markings are just a permanent fixture of the surface in this case, kinda
like how some American towns use brickwork instead of paint for crosswalks

.

On Fri, Jun 15, 2018 at 2:18 AM, marc marc 
wrote:

> it look like a pedistrian crossing and a traffic calming
> highway=crossing + crossing=unmarked
> traffic_calming=table
>
> if the standard maxspeed for a traffic_calming is not the same
> as for a "street exit", the easy think todo is to create a new
> traffic_calming value like traffic_calming=street_exit
>
>
> Le 15. 06. 18 à 09:10, Peter Elderson a écrit :
> > Speed limit is only implied for the part crossing the sidewalk. The
> > street behind it can have different speed limits, usually it is part of
> > a "30 Kmph zone", but that is not implied or necessary.
> >
> > The level of detail: sidewalks and kerbs are not usually mapped. It's
> > not realistic to start doing that just for these "exit constructions".
> > In fact, the exit may have dropped kerbs, but it might be a fat line or
> > double line, a line of different paving, a traffic bump or just that the
> > sidewalk paving stops.
> > Similar considerations for separate tagging of other details of paving,
> > elevation, lining. These are not fixed. The key element is that you
> > cross a sidewalk (and/or cycling lane).
> >
> > Speed signs, give-way signs, shark teeth, stop-lines, bump warnings may
> > or may not be present. The idea is that all or most signs can be
> > removed: a. You are coming form an exit so slow down and give way! b.
> > It's coming from the right but it's an exit so move on!
> >
> > We're looking for a simple way to indicate what's there without tagging
> > all the details and implications separately.
> >
> > 2018-06-15 8:42 GMT+02:00  > >:
> >
> > *From:*Peter Elderson  > >
> > *Sent:* Friday, 15 June 2018 16:29
> > *To:* Tag discussion, strategy and related tools
> > mailto:tagging@openstreetmap.org>>
> > *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
> > 
> >
> >
> >
> >
> > --
> > Vr gr Peter Elderson
> >
> >
> > ___
> > 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] Street exits

2018-06-18 Thread Paul Johnson

Looks like a pretty typical Dutch pedestrian crossing?  They're pretty good
about organizing things so as to be unambiguously obvious when you do and
don't have the right of way in regards to nonmotorized traffic.

On Fri, Jun 15, 2018 at 1:28 AM, Peter Elderson  wrote:

> 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).
>
> 2018-06-15 8:16 GMT+02:00 Martin Koppenhoefer :
>
>>
>>
>> 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
>>
>
>
>
> --
> Vr gr Peter Elderson
>
> ___
> 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] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

On Tue, Jun 19, 2018 at 12:36 AM, Eugene Alvin Villar 
wrote:

Just to comment on the Microsoft side angle here. Inasmuch as history has
> been very unkind to Microsoft with respect to their treatment of open
> source communities and technologies in the past (Linux, Mozilla, etc.),
>

I wouldn't say history has been unkind.  Accurate is what I'd say.
Microsoft has been unkind to competitors, open or
closed source, in the past, is what I'd say.

> there is reason to believe that they will do good with their acquisition
> of GitHub moving forward and will not screw it up like the way Oracle
> screwed up the Sun Microsystems acquisition.
>

Erm, Skype?  I'll grant you that LinkedIn is apparently not screwed up
(yet).  Windows update 1803?  Not that any of the
large closed-source companies are much better, and some of the big
open-source companies aren't quite as respected
as they once were.

And here in OSM, the community has greatly benefited from using Microsoft's
> Bing satellite imagery since 2010, and Microsoft has even recently granted
> use of their Streetside imagery for use in OSM as well (no doubt to
> continue countering Google).
>

There is that.  And I think you're right about the motivation.  And the
same applied to Google getting into mobile
phones.  They all do what they think is in their shareholders' best
interests, and that is all you can count on.

And Microsoft's Bing has been a Gold Corporate Member of the OSM Foundation
> since 2017. So this doubt heaped upon Microsoft is hopefully no longer
> without basis.
>

Ummm, I think you meant "now" not "no longer."  We can all hope.  A maxim
springs to mind: "Hope for the best, plan
for the worst."

(But yeah, keep discussions on mailing lists as much as possible.)
>

A good idea even if Microsoft turn out to be excellent custodians of github.

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

Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

2018-06-18 Thread Eugene Alvin Villar

On Tue, Jun 19, 2018 at 6:20 AM, Paul Allen  wrote:

> On Mon, Jun 18, 2018 at 10:27 PM, Frederik Ramm 
> wrote:
>
> Others have qualms about signing up to an American social network platform
>> just
>>
> to participate in OSM discussions (remember - if the product is free, you
>> are the
>
> product).
>
>
> From what I have read, others in the IT community have qualms about
> keeping their
> repos on github now it's been bought by Microsoft.  See, for example,
> https://www.theregister.co.uk/2018/06/04/microsoft_buys_github/ and the
> associated
> comments (almost all negative, some so vituperative they would make Linus
> Torvalds blush).
>
> It remains to be seen how many of those are willing to walk the walk as
> well as talk
> the talk.  However, I suspect a significant number have at least
> duplicated their
> repos elsewhere.  Some claimed they were going to copy their repos
> elsewhere
> and poison the copies on github to leave a nice surprise should Microsoft
> try
> to harvest their work.
>
> I'm not saying Microsoft will screw up github (although history shows
> that's what
> usually happens to their acquisitions).  I'm not saying Microsoft will
> steal people's
> work (they could do that without buying github), although I remember
> Stacker's
> Doublespace product and what happened to it.  I'm not saying Microsoft will
> embrace, extend and extinguish github, but they have a history of doing
> that.  I'm
> just pointing out that people have other reasons for avoiding github these
> days,
> and its alternatives don't have such sophisticated comments/discussion
> capability,
> so maybe that's another reason to move as much discussion as possible to
> the
> mailing list.
>

Just to comment on the Microsoft side angle here. Inasmuch as history has
been very unkind to Microsoft with respect to their treatment of open
source communities and technologies in the past (Linux, Mozilla, etc.),
there is reason to believe that they will do good with their acquisition of
GitHub moving forward and will not screw it up like the way Oracle screwed
up the Sun Microsystems acquisition. But don't take it from me, take it
from the Executive Director of the Linux Foundation himself:
https://www.linuxfoundation.org/blog/microsoft-buys-github-the-linux-foundations-reaction/

And here in OSM, the community has greatly benefited from using Microsoft's
Bing satellite imagery since 2010, and Microsoft has even recently granted
use of their Streetside imagery for use in OSM as well (no doubt to
continue countering Google). And Microsoft's Bing has been a Gold Corporate
Member of the OSM Foundation since 2017. So this doubt heaped upon
Microsoft is hopefully no longer without basis.

(But yeah, keep discussions on mailing lists as much as possible.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] A new Tag for "helicopter services"?

Thanks

Graeme

On 19 June 2018 at 00:14, Clifford Snow  wrote:

> office=air_charter should fit. The ones around here offer both fixed wing
> and helicopter services.
>
> With office=air_charter you could also add
> air_charter=helicopter
>
> Clifford
>
> On Mon, Jun 18, 2018 at 6:06 AM gorgonz  wrote:
>
>> I'm looking for a tag, that describes an office, that offers helicopter
>> services. Jobs are emergencies, round trips and aerial views for example.
>> What is to be noted: this describes the place of the office and not the
>> according landing field.
>>
> Was just looking at TagInfo & it shows aeroway=office, which has been used
precisely twice! So:

aeroway=office

office=air_charter; or maybe office=operations?

air_charter / operations=helicopter

Name; website; telephone etc

How's that sound?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

On 18 June 2018 at 21:15, Martin Koppenhoefer 
wrote:

>
>  "lifeguard=place" is currently not used at all, and I do not believe it
> is a good tag. "place" is so generic, it doesn't allow for any deduction of
> meaning more than "thing" or "feature", and it is used for toponyms as a
> key in OSM.
>

There's currently 41 (or maybe 76?) of them in use

> On beaches I would distinguish lifeguards that operate out of a structure
> like a tower, a cabin, office or a similar building, from those who only
> sit in a chair below an umbrella or a temporary roof, or maybe not even.
>

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

> Shall it be a feature and a property (feature would indicate the position,
> as property you could add something like lifeguard=yes to a beach or
> swimming pool (likely implied).
>

That's a good idea!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

On 18 June 2018 at 21:38,  wrote:
>
>
>
> 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?
>
> A major problem I have with that "beach" is that if someone has designated
all that stretch as "Surfers Paradise beach", then they have included ~9
separate named beaches under that one name :-( Looks like I've got some
re-mapping to do!

As part of our discussion here, that stretch includes 8 bases & 22 towers
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

> On Jun 18, 2018, at 5:27 PM, Frederik Ramm  wrote:
> 
> Jokes aside, there are many serious reasons why good old-fashioned
> mailing lists should be the mainstay of important communication in OSM.

I’m not suggesting to replace the mailing list.  As you can probably tell form 
the past week, I’ve significantly stepped up my participation.  I will happily 
take the lead on tagging discussions if that’s what it takes to prevent another 
`transit:lanes`.

> So yes, +1 to keeping the discussion on email - documenting results on
> Github is ok, but trying to move the decision-making there would be
> problematic.

Yep, also +1 to keeping everything on the tagging list.  The Github repo is to 
track what actual work is being done and by whom.  (Please tag yourself if you 
see something you want to help with.)

Right now the only GitHub issue is to fix the `emergency=lifeguard` situation, 
which we’ve already reached consensus on.

Thanks, Bryan

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

Re: [Tagging] emergency=lifeguard

2018-06-18 Thread Tod Fitch

> On Jun 18, 2018, at 3:18 PM, Graeme Fitzpatrick  wrote:
> 
> No, this will have to be a manual check, but there's only ~900 worldwide so 
> not impossible. Some should  be pretty straight forward - if a building 
> beside the beach is marked as a base, then that's fine, but an apparently 
> empty stretch of beach, or water!, being marked as a base or tower isn't. I 
> guess  message to the original mapper, in a lot of case years ago, asking or 
> confirmation that there's actually something there will be the best way to 
> go?   

Might want to check if there is some sort of tag indicating seasonal before 
removing from the map.

On the beach near me many of the lifeguard structures are built on what amounts 
to a sledge and are dragged to storage at the end of the summer season. In 
summer they are placed in the same locations each year, if nothing else so that 
the communications and power connections don’t need to be relaid. But even if 
they don’t need power and communications, the visitor use patterns remain 
fairly constant so the location of lifeguard stations/towers/structures remains 
fairly constant.

In any even, depending on the season the aerial imagery was taken you may see 
only an empty stretch of beach. Or you may see what looks like a small building 
from above.

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

Re: [Tagging] emergency=lifeguard

On 18 June 2018 at 21:17, Andrew Harvey  wrote:

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

"Patrolled"? Or is that possibly suggesting police patrols?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

On Mon, Jun 18, 2018 at 10:27 PM, Frederik Ramm  wrote:

Others have qualms about signing up to an American social network platform
> just
>
to participate in OSM discussions (remember - if the product is free, you
> are the

product).

>From what I have read, others in the IT community have qualms about keeping
their
repos on github now it's been bought by Microsoft.  See, for example,
https://www.theregister.co.uk/2018/06/04/microsoft_buys_github/ and the
associated
comments (almost all negative, some so vituperative they would make Linus
Torvalds blush).

It remains to be seen how many of those are willing to walk the walk as
well as talk
the talk.  However, I suspect a significant number have at least duplicated
their
repos elsewhere.  Some claimed they were going to copy their repos elsewhere
and poison the copies on github to leave a nice surprise should Microsoft
try
to harvest their work.

I'm not saying Microsoft will screw up github (although history shows
that's what
usually happens to their acquisitions).  I'm not saying Microsoft will
steal people's
work (they could do that without buying github), although I remember
Stacker's
Doublespace product and what happened to it.  I'm not saying Microsoft will
embrace, extend and extinguish github, but they have a history of doing
that.  I'm
just pointing out that people have other reasons for avoiding github these
days,
and its alternatives don't have such sophisticated comments/discussion
capability,
so maybe that's another reason to move as much discussion as possible to the
mailing list.

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

Re: [Tagging] emergency=lifeguard

On 18 June 2018 at 16:24,  wrote:

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

No, this will have to be a manual check, but there's only ~900 worldwide so
not impossible. Some should  be pretty straight forward - if a building
beside the beach is marked as a base, then that's fine, but an apparently
empty stretch of beach, or water!, being marked as a base or tower isn't. I
guess  message to the original mapper, in a lot of case years ago, asking
or confirmation that there's actually something there will be the best way
to go?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

Wow, thanks everybody for your thoughts.

Going through a few comments

On 18 June 2018 at 17:58, Marc Gemis  wrote:

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

Found 3 - 4 of these in a similar area, one of which is
https://www.openstreetmap.org/way/354731850#map=18/56.73835/61.11087

Part of the description gives:  Медицина катастроф - трассовый пунк Малые
Брусяны which Mr Google translates to "Medicine of catastrophes - route
point Small Brusians", which I've got to say doesn't shed an awful lot of
light on the subject!

I'll take a stab at ambulance / paramedic / emergency rescue or something
along those lines, but I think we're agreed it's not a "lifeguard"?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

2018-06-18 Thread Frederik Ramm

Hi,

On 06/18/2018 03:37 PM, Bryan Housel wrote:
> I think we should continue to make sure that every change
> is raised on the tagging mailing list for WWIC [1] reasons.

Using mailing lists provides no immunity against "WWIC", but it is
certainly safer than Github for the time being (who knows, there might
be a time when people sign up to Github before they do email, and their
friends open an issue when they want to meet up for drinks but we're not
quite there yet).

Jokes aside, there are many serious reasons why good old-fashioned
mailing lists should be the mainstay of important communication in OSM.
For me, the greatest plus is that mailing lists are not controlled by
(and at the whim of) business interests. Others have qualms about
signing up to an American social network platform just to participate in
OSM discussions (remember - if the product is free, you are the
product). Others again might prefer the accessibility offered by email,
where it is relatively straightforward to have a 100% voice based
interface, and so on.

So yes, +1 to keeping the discussion on email - documenting results on
Github is ok, but trying to move the decision-making there would be
problematic.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] drop covered=booth?

On Mon, Jun 18, 2018 at 9:00 PM, Bryan Housel  wrote:

> from https://github.com/openstreetmap/iD/issues/5088
>
> *Proposal:*
> I’d like to drop `covered=booth` as a suggested tag, as it’s superfluous.
> If the telephone feature has `booth=yes` or `booth=K6` you know it’s a
> booth.  Then we’re not repurposing the `covered=*` for a thing that it
> doesn’t normally do in other situations and isn’t documented on the main
> `covered` page.
>

The only possible problem with this is that many public phones in the US
have an acoustic hood which shields
the phone from rain and may provide a degree of rain protection to the
user.  In which case the acoustic hood
provides cover, just no as much as a booth.

Then again, I've never seen an outdoor public phone that isn't in a booth
also lack an acoustic hood.  So should
mappers and consumers assume a hood is present unless booth is specified?
Except I can conceive of a phone
in a building passage having neither a booth nor a hood (seems unlikely,
but possible).

Otherwise, I have no problems with the change.  By all means drop an
inappropriate, repurposed tag for something
better.  Once we're sure we're not going to hit further problems because we
didn't think of all use cases.

If we do go down this route, then I think an automated edit is justified
which drops covered=booth where booth=* is
specified and replaces covered=booth with booth=yes where booth isn't
specified.

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

Re: [Tagging] drop covered=booth?

2018-06-18 Thread marc marc

Le 18. 06. 18 à 22:00, Bryan Housel a écrit :
> Someone has asked me to add a `covered=booth` field to the telephone preset.

imho he need at least to document it

> Generally the tag `covered=*` (usually ‘yes’)  is used to indicate that 
> a highway goes under a building part, so that linters and validation 
> tools can not flag the crossing as an error..

but not only.
the wiki said "covered=* is used to denote that an object represented
by a node, way or area is covered.

you can use it for a lot of objets like a bicyble parking, entrance.
https://taginfo.openstreetmap.org/keys/?key=covered#combinations
159k highway - 42k highway=bus_stop = 117k
less than 1/3 of all combinations are related to a highway

I myself use covered=yes for a lot of not-highway objects

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

[Tagging] drop covered=booth?

from https://github.com/openstreetmap/iD/issues/5088 


`covered`, traditionally:
Someone has asked me to add a `covered=booth` field to the telephone preset.
I’m pushing back on the request slightly because `covered=*` already has a 
mostly-understood meaning defined here 
https://wiki.openstreetmap.org/wiki/Key:covered 


Generally the tag `covered=*` (usually ‘yes’)  is used to indicate that a 
highway goes under a building part, so that linters and validation tools can 
not flag the crossing as an error..

`covered` for telephones?
The `amenity=telephone` page suggests using `covered=booth` for a phone in a 
booth.
It also suggests adding a `booth=*` tag (again usually ‘yes’, but may indicate 
what type of iconic UK phone booth).
https://wiki.openstreetmap.org/wiki/Tag:amenity=telephone 



Proposal:
I’d like to drop `covered=booth` as a suggested tag, as it’s superfluous.  If 
the telephone feature has `booth=yes` or `booth=K6` you know it’s a booth.  
Then we’re not repurposing the `covered=*` for a thing that it doesn’t normally 
do in other situations and isn’t documented on the main `covered` page.

Thoughts?

Thanks, Bryan

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

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

2018-06-18 Thread Tobias Knerr

On 18.06.2018 17:22, Kevin Kenny wrote:
> Would it be feasible to say that building=yes is a default (except,
> perhaps, for rock_shelter, sun_shelter) and that mappers are expected to
> place an expected building=no on the exceptions? 

Using building=no is a bad idea, as any object tagged building=* is
defined as representing a building – no matter the value. In particular,
data consumers should be able to fall back onto building=yes for all
unknown building values.

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

Re: [Tagging] emergency=lifeguard

2018-06-18 Thread Tobias Wrede


Am 11.06.2018 um 23:09 schrieb Graeme Fitzpatrick:
Had a look at https://de.wikipedia.org/wiki/Wasserrettungsstation & 
it's a purely German organisation, which would appear to be life 
guards, although with possibly a bit of Coast Guard / Marine Rescue 
included?


Actually, this would be the general German term for a lifeguard base. 
They are manned/run by different organisations (DLRG, ASB, Wasserwacht). 
To my knowledge they only do near shore rescuing for swimmers, surfers, 
light boats etc. Off-shore rescuing more intended for rescuing ships' 
crews is done by German Coast Guard (Küstenwache, state run) or more 
often by another non-governmental organization called Deutsche 
Gesellschaft zur Rettung Schiffbrüchiger.


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

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

2018-06-18 Thread Kevin Kenny

On Mon, Jun 18, 2018 at 11:33 AM marc marc  wrote:
>
> Le 18. 06. 18 à 17:22, Kevin Kenny a écrit :
> > Would it be feasible to say that building=yes is a default (except,
> > perhaps, for rock_shelter, sun_shelter) and that mappers are expected to
> > place an expected building=no on the exceptions?
>
> please never do that.
> you never known if the mapper have checked the implied value or not.
> and therefore the auto-added tag lost all meaning.

I'm not talking about auto-adding a tag in the editors, but rather
documenting an assumption for data consumers.

We have a number of assumptions already that are
broadly accepted. The routers presume access=private for driveways.
The renderer presumes area=no for closed highway=* ways. The editors
don't auto-add these tags, the renderers and routers simply act
based on the default assumption and the specifically tagged
exceptions.

But I'm not wedded to this idea; if the consensus is that this particular
assumption is too fragile, so be it.

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

Re: [Tagging] Street exits

2018-06-18 Thread Tobias Wrede

Hi,

Am 15.06.2018 um 18:14 schrieb osm.tagg...@thorsten.engler.id.au:

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.

Actually, we have the same thing in Germany. It's not only for living
streets as Martin already pointed out but also for any other streets
exiting over a lowered curb. Traffic exiting from such street has to
behave the same way as when exiting from a driveway, i. e. drive with
extreme caution and wait for any other traffic including pedestrians to
pass (§10 StVO). I have no clue, though, if there is any established
tagging for that here.

Tobias

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] `amenity=shelter` implies `building=yes`?

On Mon, Jun 18, 2018 at 4:22 PM, Kevin Kenny 
wrote:

>
>>
> Would it be feasible to say that building=yes is a default (except,
> perhaps, for rock_shelter, sun_shelter) and that mappers are expected to
> place an expected building=no on the exceptions?
>

Tags are not hierarchical, let alone cladistic.  And English usage is
rather fluid.  This leads to anomalies.

Any enclosed space built by man that a person can occupy is, in one sense,
a building.  Anything built by man is, by definition, man made.  And, since
man is a part of nature, anything built by man is also natural (if a beaver
dam is natural artefact then so is the Hoover Dam).  Thankfully, OSM tags
aren't cladistic, or we'd have natural=skyscraper.

That said, most people would classify houses, garages and even sheds as
buildings but exclude bus shelters.

I'd also expect a bus shelter to have, at a minimum, a roof and at least
one wall.  I don't think we need to tag it with covered or roof because if
it doesn't have a roof/canopy it's not a shelter   As in you cannot shelter
from the rain unless it has a roof.

Note also that at one point in time (around 6 months ago) some page in the
wiki I stumbled across said that covered=yes in combination with a bus
platform meant that the platform was underground or something like that.
Which had me hastily remove the covered=yes I'd put on bus shelters because
a few months prior to that something in the wiki implied it was as
necessary as tagging a bench if there was one.

It would be nice if we could sort this out. :)

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

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

2018-06-18 Thread marc marc

Le 18. 06. 18 à 17:22, Kevin Kenny a écrit :
> Would it be feasible to say that building=yes is a default (except, 
> perhaps, for rock_shelter, sun_shelter) and that mappers are expected to 
> place an expected building=no on the exceptions?

please never do that.
you never known if the mapper have checked the implied value or not.
and therefore the auto-added tag lost all meaning.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

2018-06-18 Thread Kevin Kenny

On Mon, Jun 18, 2018 at 11:08 AM  wrote:

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

Would it be feasible to say that building=yes is a default (except,
perhaps, for rock_shelter, sun_shelter) and that mappers are expected to
place an expected building=no on the exceptions?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

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 

 &lng=9.078079866007897&z=17&pKey=90pd5WuYg8zOk_L8dxLFFQ&focus=photo
https://www.mapillary.com/app/?lat=49.08985722389377 

 &lng=9.07931005221235&z=17&pKey=oXQHKqb3Lc3Ae9IXj-5PHw&focus=photo
https://www.mapillary.com/app/?lat=49.10616167487336 

 &lng=9.121348618135698&z=17&pKey=8xUGL_VKp45sOfd9VW7dUw&focus=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] `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  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  >:
>> 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&lng=9.078079866007897&z=17&pKey=90pd5WuYg8zOk_L8dxLFFQ&focus=photo
>>>  
>>> 
>>> https://www.mapillary.com/app/?lat=49.08985722389377&lng=9.07931005221235&z=17&pKey=oXQHKqb3Lc3Ae9IXj-5PHw&focus=photo
>>>  
>>> 
>>> https://www.mapillary.com/app/?lat=49.10616167487336&lng=9.121348618135698&z=17&pKey=8xUGL_VKp45sOfd9VW7dUw&focus=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] A new Tag for "helicopter services"?

2018-06-18 Thread ael

On Mon, Jun 18, 2018 at 03:06:37PM +0200, gorgonz wrote:
> I'm looking for a tag, that describes an office, that offers helicopter
> services. Jobs are emergencies, round trips and aerial views for
> example. What is to be noted: this describes the place of the office and
> not the according landing field.
> 
> I would setup a proposal for
> 
> office=helicopter_service
> 
> Of course, any other solutions are welcome as well :-)
> 
> How are You thinking about this?

I think it is not an office. An office is primary a place for clerical 
and related activities.

ael



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

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

2018-06-18 Thread Jo

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 :

> 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&lng=9.078079866007897&z=17&pKey=90pd5WuYg8zOk_L8dxLFFQ&focus=photohttps://www.mapillary.com/app/?lat=49.08985722389377&lng=9.07931005221235&z=17&pKey=oXQHKqb3Lc3Ae9IXj-5PHw&focus=photohttps://www.mapillary.com/app/?lat=49.10616167487336&lng=9.121348618135698&z=17&pKey=8xUGL_VKp45sOfd9VW7dUw&focus=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

Re: [Tagging] A new Tag for "helicopter services"?

2018-06-18 Thread Clifford Snow

office=air_charter should fit. The ones around here offer both fixed wing
and helicopter services.

With office=air_charter you could also add
air_charter=helicopter

Clifford

On Mon, Jun 18, 2018 at 6:06 AM gorgonz  wrote:

> I'm looking for a tag, that describes an office, that offers helicopter
> services. Jobs are emergencies, round trips and aerial views for example.
> What is to be noted: this describes the place of the office and not the
> according landing field.
>
> I would setup a proposal for
>
> office=helicopter_service
>
> Of course, any other solutions are welcome as well :-)
>
> How are You thinking about this?
>
>
> ___
> 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] `amenity=shelter` implies `building=yes`?

2018-06-18 Thread Martin Koppenhoefer

sent from a phone

> On 17. Jun 2018, at 06:45, Bryan Housel  wrote:
> 
> Does `amenity=shelter` imply `building=yes`?

it does not, many places tagged like this will be bus stops and dedicated 
structures set up for hikers, but there can also be other places e.g. offering 
shelter below a rock or other natural configuation, that are tagged so (I 
recall a discussion from the local mailing list where people told they had used 
it like this).

The wiki does not require a man made structure or building for amenity=shelter 
so the above seems ok.

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

[Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

> On Jun 17, 2018, at 7:34 AM, Andrew Harvey  wrote:
> 
> If the consensus is to change it to emergency=lifeguard + lifeguard=*, then I 
> think this needs to be changed in:
> 
> 1. The wiki
> 2. Put forward a proposal to do a mechanical edit to change the existing tags
> 3. Carry out that mechanical edit
> 4. Add the preset in iD
> 
> I don't think it's far to the people who put the effort in to do a great job 
> on the wiki documentation and those who've been mapping to that accepted 
> tagging per the wiki, to change (4) without us first/while doing 1,2,3.
> 
> I think only then we can propose to osm-carto for this to be rendered on the 
> default OSM basemap.

This is great!  Happy to see that people are recognizing that some work (but 
not a lot) needs to happen before we change a tag from one thing to another 
thing.

I’ve created a repo where we can track these things:
https://github.com/osmlab/osm-tagging 

I’ll start opening issues for the things we’ve agreed to and I’ll add an issue 
template so that people can check off the items once they are done and close 
the issue once all the steps are completed.  

The repo can link back to the relevant discussion(s) on the tagging mailing 
list.  I think we should continue to make sure that every change is raised on 
the tagging mailing list for WWIC [1] reasons.

Eventually this repo may also contain code and tools for gaining better 
insights into tagging and making changes to tags.

Thanks Bryan

[1] http://www.ftrain.com/wwic.html 

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

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

> 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&lng=9.078079866007897&z=17&pKey=90pd5WuYg8zOk_L8dxLFFQ&focus=photo
>>  
>> 
>> https://www.mapillary.com/app/?lat=49.08985722389377&lng=9.07931005221235&z=17&pKey=oXQHKqb3Lc3Ae9IXj-5PHw&focus=photo
>>  
>> 
>> https://www.mapillary.com/app/?lat=49.10616167487336&lng=9.121348618135698&z=17&pKey=8xUGL_VKp45sOfd9VW7dUw&focus=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] A new Tag for "helicopter services"?

2018-06-18 Thread gorgonz

I'm looking for a tag, that describes an office, that offers helicopter
services. Jobs are emergencies, round trips and aerial views for
example. What is to be noted: this describes the place of the office and
not the according landing field.

I would setup a proposal for

office=helicopter_service

Of course, any other solutions are welcome as well :-)

How are You thinking about this?


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

Re: [Tagging] emergency=lifeguard

2018-06-18 Thread Andrew Harvey

On 18 June 2018 at 21:28, Martin Koppenhoefer 
wrote:
>
> 2018-06-18 13:17 GMT+02:00 Andrew Harvey :
>
>> 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
>>
>
> there are different kind of "supervision" on beaches possible: supervision
> that the equipment at the beach is fine (including for example chairs,
> umbrellas, sport pitches), or lifeguards who do not control the beach but
> the water in front of the beach, and do only check for people endangered by
> the water, not for things that might be damaged. The supervision tag
> definition is not clear on this (or if you read it literally, is not
> applying unambiguously well to lifeguards).
>

Agreed but the wiki for beach says when applied to beaches it specifically
means supervised by a lifeguard, when applied to other features yes it's
unrelated to lifeguards. This is how I've been using the tag, I think
that's okay as the default. It is common for beaches to have supervision
that's not a lifeguard? I'm all ears for a proposal for finer grain
tagging, but until them I'd encourage people to keep mapping per the wiki
using supervised on beaches with lifeguards.

On 18 June 2018 at 21:38,  wrote:
>
> 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?
>

I'd suggest that if there are sections permanently patrolled, to break it
up and use a multipolygon relation on the whole beach and tag each
patrolled section as supervised. Just like how a single road is split up to
tag different maxspeed, surface, lanes etc.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

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

2018-06-18 Thread Martin Koppenhoefer

2018-06-18 13:17 GMT+02:00 Andrew Harvey :

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



there are different kind of "supervision" on beaches possible: supervision
that the equipment at the beach is fine (including for example chairs,
umbrellas, sport pitches), or lifeguards who do not control the beach but
the water in front of the beach, and do only check for people endangered by
the water, not for things that might be damaged. The supervision tag
definition is not clear on this (or if you read it literally, is not
applying unambiguously well to lifeguards).

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

Re: [Tagging] emergency=lifeguard

2018-06-18 Thread Andrew Harvey

On 18 June 2018 at 21:04,  wrote:

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

If they move around the beach day to day, then the lifeguard=place tag
isn't appropriate. I think it's only when there is pretty much a permanent
chair/position (can be seasonal or with opening hours, but has some
recurrence to it)


>
> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

2018-06-18 Thread Martin Koppenhoefer

2018-06-18 13:04 GMT+02:00 :

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



 "lifeguard=place" is currently not used at all, and I do not believe it is
a good tag. "place" is so generic, it doesn't allow for any deduction of
meaning more than "thing" or "feature", and it is used for toponyms as a
key in OSM.
On beaches I would distinguish lifeguards that operate out of a structure
like a tower, a cabin, office or a similar building, from those who only
sit in a chair below an umbrella or a temporary roof, or maybe not even.

Shall it be a feature and a property (feature would indicate the position,
as property you could add something like lifeguard=yes to a beach or
swimming pool (likely implied).

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

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

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

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

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

2018-06-18 Thread Warin


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

2018-06-18 Thread Andrew Harvey

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

Agreed, lifeguard=place might just have a flag/chair which is only there
sometimes, which so long as there is some regularity to it, I think is fine
for OSM.

On 18 June 2018 at 18:39,  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?
>
>
>
> 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
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=lifeguard

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