Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

[Hufkratzer]

This is not how the tag is used. It is often used for sports halls of 
sports centers, some examples can be found in
https://wiki.openstreetmap.org/wiki/Proposed_features/leisure%3Dsports_hall#Examples_in_the_OSM_database 
.
The wiki page for sports_hall says "A sports hall can often be found on 
a campus of a school or in a sports centre."


Recently you added to the wiki page for sports_centre that sports halls 
inside of sports centres don't need a leisure tag if the centre is 
mapped as an area. OTOH it says "Use building=* for any buildings which 
are included within the centre. These can be given different sport and 
leisure tags." AFAIK the sport tag always needs a physical tag. Is that 
recent addition compatible with that? Is building=* a physical tag for 
sport=*? It is not listed in 
https://wiki.openstreetmap.org/wiki/Key:sport#Associated_tags .


I think it would be too difficult for mappers to have different tagging 
rules for sports halls inside and outside of sports centres and 
depending on whether the sports center is mapped as a node or an area.


If you do not recommend to tag a sport hall inside of a sports centre 
with a leisure tag how do you recomend to tag a fitness studio inside of 
a sports centre and why?



On 07.09.2019 02:35, Joseph Eisenberg wrote:
> (Sent to you directly since I don't want to add too many posts to the
> mailing list)
>
>> +1, this is exactly how I see it as well
>
> Is this how the tag has been used in Rome and in other areas that you
> know? I'd like to add this to the page Tag:leisure=sports_hall to help
> clarify how it's different from a sports centre, but I want to confirm
> that this is the "de facto" meaning.
>
> Joseph
>
> On 9/7/19, Martin Koppenhoefer  wrote:
>>
>> sent from a phone
>>
>>> On 6. Sep 2019, at 13:47, Chris Hill  wrote:
>>>
>>> To me a sports centre is a place that's dedicated to sport in its own
>>> space or grounds. It may have outdoor pitches,courts etc as well as 
indoor
>>> provisions. I think it could have a gym, i.e. a space with gym 
equipment

>>> too.
>>>
>>> A sports hall, to me, is a building in an environment that is not 
wholly
>>> about sports,so a building in school grounds or in a business 
complex. It

>>> has more than just a gym room.
>>>
>>
>> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Feature proposal - RFC - Utility markers

[Mateusz Konieczny]

7 Sep 2019, 01:36 by fl.infosrese...@gmail.com:
> Ok this one is really interesting.
> Why not using marker=* to give its nature and another key utility=* with 
> values "gas", "power", "telecom", "water"... ?
>

Is it typical to map "it is marker of an
unknown kind" like splitting shop
and opening hours makes sense?
As many want to map shop and are
not interested in mapping opening
hours.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

[Joseph Eisenberg]

(Sent to you directly since I don't want to add too many posts to the
mailing list)

> +1, this is exactly how I see it as well

Is this how the tag has been used in Rome and in other areas that you
know? I'd like to add this to the page Tag:leisure=sports_hall to help
clarify how it's different from a sports centre, but I want to confirm
that this is the "de facto" meaning.

Joseph

On 9/7/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 6. Sep 2019, at 13:47, Chris Hill  wrote:
>>
>> To me a sports centre is a place that's dedicated to sport in its own
>> space or grounds. It may have outdoor pitches,courts etc as well as indoor
>> provisions. I think it could have a gym, i.e. a space with gym equipment
>> too.
>>
>> A sports hall, to me, is a building in an environment that is not wholly
>> about sports,so a building in school grounds or in a business complex. It
>> has more than just a gym room.
>>
>
>

>
> Cheers Martin

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

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

[Joseph Eisenberg]

Re: > "My UK school had both a gym and a sports hall."

What was the difference between the two? Was the gym like a "fitness
centre" for weight training, perhaps? In US English we tend to use
"gym" for what seems to be a "sports hall" in some dialects, and also
for "weight lifting gyms" and "fitness centres" full of exercise
equipment.

- Joseph

On 9/7/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 6. Sep 2019, at 13:47, Chris Hill  wrote:
>>
>> To me a sports centre is a place that's dedicated to sport in its own
>> space or grounds. It may have outdoor pitches,courts etc as well as indoor
>> provisions. I think it could have a gym, i.e. a space with gym equipment
>> too.
>>
>> A sports hall, to me, is a building in an environment that is not wholly
>> about sports,so a building in school grounds or in a business complex. It
>> has more than just a gym room.
>>
>
>
> +1, this is exactly how I see it as well
>
> Cheers Martin

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

Re: [Tagging] Feature proposal - RFC - Utility markers

[Joseph Eisenberg]

> I don't get the right term here. I see only 222 items for power=marker and 
> nothing for power:marker=*. Which one are you refering to with 35k uses 
> please?

Probably pipeline=marker, used 35k times:
https://taginfo.openstreetmap.org/tags/?key=pipeline=marker

> Why not using marker=* to give its nature and another key utility=* with 
> values...

Because most mappers only add 1 tag to each new object. (Folks like
you and me are an exception - and a year ago, when I was new at this,
I only usually added 1 tag per feature). If an object can be described
with one tag, it's better to do this and create several tags, (e.g.
pipeline=marker, power=marker) rather than requiring each object to be
tagged with 2 or 3 or 4 tags. This saves mapper time and makes sure
that each object is fully described.

