Re: [Tagging] emergency=lifeguard

[Warin]

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


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




Err not in the uk ... coast guard is not military.

See

https://en.wikipedia.org/wiki/Her_Majesty%27s_Coastguard

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


In Australia that are volunteers that do marine rescue e.g.

http://marinerescueqld.org.au/


None of these fit in to the beach lifeguard situation.

I have no idea what the though was behind the OSM water rescue station . 
I think that is just confusing.


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

Re: [Tagging] Feature Proposal - RFC - Sauna

[Rory McCann]

I suggest adding `sauna=gay`, for a gay bathhouse. "gay" is a
simplification since many men who have sex with men visit them (not just
gay men). `sauna=msm` sounds clinical and might be not obvious to data
users.

In some countries (like Germany) saunas are always naked, in others
(e.g. Ireland) that is definitely not the case, you're expected to wear
your swimsuit). I don't know if that's worth tagging or if data users
should just deduce it from the country.

On 10/06/18 14:01, Jyri-Petteri Paloposki wrote:

Hi,

proposing a new (or actually amended) use of the sauna key to specify
which kind of sauna the leisure=sauna is. The proposal can be found in
https://wiki.openstreetmap.org/wiki/Proposed_features/sauna.

The proposed values as of now are as follows:

– sauna=yes
   General purpose value
– sauna=hot
   A Finnish-style sauna with a temperature of over 60°C because of the
water thrown on the rocks of the stove. This kind of sauna is relatively
dry because of the high temperature.
– sauna=steam
   A Turkish-style steam sauna with a lower temperature and limited
visibility because of the steam generated.
– sauna=smoke
   A Finnish-style hot sauna in which the stove has no chimney but
instead the smoke fills the room when the sauna is prepared, and the
smoke is then ventilated out when the sauna is ready.
– sauna=dry
   A non-steam dry sauna in which water is not thrown on the stove.
– sauna=aroma
   A sauna that constantly has an aroma. A Finnish sauna with occasional
aroma liquid added to the water is tagged as sauna=hot.
– sauna=infrared
   A sauna-like construction that is used for infrared therapy.

Best regards,





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

Re: [Tagging] emergency=fire_alarm_box

[Warin]

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

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



Roads can be found just about anywhere. We map those.

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.



Those concerned can go ahead amp map the things that concern them.

Does not mean they will be rendered on most maps.

Like fire hydrants and fire extinguishers .. they can be mapped.


For me a 'fire alarm box' is where you go to find out where the fire 
alarm originated from, or to isolate some section  or to perform 
testing/maintenance.


The fire alarm manual trigger points are some thing else... don't know 
what to call e=them off the top of may head, but not a 'box'.



*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




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

Re: [Tagging] emergency=fire_alarm_box

[Warin]

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


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…




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




*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



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

Re: [Tagging] Feature Proposal - RFC - Telecom local netwoks

[Lionel Giard]

In Belgium, we often call them "Local EXchange (LEX)", that's a simple name
change from the "telephone exchange" that at least indicate that it is not
only telephone in it !
The name vary but it always refer to the same "central office or telephone
exchange" and the difference is probably only cultural/historical.

2018-06-11 8:32 GMT+02:00 François Lacombe :

> Hi all
>
> Le lun. 11 juin 2018 à 01:29, Paul Allen  a écrit :
>
>> It also states that in the UK, the switchgear is a telephone exchange and
>> the building the switches
>> are housed in is called a telephone exchange (we Brits aren't very
>> inventive where terminology is concerned).
>>
>
> Then we do have an issue here
>
> It's the same as calling this a "transformer"
> https://www.epcomediterranee.com/medias/fiches_produits/
> fiche/438-poste-de-transformation-couloir-de-
> manoeuvre-type-pac-4uf-5uf.JPG
>
> While it's a "power substation" (power=substation) building and the
> transformer (power=transformer) is actually inside
> http://www.infos-reseaux.com/photos/image/poste-de-
> distribution-transformateur-bt/48-24062008661.jpg
>
> Telephone exchange hosting buildings use to be tagged with man_made=MDF
> because the "Main Distribution Frame" is inside too. Moving from MDF to
> telephone exchange won't bring any benefit i'm affraid.
>
> I'm not focused on central_office anyway, but we need two different terms
> to distinguish buildings from hosted devices and central office is the best
> we found for buildings
>
> All the best
>
> François
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jo]

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.

There is no need to bother the user, in case there is an adjacent way with
this tag. Then it's obvious which part of the split off way should either
remain in the relation or keep the tag.

In case there is no adjacent way with that tag, or the relation contains 2
ways which don't connect, a validation error should be shown.

Polyglot

Op ma 11 jun. 2018 om 08:07 schreef Mateusz Konieczny <
matkoni...@tutanota.com>:

> For JOSM see https://josm.openstreetmap.de/ticket/11054
>
> 11. Jun 2018 06:42 by bhou...@gmail.com:
>
> 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.
>
> ___
> 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 - Sauna

[Tom Pfeifer]

I suggest to distinguish the key for the operation mode (hot, steam etc)
from those for the expected user group and dress code.

On 11.06.2018 09:29, Rory McCann wrote:

I suggest adding `sauna=gay`, for a gay bathhouse. "gay" is a
simplification since many men who have sex with men visit them (not just
gay men). `sauna=msm` sounds clinical and might be not obvious to data
users.

In some countries (like Germany) saunas are always naked, in others
(e.g. Ireland) that is definitely not the case, you're expected to wear
your swimsuit). I don't know if that's worth tagging or if data users
should just deduce it from the country.

On 10/06/18 14:01, Jyri-Petteri Paloposki wrote:

Hi,

proposing a new (or actually amended) use of the sauna key to specify
which kind of sauna the leisure=sauna is. The proposal can be found in
https://wiki.openstreetmap.org/wiki/Proposed_features/sauna.

The proposed values as of now are as follows:

– sauna=yes
   General purpose value
– sauna=hot
   A Finnish-style sauna with a temperature of over 60°C because of the
water thrown on the rocks of the stove. This kind of sauna is relatively
dry because of the high temperature.
– sauna=steam
   A Turkish-style steam sauna with a lower temperature and limited
visibility because of the steam generated.
– sauna=smoke
   A Finnish-style hot sauna in which the stove has no chimney but
instead the smoke fills the room when the sauna is prepared, and the
smoke is then ventilated out when the sauna is ready.
– sauna=dry
   A non-steam dry sauna in which water is not thrown on the stove.
– sauna=aroma
   A sauna that constantly has an aroma. A Finnish sauna with occasional
aroma liquid added to the water is tagged as sauna=hot.
– sauna=infrared
   A sauna-like construction that is used for infrared therapy.




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

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

[Simon Poole]

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- reluctant to support one-off tag semantics that require
special code to handle them.

Note with respect to the parallel discussion on tagging systematics,
this kind of thing is multiple orders of magnitude worse than
inconsistencies in tag naming and so on (which at least from an editor
pov can typically handled by configuration in a preset).

Simon


Am 11.06.2018 um 06:42 schrieb Bryan Housel:
> 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.
>
> 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.
>
> 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!)
>
> I notice that `transit:lanes` has already been tagged on around 4000
> or so ways, so I thought it would be worth pointing out that the
> proposal is Dead on Arrival in it’s current state.  We should rework
> it before people tag too many more of these and end up disappointed.
>
> thanks, Bryan
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

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

[José G Moya Y .]

Thank you!

Regards,

José

El lun., 11 de junio de 2018 7:59, 
escribió:

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

Re: [Tagging] Feature Proposal - RFC - Sauna

[Max]

Great idea to make the sauna key more useful. But it should be looked at 
in more detail and with less of a Finnish bias. :)


Some questions that the tag should address:

1. How to tag a place which has several individual saunas?
1b. What about other sauna related amenities like cold pools (how 
cold?), whirlpools, hot tubs (how hot?)... Ice buckets, etc.

2. What's the method of heating: Wood, electricity...
3. What's the designated temperature in that sauna?
4. Are occupants allowed to handle the löyly themselves or is only staff 
allowed to do that? At what times do they (often Saunas have löyly at 
the full hour/ half hour, etc)

5. how many people fit inside?
6. how to tag the opening hours if they are different for men/women/mixed?
7. is clothing allowed?
8. There ara also other types of saunas in the world that might have 
their particularities. 찜질방 in Korea come to my mind, where you can 
actually spend as much time as you want and even stay overnight. The 
very traditional types are basically a kiln and have a fire burning 
inside for a day and then the ashea are brushed out and the walls 
radiate the heat for another day.