- Joseph

On 9/7/19, François Lacombe  wrote:
> Hi all,
>
> Thank you for yout contributions
>
> Le ven. 6 sept. 2019 à 09:13, Joseph Eisenberg 
> a écrit :
>
>> I'm still opposed to this proposal:
>>
>
> Answers provided at
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Utility_markers_proposal#Oppose_deprecating_pipeline.3Dmarker_and_marker.3Dstone
>
> Le ven. 6 sept. 2019 à 09:18, Jez Nicholson  a
> écrit :
>
>> Arriving fresh to a proposal, my first action would be to look at what is
>> currently in OSM. There are 6,043 "marker"="stone", which is 81.5% of the
>> usage of "marker" in OSM. I would expect the proposal to support current
>> usage.
>>
> I respectably disagree on that point.
> Biggest problem is that current usage isn't documented, and may not have
> been reviewed like we are doing right now.
>
> This proposal aims to define values for marker=* to describe utility
> markers.
> Despite marker=stone may be unconsistent with what is proposed, it doesn't
> make it incompatible and this proposal only notices this fact without
> thinking of deprecating it.
>
> I would then look at "power":"marker" and be very concerned to see 35,288
>> tags. That's a very strong existing usage. You might be lucky that power
>> markers aren't as useful to render as power lines, etc.
>> https://openinframap.org/#12.2/49.49246/0.21175
>>
> I don't get the right term here. I see only 222 items for power=marker and
> nothing for power:marker=*
> Which one are you refering to with 35k uses please?
>
> One of the goals is precisely to get a comprehensive render with marker=*
> for many kind of markers, not only pipeline ones.
>
> Le ven. 6 sept. 2019 à 12:20, Martin Koppenhoefer 
> a écrit :
>
>> I would rather have expected a generic description of the marker, like
>> marker=
>> post
>> cone
>> sign
>> ...
>> aerial_marker (maybe this should be a property, not a type? This seems to
>> be a quite interesting property for our context)
>>
>
> Ok this one is really interesting.
> Why not using marker=* to give its nature and another key utility=* with
> values "gas", "power", "telecom", "water"... ?
> Seems it is already used:
> https://taginfo.openstreetmap.org/keys/utility#values
>
> marker=* + utility=* give a "utility marker", right?
>
> All the best
>
> François
>

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

Re: [Tagging] Turn lanes separated by road markings

[Paul Johnson]

On Fri, Sep 6, 2019 at 2:14 PM Markus  wrote:

> Hello everyone
>
> I'm unsure how to map the following situation:
>
> There are two lanes approaching a roundabout, both with different
> destinations. The lanes are divided by a solid line (and later a panted
> triangle with chevrons) for about 100 m before they are separated
> physically:
>
> https://www.openstreetmap.org/way/430073056
>
> Do we have a relation for storing the information that the left lane
> continues on [way 394112487](https://www.openstreetmap.org/way/394112487)
> and the right lane on [way 290130794](
> https://www.openstreetmap.org/way/290130794)? This information is
> important in order that routers don't announce too late (i.e. when the
> lanes can't be changed anymore) which lane one has to take.
>
> Or is turn:lanes + change:lanes enough? (And what if there were no turn
> lane markings?)
>

Consider putting the split at the theoretical gore and making the right
turn sliproad placement=transition from the theoretical gore to the
bullnose.  Example: https://www.openstreetmap.org/way/397356496
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Mapping specifically every traffic signal

[yo paseopor]

Hi!

Mapping Barcelona in a more specific way (we have the authorization to use
Townhall's Barcelona OpenData, we have one project to import Spain Cadastre
buildings and portals, etc.) we have realized we need a more accurate way
to map the traffic signals.

Now we have three kinds of these artifacts:

-Car/Truck traffic signals. With two or more traffic signals (normally we
have one at the side and one above the road).
-Bicycle traffic signals. As a city with more than one hundred kilometers
of cycleways Barcelona is well-know for the tries of the Townhall to be
bike-friendly.
-Pedestrian traffic signals. With a position perpendicular to car traffic
signal is important because of accessibility data (it can buzz, it can
flash, it can count...)

I think the best way to do this is using well-know vehicle access tags, and
also the most advanced scheme to tag directions and sides.
The position of the nodes will be the same as now, on the way it affects
little before the crossing.
For these reasons I propose new way to tag all these kinds of traffic
signals as it follows in every way you have affected by one of these.

car,truck... traffic signal:

highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=motor_vehicle
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above side=right or left (it depends of the location of the pole
relative to the way it is )

bike traffic signal:
highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=bicycle
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above ,right or left (it depends of the location of the pole relative
to the way it is )

pedestrian traffic signal:
highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=foot
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above ,right or left (it depends of the location of the pole relative
to the way it is )

horse traffic signal:
highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=horse
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above ,right or left (it depends of the location of the pole relative
to the way it is )

then you will complement all of this with another node being the crossing
with every road, in the place we do now.

Traffic signals are so important we need a good  specific scheme to do a
good and specific mapping

What do you think about that?

Salut i mapes (Health and maps)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Utility markers

[François Lacombe]

Hi all,

Thank you for yout contributions

Le ven. 6 sept. 2019 à 09:13, Joseph Eisenberg 
a écrit :

> I'm still opposed to this proposal:
>

Answers provided at
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Utility_markers_proposal#Oppose_deprecating_pipeline.3Dmarker_and_marker.3Dstone

Le ven. 6 sept. 2019 à 09:18, Jez Nicholson  a
écrit :

> Arriving fresh to a proposal, my first action would be to look at what is
> currently in OSM. There are 6,043 "marker"="stone", which is 81.5% of the
> usage of "marker" in OSM. I would expect the proposal to support current
> usage.
>
I respectably disagree on that point.
Biggest problem is that current usage isn't documented, and may not have
been reviewed like we are doing right now.

This proposal aims to define values for marker=* to describe utility
markers.
Despite marker=stone may be unconsistent with what is proposed, it doesn't
make it incompatible and this proposal only notices this fact without
thinking of deprecating it.

I would then look at "power":"marker" and be very concerned to see 35,288
> tags. That's a very strong existing usage. You might be lucky that power
> markers aren't as useful to render as power lines, etc.
> https://openinframap.org/#12.2/49.49246/0.21175
>
I don't get the right term here. I see only 222 items for power=marker and
nothing for power:marker=*
Which one are you refering to with 35k uses please?

One of the goals is precisely to get a comprehensive render with marker=*
for many kind of markers, not only pipeline ones.

Le ven. 6 sept. 2019 à 12:20, Martin Koppenhoefer 
a écrit :

> I would rather have expected a generic description of the marker, like
> marker=
> post
> cone
> sign
> ...
> aerial_marker (maybe this should be a property, not a type? This seems to
> be a quite interesting property for our context)
>

Ok this one is really interesting.
Why not using marker=* to give its nature and another key utility=* with
values "gas", "power", "telecom", "water"... ?
Seems it is already used:
https://taginfo.openstreetmap.org/keys/utility#values

marker=* + utility=* give a "utility marker", right?

All the best

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

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

[Martin Koppenhoefer]

sent from a phone

> On 6. Sep 2019, at 13:47, Chris Hill  wrote:
> 
> To me a sports centre is a place that's dedicated to sport in its own space 
> or grounds. It may have outdoor pitches,courts etc as well as indoor 
> provisions. I think it could have a gym, i.e. a space with gym equipment too.
> 
> A sports hall, to me, is a building in an environment that is not wholly 
> about sports,so a building in school grounds or in a business complex. It has 
> more than just a gym room.
> 


+1, this is exactly how I see it as well 

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

Re: [Tagging] Turn lanes separated by road markings

[Jan Michel]

Hi Markus,

On 06.09.19 21:07, Markus wrote:

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

Do we have a relation for storing the information that the left lane 
continues on [way 
394112487](https://www.openstreetmap.org/way/394112487) and the right 
lane on [way 290130794](https://www.openstreetmap.org/way/290130794)? 
This information is important in order that routers don't announce too 
late (i.e. when the lanes can't be changed anymore) which lane one has 
to take.

We do have a (recently approved) relation type for this: 'connectivity':
https://wiki.openstreetmap.org/wiki/Relation:connectivity

Or is turn:lanes + change:lanes enough? (And what if there were no turn 
lane markings?)
In this case with a simple 2-lane way splitting into 2 1-lane ways I 
would not use this relation - it should be obvious to all routing tools 
how these ways relate to each other. The example looks more complicated 
than it actually is, because some ways are oneways and some are not. For 
routing purposes, the lanes in each direction can be treated separately 
from each other.



Jan


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

Re: [Tagging] Feature Proposal - RFC - sunbathing

[Richard]

On Tue, Sep 03, 2019 at 07:52:38AM +1000, Warin wrote:
> In Australia most people 'sunbathe' on a beach of sand. Some 'sunbathe' in
> their own backyard. High rates of sun exposure gets 'melanoma' and there are
> publicity campaigns to get people to cover up from sun exposure.

wildy offtopic so I bite my tongue to reply to that. 

Richard

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

Re: [Tagging] Turn lanes separated by road markings

[Leif Rasmussen]

I see two good options:
1) Split the two lanes into two ways where they first split apart (but
aren't yet physically divided).  This doesn't follow the "physical divider"
rule, but since the road markings are acting as a physical divider, and
they are much more than just a line, an exception to that rule seems fine.
2) Just pretend that the road markings are like any other line and tag
change:lanes instead of two separate ways.  Then, you could use a new tag
like "width:dividers:backward=3" to mark that the lane divider is 3 meters
wide.

I would probably just go with the first one for now, since it's a bit
difficult to physically cross that lane divider with a vehicle and the lane
splits off anyway.

...

I've been considering starting a proposal for mapping the widths of lane
dividers recently, since there are many cases where they aren't just
lines.  Perhaps some tag like "width:dividers=0|0|4" or similar could work,
where each number represents a divider between two lanes (that example
would be for a one way road with 4 lanes, the right of which is separated
by a 4 meter lane divider).
What do people think of a new tag like this?  I personally think something
other than "|" should be used for dividers, so am looking for a better
syntax.  If people like the idea, I would be happy to start a new proposal.

Leif Rasmussen

On Fri, Sep 6, 2019 at 3:15 PM Markus  wrote:

> Hello everyone
>
> I'm unsure how to map the following situation:
>
> There are two lanes approaching a roundabout, both with different
> destinations. The lanes are divided by a solid line (and later a panted
> triangle with chevrons) for about 100 m before they are separated
> physically:
>
> https://www.openstreetmap.org/way/430073056
>
> Do we have a relation for storing the information that the left lane
> continues on [way 394112487](https://www.openstreetmap.org/way/394112487)
> and the right lane on [way 290130794](
> https://www.openstreetmap.org/way/290130794)? This information is
> important in order that routers don't announce too late (i.e. when the
> lanes can't be changed anymore) which lane one has to take.
>
> Or is turn:lanes + change:lanes enough? (And what if there were no turn
> lane markings?)
>
> Thanks in advance for your help
>
> Regards
>
> Markus
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Using destination_sign relations for pedestrian navigation

[Jan Michel]

Hi Antoine,

I think your suggestions are all valid, but it seems some make tagging 
and using data more complicated than necessary.



On 05.09.19 09:29, Antoine Riche via Tagging wrote:
In order to improve the user experience, we want to provide walking 
instructions such as "take the exit 'Rue de Londres'" or "Walk through 
the gate labelled 'Northern lines'" rather than "Walk 75 metres then 
turn left". Our problem is that such waypoints may have a different name 
depending on the direction you cross them. The solution we used is to 
create, when there is such an ambiguity, two destination_sign relations 
pointing to the same 'intersection' member, one for each direction with 
the 'from' and 'to' members swapped. Here is an example at Juvisy 
station : the entrance named 'Accès Danton' when walking in 
(https://www.osm.org/relation/9471596) is named 'Quartier Seine' when 
walking out (https://www.osm.org/relation/9471597).
That's correct and how it's done usually. In such a simple case, the 
same information can also be added to the way passing through the 
entrance using the tags 'destination:forward' and 
'destination:backward'. I think this carries all the information you 
need for the routing. The additional information the relation is able to 
handle (location of the sign, colours etc.) are not needed here. Adding 
tags to a (short) way is much less effort and serves the purpose very 
well here. In addition, the 'destination' tag is already used by some 
routing tools.



I wish to amend the Wiki to explain that destination_sign relations can 
also be used for pedestrian and indoor routing, not just at 
"crossroads". Does that require opening a discussion in the discussion 
page, or may I just go ahead ?


A huge amount of these relations are already used on paths like hiking 
trails, so this tagging scheme is definitely not limited to road signs. 
So there is no redefinition needed, maybe the description needs to be 
refined a bit.



Now since the routing engine supports area routing, we need to loosen 
some constraints on the members, that are documented on the wiki and 
enforced by the JOSM validator :
1/ allow areas for the 'from' and 'to' members, as in this example : 
https://www.osm.org/relation/9722912
This seems to be fine - you have to note that many data users (me 
included) are not actually able to handle areas well with respect to 
routing.


2/ allow multiple 'intersection' members, so that multiple doors can be 
referenced by a single relation – example in Gare Montparnasse : 
https://www.osm.org/relation/9823029
This looks fine to me - but the destinations should be tagged using 
'destination' and not using 'name' - that would be the name of the sign 
(which is unlikely to exist).


3/ allow multiple 'to' members, so that the same relation can point to 
both a line and an area, and cover linear and area routing (no example 
but I could create one).
In my opinion, the area should not be included here. The 'to' member of 
the relation is not meant to be the final destination, but just a way or 
node you need to pass through to get to your destination. That would be 
a node directly after the 'intersection'. Having both makes it difficult 
for the data user to find which one is the correct one in the current 
context. The decision might not always be as simple as 'area' vs. 'way'.



FYI, I'm working a bit on displaying destination signs, mostly in the 
context of hiking guideposts, but yours can be displayed as well, e.g.

http://osm.janmichel.eu/destinationsign/example/index.htm#zoom=18=48.993567=2.2349=6079938675
This is currently very much "work in progress" and far from being 
finalized, but you might find it helpful.




Are there objections to this proposal ? Do you recommend to open this 
subject on the Discussion page or is it best discussing it on this list ?


Regards,
Antoine.



Jan


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

[Tagging] Turn lanes separated by road markings

[Markus]

Hello everyone

I'm unsure how to map the following situation:

There are two lanes approaching a roundabout, both with different
destinations. The lanes are divided by a solid line (and later a panted
triangle with chevrons) for about 100 m before they are separated
physically:

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

Do we have a relation for storing the information that the left lane
continues on [way 394112487](https://www.openstreetmap.org/way/394112487)
and the right lane on [way 290130794](
https://www.openstreetmap.org/way/290130794)? This information is important
in order that routers don't announce too late (i.e. when the lanes can't be
changed anymore) which lane one has to take.

Or is turn:lanes + change:lanes enough? (And what if there were no turn
lane markings?)

Thanks in advance for your help

Regards

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

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

[Steve Doerr]

My UK school had both a gym and a sports hall. And neither was used for 
the morning assembly: there was a main hall (with a stage) for that, 
which was also used for serving school dinners at lunchtime.


Steve


On 05/09/2019 16:21, Philip Barnes wrote:

In terms of schools, we call them gyms in the UK too.

Certainly not sports halls.

Phil (trigpoint)

On Thursday, 5 September 2019, Joseph Eisenberg wrote:

What is a sports hall?

Is it what we call a "gym" in America?

The dictionary definition I found just said it was "a building used
for sports", and the wiki page only says it's a building or part of a
building "used as a sports hall", which doesn't do anything to clarify
the situation.

I don't see how that is different than the definition of
sports_centre: "a distinct facility where sports take place within an
enclosed area" - which then specifically mentions "it can be a
building".

I'll admit that we don't use the term "sports centre" in the USA
either, but at least the wiki definition is clearly vague: it's any
enclosed area (including buildings) where sports take place.

On 9/5/19, Tom Pfeifer  wrote:

On 05.09.2019 15:48, Joseph Eisenberg wrote:

Another user would like the proposed tag (used 329 times)

346 if you count all tags. Look at taghistory and see it has grown from 22
in early 2018, thus about
15 times.

It was a result of discussion in some communities that time.


leisure=sports_hall to be added to leisure=sports_centre.

No. You cannot add the value to the same key.

The intention of leisure=sports_hall is to describe facilities better that
were incorrectly tagged
leisure=sports_centre, an example are simple school sport halls, which
certainly are not 'centres'.



However, I believe that rarely used, proposed tags should be approved
through the proposal process or should become commonly used
organically, before being added to the pages of common tags and keys.

If you look at the history, it is being growing organically.
A hint to consider a more suitable tag on the centre page tagging cannot
hurt.


So, this can be a synonym for a sports_centre, or a tag for a building
found in a sports_centre?

More precisely, leisure=sports_hall is for facilities that are not centres.
Surely a centre can hold, among other facilities to form a centre, one or
more halls.


Why not just use building=sports_hall and sports_centre for the whole
area?

Because building=* describes the building typology, not the usage. leisure=*
describes the usage.
Thus, a purpose-built sports hall is
leisure=sports_hall+building=sports_hall, while a converted
church that is now used for sports is leisure=sports_hall+building=church.

tom

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


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




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Tagging] Using destination_sign relations for pedestrian navigation

[Antoine Riche via Tagging]

Thank for your reponses so far. Any views on loosening the constraints 
on member types and cardinalities ?


Le 05/09/2019 à 19:33, yo paseopor a écrit :

Using established is the best way, but look at this, it could be useful
https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging#Destination_signs

It covers all kind of traffic signs, also destination traffic signs, 
so it would be useful for a pedestrian destination traffic sign 
description and your routing subject.


Salut i mapes (Health and maps)
yopaseopor


On Thu, Sep 5, 2019 at 9:31 AM Antoine Riche via Tagging 
mailto:tagging@openstreetmap.org>> wrote:


Hello.

We are working with SNCF, the french railway company, to provide
pedestrian navigation inside and around railway stations in the
Greater Paris area. A dedicated routing engine, which provides
indoor/outdoor navigation and supports area routing, has been
developed – this will be presented during SOTM in Heidelberg.

In order to improve the user experience, we want to provide
walking instructions such as "take the exit 'Rue de Londres'" or
"Walk through the gate labelled 'Northern lines'" rather than
"Walk 75 metres then turn left". Our problem is that such
waypoints may have a different name depending on the direction you
cross them. The solution we used is to create, when there is such
an ambiguity, two destination_sign relations pointing to the same
'intersection' member, one for each direction with the 'from' and
'to' members swapped. Here is an example at Juvisy station : the
entrance named 'Accès Danton' when walking in
(https://www.osm.org/relation/9471596) is named 'Quartier Seine'
when walking out (https://www.osm.org/relation/9471597).

I wish to amend the Wiki to explain that destination_sign
relations can also be used for pedestrian and indoor routing, not
just at "crossroads". Does that require opening a discussion in
the discussion page, or may I just go ahead ?

Now since the routing engine supports area routing, we need to
loosen some constraints on the members, that are documented on the
wiki and enforced by the JOSM validator :
1/ allow areas for the 'from' and 'to' members, as in this example
: https://www.osm.org/relation/9722912
2/ allow multiple 'intersection' members, so that multiple doors
can be referenced by a single relation – example in Gare
Montparnasse : https://www.osm.org/relation/9823029
3/ allow multiple 'to' members, so that the same relation can
point to both a line and an area, and cover linear and area
routing (no example but I could create one).

Are there objections to this proposal ? Do you recommend to open
this subject on the Discussion page or is it best discussing it on
this list ?

Regards,
Antoine.

___
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] Tag for a milk_shake shop?

[ael]

On Fri, Sep 06, 2019 at 03:21:59PM +1000, Andrew Harvey wrote:
> I'd tag it as amenity=cafe, even without selling coffee I still think it
> fits into https://wiki.openstreetmap.org/wiki/Tag:amenity=cafe, just with a
> cuisine tag to specify milk_shakes are the main cuisine.

Well, after all the suggestions, I have ended up with a surfeit of tags!
amenity=cafe
cuisine=milk_shake
shop=beverages
drink=milk_shake

and perhaps the drink needs adjusting, or perhaps not.

If forced to choose, I would remove the shop part: it seems nearer to a
cafe'.

ael


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

[Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

Last year there was a little discussion about unique wikidata ids in the
openstreetmap database:
https://lists.openstreetmap.org/pipermail/tagging/2018-August/038249.html

It was more or less decided there was no problem with this. Nevertheless, I
think we should consider having a hard rule of "*A Wikidata item cannot be
connected to more than one OSM item*".

Problems with not enforcing this rule:

- the problem of a partially downloaded database, where one is never sure
if a wikidata item is fully downloaded unless the whole database is
downloaded.

- we could get a flood of wikidata tags where one would, for example, tag
every building in a town with the wikidata id of the town, because that
building is a part of the town. Is that wrong tagging? Well, if the above
rule is not in place, I'm not sure.

- if a road segment has two road routes that are using it, then we should
tag it as "wikidata=Q1234;Q5678". That means, if we want to find any
wikidata id, we should be prepared to parse all wikidata tags and be
prepared for semicolons. This slows down any wikidata searches

- we can't enforce some rules like "tag leisure=stadium can only be
connected to something that is, or is derived from Q483110 (Stadium) in
Wikidata" because, if we tag all the parts of an entity, we can also tag a
water fountain in the stadium, because that is a part of it.

So I propose we enforce this rule, and we tag, for example, railways only
on the route relation.

If one wants to tag all route segments with a wikidata tag, I propose a
general usage "*part:wikidata=**" which would be used when a single
wikidata tag just isn't viable. Proposal wiki page here:

https://wiki.openstreetmap.org/wiki/Proposed_features/part:wikidata

Thanks for reading,
Janko Mihelić
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

[Joseph Eisenberg]

Re: "A sports hall, to me, is a building in an environment that is not
wholly about sports,so a building in school grounds or in a business
complex."

That's a useful definition.

Can anyone confirm if this is how it's being used? I believe most of
the original discussion was about features in Germany (Sporthallen?) -
I think these are the same as a school Gymnasium in the USA, but I'm
not sure.

I'm just concerned that with the current lack of definition on the
wiki page, people will start using it for features that are normally
tagged as sports centres in a single building, like a dedicated futsal
centre in Brazil or an indoor tennis centre in Indonesia, where words
like "sports hall" and "sports centre" may have no clear translation
into the local language.

- Joseph Eisenberg

On 9/6/19, Chris Hill  wrote:
> On 05/09/2019 23:29, Graeme Fitzpatrick wrote:
>>
>> On Fri, 6 Sep 2019 at 03:08, Chris Hill > > wrote:
>>
>> It's a sports hall I think because it is marked out for various
>> indoor sports,e.g. badminton, volley ball,
>> 5-a-side football etc, with curtains or nets to separate courts when
>> needed.
>>
>>
>> Thanks, Chris, that's what I was remembering from schools in
>> Australia, but they weren't called a sports hall - usually Assembly
>> Hall, as that's where the School assembles to be addressed by the
>> principal.
>>
>> Wouldn't that description still match the definition that Joseph
>> quoted above though - "sports_centre: "a distinct facility where
>> sports take place within an enclosed area" - which then specifically
>> mentions "it can be a building"."?
>>
>>
> To me a sports centre is a place that's dedicated to sport in its own
> space or grounds. It may have outdoor pitches,courts etc as well as
> indoor provisions. I think it could have a gym, i.e. a space with gym
> equipment too.
>
> A sports hall, to me, is a building in an environment that is not wholly
> about sports,so a building in school grounds or in a business complex.
> It has more than just a gym room.
>
> This is just my interpretation and I don't think agonising over precise
> meanings is that useful. I am, however strongly against homogenising the
> database. If someone describes a place as a sports hall I am strongly
> against someone overwriting that as a sports centre when they have no
> local knowledge, but just want to impose a structure to the data that
> doesn't actually exist. We are describing the real world which is messy,
> has contradictions and inconsistencies and which we will never ever get
> right with homogenous lists and restrictions. I say there as sports
> halls and sports centres and there is easily room for both.
>
> --
> cheers
> Chris Hill (chillly)
>
>

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

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

[Chris Hill]

On 05/09/2019 23:29, Graeme Fitzpatrick wrote:


On Fri, 6 Sep 2019 at 03:08, Chris Hill > wrote:


It's a sports hall I think because it is marked out for various
indoor sports,e.g. badminton, volley ball,
5-a-side football etc, with curtains or nets to separate courts when
needed.


Thanks, Chris, that's what I was remembering from schools in 
Australia, but they weren't called a sports hall - usually Assembly 
Hall, as that's where the School assembles to be addressed by the 
principal.


Wouldn't that description still match the definition that Joseph 
quoted above though - "sports_centre: "a distinct facility where 
sports take place within an enclosed area" - which then specifically 
mentions "it can be a building"."?



To me a sports centre is a place that's dedicated to sport in its own 
space or grounds. It may have outdoor pitches,courts etc as well as 
indoor provisions. I think it could have a gym, i.e. a space with gym 
equipment too.


A sports hall, to me, is a building in an environment that is not wholly 
about sports,so a building in school grounds or in a business complex. 
It has more than just a gym room.


This is just my interpretation and I don't think agonising over precise 
meanings is that useful. I am, however strongly against homogenising the 
database. If someone describes a place as a sports hall I am strongly 
against someone overwriting that as a sports centre when they have no 
local knowledge, but just want to impose a structure to the data that 
doesn't actually exist. We are describing the real world which is messy, 
has contradictions and inconsistencies and which we will never ever get 
right with homogenous lists and restrictions. I say there as sports 
halls and sports centres and there is easily room for both.


--
cheers
Chris Hill (chillly)

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

Re: [Tagging] Feature proposal - RFC - Utility markers

[Martin Koppenhoefer]

Actually I just found out, placement also exists, but for a different
purpose:
https://wiki.openstreetmap.org/wiki/Key%3Aplacement

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

Re: [Tagging] Feature proposal - RFC - Utility markers

[marc marc]

Le 06.09.19 à 12:17, Martin Koppenhoefer a écrit :
> placement(?)=soil / street

location seems better and already exist
https://wiki.openstreetmap.org/wiki/Key%3Alocation
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Utility markers

[Martin Koppenhoefer]

I agree with your definition for marker:
marker= The node corresponds to a marker seen on ground

but then the actual values that you propose do not (or only implicitly)
refer to the marker but to the "thing" the marker refers to:

"pipeline" - Indicate that a pipeline is buried next to the marker,
possibly underground and not mandatorly righly below

"power_cable" - A power cable is installed next to the marker, possibly
underground and not mandatorly righly below

"telecom_cable" - A telecommunication cable is installed next to the
marker, possibly underground and not mandatorly righly below

"fire_hydrant" - A fire hydrant is available next to the marker, possibily
underground and not mandatorly rightly below



I would rather have expected a generic description of the marker, like
marker=
post
cone
sign
...
aerial_marker (maybe this should be a property, not a type? This seems to
be a quite interesting property for our context)

properties which might be useful for markers:
dome_marker=yes/no (or: marker_top=flat/dome/...)
placement(?)=soil / street


If this is for a _utility_ marker only, you should consider using a more
specific key name like "utility_marker". I could imagine defining a generic
"marker" tag for utility markers but including also other markers, which
may be similar by their physical appearance, although for many of them,
e.g. survey points, milestones and boundary markers, we already have
established different tagging and will likely not change this.

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

Re: [Tagging] Feature proposal - RFC - Utility markers

[Jez Nicholson]

Arriving fresh to a proposal, my first action would be to look at what is
currently in OSM. There are 6,043 "marker"="stone", which is 81.5% of the
usage of "marker" in OSM. I would expect the proposal to support current
usage.

I would then look at "power":"marker" and be very concerned to see 35,288
tags. That's a very strong existing usage. You might be lucky that power
markers aren't as useful to render as power lines, etc.
https://openinframap.org/#12.2/49.49246/0.21175

On Fri, Sep 6, 2019 at 8:13 AM Joseph Eisenberg 
wrote:

> I'm still opposed to this proposal:
>
> This proposal is quite long and complicated-looking. I believe it
> would be better to clarify exactly what tags are new: for example,
> "support", "material" etc are existing tags, not new tags. Please
> update the "Proposal" section at the top to clearly state the tags
> that would be added, and the tags that would be deprecated.
>
> I believe there are 2 tags that are being deprecated: pipeline=marker
> and marker=stone. I don't see the benefit in moving the first from the
> pipeline=* key, where it's really clear that "this is a marker for a
> pipeline" to a new marker key, where the values will be mixed between
> power, communications, pipeline and fire hydrand features (and
> possibly others in the future).
>
> I also think that it's not reasonable to deprecate marker=stone
> without clearly discussing what tag is supposed to replace it.
> According to taginfo, almost all uses of marker=stone are combined
> with boundary=marker, so these are boundary marker stones, "a robust
> physical marker that identifies the start of a land boundary or the
> change in a boundary, especially a change in direction of a boundary."
>
> - Joseph Eisenberg
>
> On 9/6/19, François Lacombe  wrote:
> > Hi all
> >
> > The proposal to introduce marker=* key for all kind of utility markers is
> > about to be voted.
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal
> >
> > All previous comments have been solved and any new one will be welcome.
> >
> > Currently, more than 6k object are described with undocumented
> marker=stone
> > which conflicts a bit with proposed marker classification.
> > As those are mainly (to be determined on each situation) highway
> milestones
> > or private ground limits, they're not covered by this proposal
> > A suggestion would to define marker=milestone or marker=land_limit +
> > support=pedestal + material=stone.
> >
> > All the best
> >
> > François
> >
> > Le ven. 19 juil. 2019 à 21:22, François Lacombe <
> fl.infosrese...@gmail.com>
> > a écrit :
> >
> >> Hi Jospeh
> >>
> >> This proposal is an attempt to bring consistency in markers mapping, in
> >> two ways :
> >> - Provide a common concept to tag them all.
> >> - Free pipeline=* from some features unrelated directly to pipeline
> >> operation.
> >>
> >> Second point should encourage a mapping good practice I didn't have in
> >> mind in previous pipeline mapping evolutions : the marker shouldn't be
> >> part
> >> of the pipeline way directly as it warns about the presence of pipelines
> >> in
> >> a given range or distances.
> >> Just like road signs should get their own node beside the road instead
> of
> >> be part the highway way.
> >> To me yes, we should encourage to use marker=pipeline instead of
> >> pipeline=marker prior to the last gets *really* used.
> >> 29k features is less than the whole amount of pipeline markers we have
> to
> >> find in France (which is a small area).
> >>
> >> All the best
> >>
> >> François
> >>
> >> Le jeu. 18 juil. 2019 à 06:07, Joseph Eisenberg <
> >> joseph.eisenb...@gmail.com> a écrit :
> >>
> >>> It looks like the main effect of this proposal would be to replace
> >>> pipeline=marker (used 29k times) with marker=pipeline, though the new
> >>> key
> >>> marker= could also be used for power cables and telecommunications
> >>> cables.
> >>>
> >>> Is it really necessary to change pipeline=marker?
> >>>
> >>> -Joseph
> >>>
> >>> On Sun, Jul 14, 2019 at 11:10 PM François Lacombe <
> >>> fl.infosrese...@gmail.com> wrote:
> >>>
>  Hi all,
> 
>  Here is another proposal we were two working on it.
>  It regards several kinds of utility markers usually warning about
>  buried
>  infrastructure beneath them.
> 
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal
> 
>  Markers are currently described with keys like pipeline=* and power=*
>  although they're not directly involved in infrastructure running
>  processes
>  (like a valve can be on a pipeline for instance).
>  Then it can be useful to define a new key marker=* to gather more
>  categories on OSM (pipeline is for now the most mapped here) and
>  prevent
>  pipeline, power and telecom keys be cluttered with not directly
> related
>  features.
> 
>  Note that markers mapping is important on OSM as location signs and
>  relevant data 

Re: [Tagging] Feature proposal - RFC - Utility markers

[Joseph Eisenberg]

I'm still opposed to this proposal:

This proposal is quite long and complicated-looking. I believe it
would be better to clarify exactly what tags are new: for example,
"support", "material" etc are existing tags, not new tags. Please
update the "Proposal" section at the top to clearly state the tags
that would be added, and the tags that would be deprecated.

I believe there are 2 tags that are being deprecated: pipeline=marker
and marker=stone. I don't see the benefit in moving the first from the
pipeline=* key, where it's really clear that "this is a marker for a
pipeline" to a new marker key, where the values will be mixed between
power, communications, pipeline and fire hydrand features (and
possibly others in the future).

I also think that it's not reasonable to deprecate marker=stone
without clearly discussing what tag is supposed to replace it.
According to taginfo, almost all uses of marker=stone are combined
with boundary=marker, so these are boundary marker stones, "a robust
physical marker that identifies the start of a land boundary or the
change in a boundary, especially a change in direction of a boundary."

- Joseph Eisenberg

On 9/6/19, François Lacombe  wrote:
> Hi all
>
> The proposal to introduce marker=* key for all kind of utility markers is
> about to be voted.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal
>
> All previous comments have been solved and any new one will be welcome.
>
> Currently, more than 6k object are described with undocumented marker=stone
> which conflicts a bit with proposed marker classification.
> As those are mainly (to be determined on each situation) highway milestones
> or private ground limits, they're not covered by this proposal
> A suggestion would to define marker=milestone or marker=land_limit +
> support=pedestal + material=stone.
>
> All the best
>
> François
>
> Le ven. 19 juil. 2019 à 21:22, François Lacombe 
> a écrit :
>
>> Hi Jospeh
>>
>> This proposal is an attempt to bring consistency in markers mapping, in
>> two ways :
>> - Provide a common concept to tag them all.
>> - Free pipeline=* from some features unrelated directly to pipeline
>> operation.
>>
>> Second point should encourage a mapping good practice I didn't have in
>> mind in previous pipeline mapping evolutions : the marker shouldn't be
>> part
>> of the pipeline way directly as it warns about the presence of pipelines
>> in
>> a given range or distances.
>> Just like road signs should get their own node beside the road instead of
>> be part the highway way.
>> To me yes, we should encourage to use marker=pipeline instead of
>> pipeline=marker prior to the last gets *really* used.
>> 29k features is less than the whole amount of pipeline markers we have to
>> find in France (which is a small area).
>>
>> All the best
>>
>> François
>>
>> Le jeu. 18 juil. 2019 à 06:07, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> a écrit :
>>
>>> It looks like the main effect of this proposal would be to replace
>>> pipeline=marker (used 29k times) with marker=pipeline, though the new
>>> key
>>> marker= could also be used for power cables and telecommunications
>>> cables.
>>>
>>> Is it really necessary to change pipeline=marker?
>>>
>>> -Joseph
>>>
>>> On Sun, Jul 14, 2019 at 11:10 PM François Lacombe <
>>> fl.infosrese...@gmail.com> wrote:
>>>
 Hi all,

 Here is another proposal we were two working on it.
 It regards several kinds of utility markers usually warning about
 buried
 infrastructure beneath them.

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

 Markers are currently described with keys like pipeline=* and power=*
 although they're not directly involved in infrastructure running
 processes
 (like a valve can be on a pipeline for instance).
 Then it can be useful to define a new key marker=* to gather more
 categories on OSM (pipeline is for now the most mapped here) and
 prevent
 pipeline, power and telecom keys be cluttered with not directly related
 features.

 Note that markers mapping is important on OSM as location signs and
 relevant data to verify presence of not visible infrastructures.

 Feel free to raise concerns here and on talk page.

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

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