Then there are countries where the word sauna is just a synonym for a 
place where people fuck, like it is in France. Might lead to odd 
situations if those are confused.


Some of these things on the list may indeed be concluded from the 
country specific customs, but a map and tagging scheme should at least 
consider them


m.


On 10.06.2018 14:01, Jyri-Petteri Paloposki wrote:

Hi,

proposing a new (or actually amended) use of the sauna key to specify
which kind of sauna the leisure=sauna is. The proposal can be found in
https://wiki.openstreetmap.org/wiki/Proposed_features/sauna.

The proposed values as of now are as follows:

– sauna=yes
   General purpose value
– sauna=hot
   A Finnish-style sauna with a temperature of over 60°C because of the
water thrown on the rocks of the stove. This kind of sauna is relatively
dry because of the high temperature.
– sauna=steam
   A Turkish-style steam sauna with a lower temperature and limited
visibility because of the steam generated.
– sauna=smoke
   A Finnish-style hot sauna in which the stove has no chimney but
instead the smoke fills the room when the sauna is prepared, and the
smoke is then ventilated out when the sauna is ready.
– sauna=dry
   A non-steam dry sauna in which water is not thrown on the stove.
– sauna=aroma
   A sauna that constantly has an aroma. A Finnish sauna with occasional
aroma liquid added to the water is tagged as sauna=hot.
– sauna=infrared
   A sauna-like construction that is used for infrared therapy.

Best regards,




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

Re: [Tagging] Feature Proposal - RFC - Telecom local netwoks

[Stephen Doerr]

On 10 June 2018, at 16:53, François Lacombe  wrote:

>A telephone exchange is a particular device inside a central office.


Eh? No it's not. It's a building containing all manner of equipment for routing 
telephone calls in a town or other district and also,in former times, rows of 
women operating manual switchboards to connect callers. Central office is not a 
term I'd associate with telephone services: it sounds like a word for the 
headquarters of a company, political party, or other organization.

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

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

[Bryan Housel]

Amazing, but I’m not surprised that the JOSM devs figured this out years ago :)

OK, so we should probably have a conversation about how a tag like this can 
continue to exist for years with - not just no support but - literally everyone 
who writes software speaking out against it.

But for right now, can we get that page taken down so people stop tagging it, 
and have a proper proposal put up and accepted?
How quickly can the tagging community turn this around?

For the existing data, obviously I’m fine to just delete it, but I imagine 
someone out there would like their work preserved and converted to whatever new 
thing we need to (quickly) agree on.

thanks, Bryan


> On Jun 11, 2018, at 2:06 AM, Mateusz Konieczny  
> wrote:
> 
> For JOSM see https://josm.openstreetmap.de/ticket/11054 
> 
> 
> 11. Jun 2018 06:42 by bhou...@gmail.com :
> 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.
> ___
> 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

[Stephen Doerr]

On 10 June 2018, at 17:05, Paul Allen  wrote:

>
>
>On Sun, Jun 10, 2018 at 4:16 PM, Yves  wrote:
>

>I doubt you'll find an airport that doesn't have a waiting room/area 
>somewhere.  Probably also a bar or cafe.
>
>Lounges are the expensive places catering to the rich customer 
>(executive-class ticket or money to burn on
>
>food/drink) rather than the ordinary traveller needing a place to sit.

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. 

Steve___
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] Feature Proposal - RFC - Lounges

[Paul Allen]

On Mon, Jun 11, 2018 at 12:17 PM, Stephen Doerr 
wrote:

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
>

Yeah, you're right.  However, for general travellers that "departure
lounge" is a waiting room.  Not even a glorified
waiting room.  But marketers had to abuse language (as always) to make it
sound better than it actually is.

Interestingly, a "departure lounge" (for the common herd) doesn't appear to
meet the definition of the proposal for
calling it a lounge.

Yet another problem.

-- 
Paul
___
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] Feature Proposal - RFC - Telecom local netwoks

[Philip Barnes]

On 10 June 2018 23:42:07 BST, "François Lacombe"  
wrote:
>2018-06-11 0:14 GMT+02:00 Graeme Fitzpatrick :
>
>> Thanks for that, but I'm afraid that the continual OSM worldwide
>> translation problem is raising it's ugly head yet again.
>>
>> In Australia at least, "telephone exchange" refers to the building
>itself,
>> which houses the Main Frame (where all the cables are terminated) &
>the
>> various types of switching equipment. In 20 years of working for our
>> Telecom, I never heard the phrase "Central Office" - the closest
>thing that
>> would refer to is an Admin Office of some sort.
>>
>
>I understand this well, and we have to choose a single value to do the
>job
>worldwide.
>
>As OSM main language is British English, I would use central office.
>Furthermore, telephone exchange sounds to be focused on telephone
>service

Office to my British ears sounds American, in British English we refer to a 
telephone exchange. 

For example my town has a largeish building, which is probably very empty these 
days and dotted over the town are cabinets where the main lines/fibre is split 
out to provide links to individual premises. 

Phil (trigpoint) 

-- 
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] Feature Proposal - RFC - Lounges

[Anton Klim]

 Thanks everyone for your comments and suggestions.

I realised I might have bitten a bit too much with this tag, trying to
cover bare-bones waiting area and lounges under one key,
At this stage I am not expanding the tag to waiting rooms at
offices/institutions, rather focusing on the airport/hotel concept.
In light of this, I've also amended the proposed tagging to be more
specific, changing it to *airport_lounge *for the key.
I still feel like amenity is a good fit since it's a place people visit.

Andrew, many thanks for the reminder we have some tags for facilities such
as showers already. How would we go about covering things which are not
already in the scheme, e.g. whether food/drink is offered and of what type?
I don't think cuisine quite covers it.

Anton

2018-06-11 15:23 GMT+03:00 :

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

Re: [Tagging] emergency=fire_alarm_box

[Philip Barnes]

Fire alarms, often a hand operated bell, are a common feature on campsites.

Phil (trigpoint) 

On 11 June 2018 05:28:43 BST, Bryan Housel  wrote:
>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

-- 
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] Feature Proposal - RFC - Telecom local netwoks

[Kevin Kenny]

On Mon, Jun 11, 2018 at 9:13 AM Philip Barnes  wrote:

> >As OSM main language is British English, I would use central office.
> >Furthermore, telephone exchange sounds to be focused on telephone
> >service
>
> Office to my British ears sounds American, in British English we refer to
> a telephone exchange.
>
> For example my town has a largeish building, which is probably very empty
> these days and dotted over the town are cabinets where the main lines/fibre
> is split out to provide links to individual premises.
>

'Central office' is definitely an Americanism, but 'telephone exchange' is
also perfectly comprehensible on this side of the pond. We generally call
the system therein a 'switch' (collectively., 'switch gear').

They're not necessarily 'small' buildings, the way the Wiki suggests: I
recall that there was one in Manhattan that served nearly 200,000
telephones and was eleven storeys tall. (A fire there in 1975 caused what
was arguably telephony's worst service disaster of all time.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Lounges

[Philip Barnes]

On 10 June 2018 14:26:06 BST, ael  wrote:
>On Sun, Jun 10, 2018 at 01:16:53PM +0100, Paul Allen wrote:
>> On Sun, Jun 10, 2018 at 12:40 PM, Yves  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.
>> Waiting room, however, is EXACTLY what you want to describe. 
>Hospitals and
>> doctors' surgeries have waiting rooms.
>> So do train stations and bus stations.
>> 
>> I am firmly, solidly and unswervingly opposed to "lounge" for this
>proposal.
>
>+1
>
>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.
>
Lounge is very much used in British English to describe the posh carpeted room 
in a pub. 

I can remember when prices were higher in the lounge than they were in the bar. 

Usage of lounge in a house will depend where you are from, in my experience 
living room is more common along with sitting room. 

Phil (trigpoint) 

-- 
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 - Telecom local netwoks

[Philip Barnes]

On 11 June 2018 14:58:59 BST, Kevin Kenny  wrote:
>On Mon, Jun 11, 2018 at 9:13 AM Philip Barnes 
>wrote:
>
>> >As OSM main language is British English, I would use central office.
>> >Furthermore, telephone exchange sounds to be focused on telephone
>> >service
>>
>> Office to my British ears sounds American, in British English we
>refer to
>> a telephone exchange.
>>
>> For example my town has a largeish building, which is probably very
>empty
>> these days and dotted over the town are cabinets where the main
>lines/fibre
>> is split out to provide links to individual premises.
>>
>
>'Central office' is definitely an Americanism, but 'telephone exchange'
>is
>also perfectly comprehensible on this side of the pond. We generally
>call
>the system therein a 'switch' (collectively., 'switch gear').
>
>They're not necessarily 'small' buildings, the way the Wiki suggests: I
>recall that there was one in Manhattan that served nearly 200,000
>telephones and was eleven storeys tall. (A fire there in 1975 caused
>what
>was arguably telephony's worst service disaster of all time.)

I agree they are not small, the one in my small town is the same size as the 
swimming pool building. 

Phil (trigpoint) 

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

[Philip Barnes]

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]

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 , emergency=stop_button

[Bryan Housel]

Ok cool

So we have
`emergency=fire_alarm`   (for both indoor pull and outdoor box types, invent a 
sub tag if needed to distinguish)
and
`emergency=stop_button`

Who wants to add these pages?
I’ll add presets for iD this week if we can just move this forward and wrap up 
the discussion.


Thanks, Bryan




> On Jun 11, 2018, at 10:50 AM,  
>  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.
>  

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

Re: [Tagging] emergency=fire_alarm , emergency=stop_button

[marc marc]

Le 11. 06. 18 à 16:53, Bryan Housel a écrit :

> `emergency=fire_alarm`   (for both indoor pull and outdoor box types, 
> invent a sub tag if needed to distinguish)

indoor=yes
or
location=outdoor<>indoor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=fire_alarm_box

[Paul Allen]

On Mon, Jun 11, 2018 at 3:50 PM,  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

[Philip Barnes]

At petrol stations they are typically high up, not placed for general use.

Phil (trigpoint) 

On 11 June 2018 16:00:23 BST, Paul Allen  wrote:
>On Mon, Jun 11, 2018 at 3:50 PM, 
>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

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

[Bryan Housel]

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


> 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 



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


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


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.

Thanks, Bryan


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

[Bryan Housel]

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

Yes - do you think the via node in a turn restriction is also redundant?  It 
helps me a lot to know whether node joins are allowed around there, or whether 
something will break.

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

and
https://github.com/openstreetmap/iD/issues/4921 

for some situations where it’s super helpful to prevent a user from doing 
things to the via node.


Thanks, Bryan

___
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

[Simon Poole]

Am 11.06.2018 um 17:19 schrieb osm.tagg...@thorsten.engler.id.au:
>
> *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?
>
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

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



signature.asc
Description: OpenPGP digital signature
___
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

[Tagging] wall and block that aren't a barrier

[Tobias Knerr]

On 09.06.2018 23:13, marc marc wrote:
> https://upload.wikimedia.org/wikipedia/commons/thumb/2/22/Rehbrunnen_04.jpg/800px-Rehbrunnen_04.jpg

Based on this picture, the current mapping is clearly incorrect. This
basin doesn't qualify as a barrier=retaining_wall even if we allow for a
very generous reading of the tag's definition.

For most use cases, I believe it would be entirely sufficient to draw an
area for the fountain, and add subtags as desired. For map users who are
interested in how the fountain looks, the image and wikimedia_commons
tags are already available.

The mapper seems to be interested in going beyond that and creating a
relatively detailed model of the fountain, which is a legitimate goal
and might be useful in some applications, e.g. 3D rendering. However,
I'd argue that our editors and data model aren't really the right tools
for that job. It would seem more practical to create a model of the
fountain in Blender or SketchUp, which could then be uploaded to the 3D
Model Repository and linked with OSM.

If we to try to model the fountain using OSM ways and areas anyway,
though, then I'd rather see specialized tags for fountain micromapping
(nano-mapping?) introduced. Re-purposing existing tags for this use case
isn't a good idea imo.



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

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

[Brad Neuhauser]

Just an FYI, pet/service animal "relief areas" are now required in US
airports of a certain size. That's probably why the four places tagged
amenity=pet_relief_area are in US airports. See
http://petfriendlytravel.com/airports

On Mon, Jun 11, 2018 at 4:08 AM, José G Moya Y.  wrote:

> Thank you!
>
> Regards,
>
> José
>
> El lun., 11 de junio de 2018 7:59, 
> escribió:
>
>> 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 <
>> tagging@openstreetmap.org>
>> *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
>>
>
> ___
> 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

[Mateusz Konieczny]

11. Jun 2018 13:09 by bhou...@gmail.com :

 


> But for right now, can we get that page taken down so people stop tagging it, 
> and have a proper proposal put up and accepted?




I added 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2Ftransit&type=revision&diff=1617128&oldid=1617122
 





Note that in case of horrible tag Wiki pages are not deleted but describing tag 
as a horrible - 


especially for horrible tags that are popular or used to be popular.




And all proposal are kept, even really stupid ones. 




 

> OK, so we should probably have a conversation about how a tag like this can 
> continue to exist for years




Part of the issue is that currently only JOSM considers encouraging users to 
not use completely

broken tags as something important.




While iD design may exclude flooding user with warnings -

 why its rendering suggests that for example [building=yes; demolished=yes] is 
a good idea?




Current rendering suggests to editors that it is great idea to tag this way - 
see

https://upload.wikimedia.org/wikipedia/commons/5/51/Special_rendering_for_demolished%3Dyes_in_iD_editor_of_OSM_data.png
 





> Amazing, but I’m not surprised that the JOSM devs figured this out years ago 
> :)



Note that JOSM issue was not closed as WONTFIX (yet?).___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Sauna

[Jyri-Petteri Paloposki]

On 11.06.2018 12:17, Max wrote:
> Great idea to make the sauna key more useful. But it should be looked at
> in more detail and with less of a Finnish bias. :)
> 
> Some questions that the tag should address:
> 
> 1. How to tag a place which has several individual saunas?
> 1b. What about other sauna related amenities like cold pools (how
> cold?), whirlpools, hot tubs (how hot?)... Ice buckets, etc.
> 2. What's the method of heating: Wood, electricity...
> 3. What's the designated temperature in that sauna?
> 4. Are occupants allowed to handle the löyly themselves or is only staff
> allowed to do that? At what times do they (often Saunas have löyly at
> the full hour/ half hour, etc)
> 5. how many people fit inside?
> 6. how to tag the opening hours if they are different for men/women/mixed?
> 7. is clothing allowed?
> 8. There ara also other types of saunas in the world that might have
> their particularities. 찜질방 in Korea come to my mind, where you can
> actually spend as much time as you want and even stay overnight. The
> very traditional types are basically a kiln and have a fire burning
> inside for a day and then the ashea are brushed out and the walls
> radiate the heat for another day.
> 
> Then there are countries where the word sauna is just a synonym for a
> place where people fuck, like it is in France. Might lead to odd
> situations if those are confused.
> 
> Some of these things on the list may indeed be concluded from the
> country specific customs, but a map and tagging scheme should at least
> consider them

Thanks for the comment!

Right now I decided to go with the easy one, ie. the sauna experience.
The heating, strict temperature etc. are more of per-location things,
and go quite a bit deeper – of course we could expand the definition
right away to those also.

Number eight sounds like it would fit in this ”experience”, so we should
probably add that one. Is there a western spelling for that?

Not sure what to do with the ”brothel sauna”. I'd say we add that as a
”see also”, as there seems to be a used tagging for that already:
https://taginfo.openstreetmap.org/keys/brothel%3Asaunaclub . I don't
think it fits the sauna=* definition very well anyway :)

Best regards,
-- 
Jyri-Petteri Paloposki

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

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

[Bryan Housel]

> On Jun 11, 2018, at 1:17 PM, Mateusz Konieczny  
> wrote:
> 11. Jun 2018 13:09 by bhou...@gmail.com :
> But for right now, can we get that page taken down so people stop tagging it, 
> and have a proper proposal put up and accepted?
> I added 
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2Ftransit&type=revision&diff=1617128&oldid=1617122
>  
> 
Thank you!


> While iD design may exclude flooding user with warnings - why its rendering 
> suggests that for example [building=yes; demolished=yes] is a good idea?
> 

I already told you why here:  
https://github.com/openstreetmap/iD/issues/4501#issuecomment-393726776 


Any feature with any kind of ephemeral tag gets drawn with dashes.

iD also have a special rendering for old style multipolygons, so people can 
clean them up if they want to. Rendering something with dashes doesn’t mean we 
are encouraging people to tag a certain way - it just means “hey mapper, pay 
attention to this thing, there is something interesting about it”.

Please start a separate discussion thread if you want to discuss lifecycle 
tagging. 


Thanks, Bryan

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

Re: [Tagging] Feature Proposal - RFC - Sauna

[Max]

On 11.06.2018 19:28, Jyri-Petteri Paloposki wrote:

Number eight sounds like it would fit in this ”experience”, so we should
probably add that one. Is there a western spelling for that?


The romanization reads Jjimjilbang
https://en.wikipedia.org/wiki/Jjimjilbang

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

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

[Mateusz Konieczny]

11. Jun 2018 19:17 by matkoni...@tutanota.com :
> Note that JOSM issue was not closed as WONTFIX (yet?).




And now it got closed as wontfix. 

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

Re: [Tagging] Feature Proposal - RFC - Lounges

[ael]

On Mon, Jun 11, 2018 at 03:12:49PM +0100, Philip Barnes wrote:
> 
> 
> On 10 June 2018 14:26:06 BST, ael  wrote:
> >> I am firmly, solidly and unswervingly opposed to "lounge" for this
> >proposal.
> >
> >+1
> >
> >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.
> >
> Lounge is very much used in British English to describe the posh carpeted 
> room in a pub. 

I give you that, but note that pubs were originally in private homes :-)

Completely agree that living room is the much preferred term, but lounge
is well understood. 

But I don't want to get lost in philology of which I know little. 
Qualified use like Airport_lounge seems unexceptional.

ael


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

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

[Paul Johnson]

On Sun, Jun 10, 2018, 23:43 Bryan Housel  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?

 (could you imagine if we tagged turn restrictions as  maybe-a-relation or
> maybe-a-way-tag ?? nope!)
>

Yes, because we have that exact situation because we refused to kill off
the route=road refs on constituent ways dinosaur.  Your point of it being
bad stands, however.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Lounges

[Martin Koppenhoefer]

sent from a phone

> On 10. Jun 2018, at 13:28, Paul Allen  wrote:
> 
> If proposed as amenity=waiting_room I'd vote for it.  If proposed as 
> amenity=lounge I'd vote against it. 


+1

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

Re: [Tagging] emergency=lifeguard

[Graeme Fitzpatrick]

On 11 June 2018 at 15:31, Andrew Harvey  wrote:

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

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?

I'd also go for the simple arrangement:

emergency=lifeguard

lifeguard=base/place/platform/tower


although


emergency=life_ring should remain separate


Thanks

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

Re: [Tagging] Feature Proposal - RFC - Lounges

[Martin Koppenhoefer]

sent from a phone

> On 10. Jun 2018, at 14:53,  
>  wrote:
> 
> In the context of an airport, a waiting room (or rather, waiting area) is 
> something like this:
> 
>  
> 


indeed, this is a waiting _area_ , both terms are about space dedicated to 
waste time waiting, but they have distinct meaning, rooms are about more 
intimate enclosed spaces, areas are typically open or „feel“ open (space). IMHO 
there is room for both tags, waiting_area and waiting_room.

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

Re: [Tagging] Feature Proposal - RFC - Lounges

[Martin Koppenhoefer]

sent from a phone

On 11. Jun 2018, at 23:08, Martin Koppenhoefer  wrote:

>> On 10. Jun 2018, at 13:28, Paul Allen  wrote:
>> 
>> If proposed as amenity=waiting_room I'd vote for it.  If proposed as 
>> amenity=lounge I'd vote against it. 
> 
> 
> +1


taking it back, sorry. We could probably have all three, waiting room/area and 
lounge.

Maybe waiting_lounge? airport lounge has the disadvantage that it doesn’t cover 
the same concept in train stations. Unlike airports it is not common there, but 
some (major) train stations have those lounges, usually access is limited (e.g. 
first class ticket, or some kind of membership in a frequent client program).

While I agree that lounge alone can be ambiguous, the qualifier ideally should 
not be repeating the context but describe the concept, -0.6 to airport_lounge.

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

Re: [Tagging] emergency=lifeguard

[Graeme Fitzpatrick]

On 11 June 2018 at 17:25, Warin <61sundow...@gmail.com> wrote:

> On 11/06/18 15:39, osm.tagg...@thorsten.engler.id.au wrote:
>
> *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.
>
>
> Err not in the uk ... coast guard is not military.
>
> See
>
> https://en.wikipedia.org/wiki/Her_Majesty%27s_Coastguard
>
> https://en.wikipedia.org/wiki/Royal_National_Lifeboat_Institution
>
>
> In Australia that are volunteers that do marine rescue e.g.
>
> http://marinerescueqld.org.au/
>
>
> None of these fit in to the beach lifeguard situation.
>
> I have no idea what the though was behind the OSM water rescue station . I
> think that is just confusing.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
Agree with you that "Coast Guard" is not a one-size-fits-all term.

There is amenity=rescue_station
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Drescue_station, which, to
my mind should actually also be an emergency= listing?

Looking at that, it appears that the whole emergency= area has been going
to be cleaned up
https://wiki.openstreetmap.org/wiki/WikiProject_Emergency_Cleanup - for the
last 4 years!

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Telecom local netwoks

[Graeme Fitzpatrick]

On 12 June 2018 at 00:21, Philip Barnes  wrote:

>
>
> On 11 June 2018 14:58:59 BST, Kevin Kenny 
> wrote:
>
> >> For example my town has a largeish building,
> >
> >They're not necessarily 'small' buildings, the way the Wiki suggests:
>
> I agree they are not small, the one in my small town is the same size as
> the swimming pool building.
>
> Phil (trigpoint)
>

Getting away from mapping for a moment :-), but talking "telephone
exchanges" internationally.

Are all of your's the same as most (definitely the bigger ones) in
Australia, & built on absolute prime real estate? :-)

Exchanges near here are almost always in the centre of town, usually on a
main road & frequently the busiest intersection - one even has ocean views!

Thanks

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

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

[Martin Koppenhoefer]

sent from a phone

> On 8. Jun 2018, at 17:32, Kevin Kenny  wrote:
> 
> Is there 'correct' tagging for these areas, which are widespread in the areas 
> that I map and are important to the public?


there are 2 competing tags, leisure=nature_reserve and boundary protected area 
for this kind of object. None of them states it is named after a forest, or 
mainly covered by forest. Maybe this could become an additional property, e.g. 
for protected_area objects?


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

[Martin Koppenhoefer]

sent from a phone

> On 9. Jun 2018, at 15:53, Paul Allen  wrote:
> 
> Landuse=forest could mean a group of trees which are not
> consistently used by a single organization for anything (and often called 
> "Xyz Forest"


interesting, can you give a real world example where a group of trees has 
actually the name “... forest”? I always thought a forest would require more 
trees.


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

[Warin]

On 12/06/18 08:35, Martin Koppenhoefer wrote:


sent from a phone


On 8. Jun 2018, at 17:32, Kevin Kenny  wrote:

Is there 'correct' tagging for these areas, which are widespread in the areas 
that I map and are important to the public?


there are 2 competing tags, leisure=nature_reserve and boundary protected area 
for this kind of object. None of them states it is named after a forest, or 
mainly covered by forest. Maybe this could become an additional property, e.g. 
for protected_area objects?


Usually the administration boundary does not define the plants stopping or 
starting at that same point.

So I prefer to define the plants with another relation/way rather than 
artificially use the administration boundary.

Thus I use landcover=trees (with natural=wood for the moment to keep rendering) 
for the tree areas - common around me and very extensive,
while the reserves and National Parks get different relations/ways for them.


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

Re: [Tagging] Feature Proposal - RFC - Telecom local netwoks

[François Lacombe]

Hi,

Thanks everyone for your remarks

According to
http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=722-06-05
Switching exchange = Telephone exchange = Central office

Could someone confirm that point to point or GPON fibre networks are
connected to a telephone exchange building too?
Can we call a fibre dedicated building a telephone exchange also ?

All the best

François


2018-06-11 23:57 GMT+02:00 Graeme Fitzpatrick :

>
>
>
> On 12 June 2018 at 00:21, Philip Barnes  wrote:
>
>>
>>
>> On 11 June 2018 14:58:59 BST, Kevin Kenny 
>> wrote:
>>
>> >> For example my town has a largeish building,
>> >
>> >They're not necessarily 'small' buildings, the way the Wiki suggests:
>>
>> I agree they are not small, the one in my small town is the same size as
>> the swimming pool building.
>>
>> Phil (trigpoint)
>>
>
> Getting away from mapping for a moment :-), but talking "telephone
> exchanges" internationally.
>
> Are all of your's the same as most (definitely the bigger ones) in
> Australia, & built on absolute prime real estate? :-)
>
> Exchanges near here are almost always in the centre of town, usually on a
> main road & frequently the busiest intersection - one even has ocean views!
>
> 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] I can't support transit:lanes

[Mateusz Konieczny]

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


> On Sun, Jun 10, 2018, 23:43 Bryan Housel <> 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