Re: [Tagging] Why should we avoid overusage of amenity=* tag?

[石野貴之]

Thank you for the reply.

> These difficulties, and opposing ideas on how to deal with existing tags,
make it hard to change established tagging schemes. But I am strongly in
favour of not establishing new amenity=* for hitherto unmapped facilites,
but rather use new tags altogether, whose use can then be expanded into
proper tagging schemes.

I support your idea using new tags altogether with existing tags.
Then, how about the following examples? Do you think them good ideas?

 (a) *office=educational_institution* and *education=cram-school* for
Japanese *juku*s aimed for entrance examinations.

 (b) *shop=computer* and *education=specialty* if a computer shop provides
a workshop to learn how to use computers.

Takayuki Ishino
yumean1...@gmail.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting results - Police facilites

[Graeme Fitzpatrick]

Sorry to see that it missed out Jan :-(

As Joseph suggests, maybe take out the country specific & try again?

On Tue, 23 Apr 2019 at 11:22, Joseph Eisenberg 
wrote:

> It looks like several critical comments mentioned that the country
> specific tagging (eg police:FR=*) was not good.
>

Just for interest's sake, in regard to that - is there any form of
"European Police" across the EU, or is all law-enforcement still strictly
under each countries control? There is an EU military force of some sort,
isn't there?

Thanks

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

Re: [Tagging] Feature Proposal - Voting results - Police facilites

[Joseph Eisenberg]

That’s very close. I suppose it would have been approved with one more vote.

It looks like several critical comments mentioned that the country specific
tagging (eg police:FR=*) was not good.

I would suggest just removing these from being mentioned in the proposal.
Perhaps we can try talking to the French community about how their need can
be met with the more general tags in the proposal?

Joseph

On Tue, Apr 23, 2019 at 5:23 AM Jan S  wrote:

> The voting period for the refined police facilities proposal (
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Police_facilites)
> has ended. The proposal has been rejected by 8 approvals against 3
> rejections (72.7% approval).
>
> Best,
> Jan
> ___
> 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] Walking Routes, how to tag alternatives/additions/shortcuts/approach tracks etc.

[Warin]

The 'Great North Walk' https://www.openstreetmap.org/relation/1388126

has - the ways that form the route ... and
3 relations with the roles 'alternate' that form alternative paths .. 
one of them is a closed section that was the original path but is in 
conflict with a shooting range.




On 23/04/19 08:04, Joseph Eisenberg wrote:

Do you have a link to an example?

I’m reminded of the Oregon Coast bicycle route, which has alternative 
section s that leave the main highway to follow a scenic but longer 
road through the hills or closer to the coast. There are also 
alternatives that follow a Main Street (high street) through a village.


See pdf of route:
https://www.oregon.gov/odot/programs/tdd%20documents/oregon-coast-bike-route-map.pdf

My first thought is something like role=side_route for an
alternative which leads the main route but then rejoins. This is 
similar to side_stream in waterway relations.


Perhaps approach or entrance segments could be tagged role=link - 
echoing highways tagging? But that might imply a connection to another 
route.


Joseph

On Tue, Apr 23, 2019 at 6:49 AM Peter Elderson > wrote:


Long walking routes often have a main route and several additions
of various types. If these additions are not waymarked, they are
not recorded in OSM. Easy.

But often, they are. On maps these are usually shown as a striped
line, while the main route is usually a continuous line.

I would like to enable OSMrenderers and data users to
render/process the additions/alternatives differently than the
main route.

One solution just for rendering would be to optionally add
"striped" to the colour tag. Or dotted.

A more general solution would be something like alternative=yes,
additional=yes, approach=yes. A tag that covers all the variants,
I can't think of a suitable word.
the other way around: main_route=no?



Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging



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



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

Re: [Tagging] Walking Routes, how to tag alternatives/additions/shortcuts/approach tracks etc.

[Joseph Eisenberg]

Do you have a link to an example?

I’m reminded of the Oregon Coast bicycle route, which has alternative
section s that leave the main highway to follow a scenic but longer road
through the hills or closer to the coast. There are also alternatives that
follow a Main Street (high street) through a village.

See pdf of route:
https://www.oregon.gov/odot/programs/tdd%20documents/oregon-coast-bike-route-map.pdf

My first thought is something like role=side_route for an
alternative which leads the main route but then rejoins. This is similar to
side_stream in waterway relations.

Perhaps approach or entrance segments could be tagged role=link - echoing
highways tagging? But that might imply a connection to another route.

Joseph

On Tue, Apr 23, 2019 at 6:49 AM Peter Elderson  wrote:

> Long walking routes often have a main route and several additions of
> various types. If these additions are not waymarked, they are not recorded
> in OSM. Easy.
>
> But often, they are. On maps these are usually shown as a striped line,
> while the main route is usually a continuous line.
>
> I would like to enable OSMrenderers and data users to render/process the
> additions/alternatives differently than the main route.
>
> One solution just for rendering would be to optionally add "striped" to
> the colour tag. Or dotted.
>
> A more general solution would be something like alternative=yes,
> additional=yes, approach=yes. A tag that covers all the variants, I can't
> think of a suitable word.
> the other way around: main_route=no?
>
>
>
> Vr gr Peter Elderson
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Walking Routes, how to tag alternatives/additions/shortcuts/approach tracks etc.

[Peter Elderson]

Long walking routes often have a main route and several additions of
various types. If these additions are not waymarked, they are not recorded
in OSM. Easy.

But often, they are. On maps these are usually shown as a striped line,
while the main route is usually a continuous line.

I would like to enable OSMrenderers and data users to render/process the
additions/alternatives differently than the main route.

One solution just for rendering would be to optionally add "striped" to the
colour tag. Or dotted.

A more general solution would be something like alternative=yes,
additional=yes, approach=yes. A tag that covers all the variants, I can't
think of a suitable word.
the other way around: main_route=no?



Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why should we avoid overusage of amenity=* tag?

[Jan S]

Am Mo., 22. Apr. 2019 um 01:48 Uhr schrieb Paul Allen :

>
> It certainly makes overpass turbo queries a lot simpler and more intuitive
> if we can group all
> education facilities under education rather than under amenity.  Typing
> "education=*" is shorter
> than "amenity=school or amenity=university".  And won't trip you up if you
> forget that you also
> needed to query for amenity=college, etc.  We did it for healthcare, we
> can do it for education.
>
> In the short-term it means even more complex queries to find educational
> establishments because
> both sets of tags will be in use.  However, if we have a 1:1
> correspondence (amenity=school ->
> education=school) then a bulk edit is technically possible and maybe even
> politically possible.
>
> Otherwise let's get rid of amenity=* by tagging EVERYTHING as thing=*.
> It's the logical next step
> after using amenity any time we can't think of a better tag.
>
> I am in favour of using specific tags to group sets of things that belong
together, instead of using general tags like "amenity". But it's difficult
to teach an old dog new tricks. "Amenity" has been adopted so widely that
whenever a specific set of tags would be introduced, the question arises of
how to treat those things that have already been tagged as "amenity=*".
E.g. in the case of educational institutions, it would either be necessary
to maintain amenity=school or amenity=university, or double-tag these
institutions for the sake of backward compatibility as amenity=school and
education=school, or to automatic retagging of all amenity=school as
education=school (DANGER!!!).

These difficulties, and opposing ideas on how to deal with existing tags,
make it hard to change established tagging schemes. But I am strongly in
favour of not establishing new amenity=* for hitherto unmapped facilites,
but rather use new tags altogether, whose use can then be expanded into
proper tagging schemes.

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

[Tagging] Feature Proposal - Voting results - Police facilites

[Jan S]

The voting period for the refined police facilities proposal (
https://wiki.openstreetmap.org/wiki/Proposed_Features/Police_facilites) has
ended. The proposal has been rejected by 8 approvals against 3 rejections
(72.7% approval).

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Kevin Kenny]

On Mon, Apr 22, 2019 at 8:47 AM Valor Naram  wrote:
> I need to clarify the access=* key for my proposal to pleace this discussion.
>
> changing_table:access=yes
> The changing table is accessible to the public. This means you can change the 
> nappy of your baby without being a customer. This happens rarely.

A notable exception is the public loos in parks, airports, motorway
rest stops, and similar places. I suppose that you might be a
'customer' by virtue of having stepped into the place, but it's really
more 'access=yes'.

> changing_table:access=no
> The changing table isn't also accessible for the customers. We should leave 
> this value anyway because parents don't have any doubt of asking. It applies 
> also for rooms for which you need a key.

It's pretty common in the US to have to ask for they key to the
lavatory in gas/petrol stations and convenience stores. It's still
access=customers, you just need to request the access token.

In any case, thinking back a quarter-century or so to when my daughter
was a baby, the key question in my mind was usually, "is there a
changing table that isn't in the ladies' room?'  At the time, places
where a man could change a diaper discreetly were almost vanishingly
rare.

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

[Tagging] RFC - Connectivity

[Leif Rasmussen]

Hi everyone!
I have recently been mapping a lot of turn:lanes information on highways in
my area, but ran into the issue that turn:lanes fails to store all of the
necessary information in many junctions.  Multi-lane roundabouts, single
point urban interchanges, 5 way intersections with divided roads, and other
cases are all too complex for turn:lanes to handle.

Because of this, I have created a proposal for a simple type of from-via-to
relation that would provide information about how lanes in the "from" way
connect to those in the "to" way at any point where it isn't clear.  These
relations are very similar to turn restrictions, and like turn
restrictions, wont be needed in most intersections.

The relation would also be able to store the same information as could have
been possible with transit:lanes, just without the many maintenance issues
that came that system.


https://wiki.osm.org/wiki/Proposed_features/Connectivity


All feedback on how to potentially improve the proposal would be highly
appreciated!

Thanks,
Leif Rasmussen
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Variable position

[Paul Allen]

On Mon, 22 Apr 2019 at 14:45, bkil  wrote:

> leisure=outdoor_seating + shelter=no + covered=no
>

The wiki for the tag does not offer shelter or covered as associated tags.
Instead it
has weather_protection.

leisure=outdoor_seating seems to do what the OP wanted.  The only quibble I
have with
it is the icon, which shows it as being covered irrespective of
weather_protection=*.  If
you're a tourist in Cardigan on a day which is hot but it's also raining,
you might plan to eat
at the Fusion Bar and Restaurant https://www.openstreetmap.org/way/587710043
because it appears to have covered outdoor seating.  Or at Bara Menyn
https://www.openstreetmap.org/way/578156741  Or at El Salsa
https://www.openstreetmap.org/way/612581937
.
In reality, none of them have any form of weather protection.  Not even
parasols on the tables.

After three disappointments you probably wouldn't bother going to the
Cardiff Arms in Cilgerran
https://www.openstreetmap.org/way/679041950 because you now know not to
trust the icon.
That actually does have weather protection.

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Michael Brandtner via Tagging]

I don' think we should use no, but private. But as others have stated, I can't 
really think of a changing table that should be mapped in osm but isn't 
accessible even for customers. 
But us this really a point we need to discuss? Can't we just say that 
changing_table:access should be used with values of the access key and let 
mappers decide which one is the most apptopiate? 
 
  Am Mo., Apr. 22, 2019 at 14:46 schrieb Valor Naram:   
___
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] Other missing landform tags

[Kevin Kenny]

On Sun, Apr 21, 2019 at 10:39 AM Joseph Eisenberg
 wrote:
> > Col or gap (use saddle? And that is in OSM) = a col is the lowest point on a
> > mountain ridge between two peaks.
>
> Yes, "col" is the French word for saddle, a low point on a ridge.
>
> A gap is also usually a saddle (or sometimes a mountainpass=yes on a
> highway, sometimes a valley or gorge)

Around here, the locals use 'pass', 'gap' and 'notch' pretty much
interchangeably and the mountaineers use 'col' as a generic word. (The
locals who aren't into mountaineering might not even know the word.)
"Jimmy Dolan Notch is the col between Twin Mountain and Indian Head."

The mountains around here (which are actually arêtes but only a
geologist cares) have all sorts of nouns in their proper names.
'...berg' ('Wittenberg' never has 'Mountain' postpended by the locals,
no matter what the USGS maps say), '... Mountain', 'Mount ...', '...
Cap', '... Dome', '... Head', '... Knob,' '... Peak', '... Point,'
'... Top' are all common but don't really say anything about the
characteristics, except that the 'Points' tend to lie on the
Escarpment. (Visitors getting their first sight of Blackhead, Black
Dome, and Thomas Cole Mountain frequently remark on how similar they
look, standing side by side.) There are two that are simply named
'High Peak'; the mountaineers find it necessary to distinguish them
and attach the names of nearby features: 'Kaaterskill HIgh Peak',
'Windham High Peak'.  Farther north, there are a few that simply have
unique names: the 'Sawteeth' and the 'Gothics' come to mind, and I
never seem to hear anyone append 'Mountain' to those names. The name
'Tahawus' is beginning to displace 'Mount Marcy.'

> Natural=gully sounds fine. I know mountain climbers talk about these
> often, but there isn't a clear distinction from a gully or small
> valley.

As with 'col' and some others, I trace these terms in English largely
to a mountaineering book that Yvon Chouinard wrote in the late 1970s,
which I would argue is what started the modern popularity of ice
climbing.  I can't remember ever hearing those terms used by climbers
in, say 1975, but by the 1980's all the climbers were slinging them
about.

> > ravine = A deep narrow steep sided valley.
>
> I would think these could be either natural=gully or natural=valley or
> natural=gorge depending on size?

That's what I do.  I tend to do it only if the valley has a distinct
name from any stream that runs in it, partly because I don't have a
good rendering yet for these landforms, and depend on the contour
lines and hill shading in the maps I produce.

> > Fen = one of the main types of wetland, fens are a kind of mire. Tag as a
> > wetland?
>
> wetland=fen is approved, but much less common than wetland=bog - so I
> suspect that many fens are mapped as natural=wetland + wetland=bog -
> https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dfen

Around here, I've been assured by a geologist friend that some of the
so-called bogs are in fact fens. For various reasons, around me both
bogs and fens tend to be low-pH blackwater mires, with similar
ecosystems. The acid-tolerant bryophytes, leatherleaf, and cranberry
tend to predominate even in systems with enough nutrients to support a
sedge fen or an alder thicket. I couldn't distinguish bog from fen in
these mires without a detailed drainage study.  I suspect that few
mappers would distinguish ombrotrophic from minerotrophic systems, or
a lagg from a fen. So as long as we *have* the tags, knowledgeable
mappers can use them and other mappers can at least identify that the
peatlands are there.

> > tarn = A tarn (or corrie loch) is a mountain lake, pond or pool, formed in a
> > cirque excavated by a glacier. Use OSM lake ???
>
> +1 natural=water +water=lake - if you want, you could add lake=tarn as well?

Sounds good to me. The glacial water forms near me that I find
problematic for tagging are the paternoster lakes, which sometimes
bear names that are simply 'Essex Chain of Lakes', 'Fulton Chain of
Lakes', etc. and the individual ones have singularly uninformative
names like 'First Lake', 'Second Lake', and on up... there's a
'Thirteenth Lake' in one of the chains.

> > Peaks are not necessarily mountains or hills!!!
> > The highest mountain in Australia, Mt Koscciszko is a bump in a bumpy
> > landscape .. it is not a 'peak'.
>
> A natural=peak is any summit or peak; that is, any point that is
> higher than the surroundings. Wikipedia: "A summit is a point on a
> surface that is higher in elevation than all points immediately
> adjacent to it. The topographic terms acme, apex, peak (mountain
> peak), and zenith are synonymous."

This. A 'peak' surely doesn't need to be an isolated formation. Nor
does it need to be a true mountain. In fact, none of the 'Catskill
Mountains' is geologically a mountain. They're all arêtes in a heavily
glaciated, dissected plateau. Nor does a 'peak' need to be
particularly sharp; in fact, one of the 'High Peak's in the Catskills

Re: [Tagging] Variable position

[bkil]

leisure=outdoor_seating + shelter=no + covered=no

On Mon, Apr 22, 2019 at 3:11 PM Paul Allen  wrote:

> On Mon, 22 Apr 2019 at 13:49, bkil  wrote:
>
>> Note that outdoor_seating is usually for customers, so don't forget to
>> add:
>> access=yes
>>
>
> True, usually it's associated with customers.  But there may be public
> outdoor seating,
> possibly covered.
>
> Also, why not simply use the already established:
>> shelter=no + covered=no?
>>
>
> Because an uncovered shelter isn't much of a shelter (not in places where
> it rains a lot).  And
> a shelter doesn't necessarily have any seating.
>
> --
> Paul
>
> ___
> 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 - Baby changing table

[Valor Naram]

It could be added to the "features" key as "adjustable_height" value. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: To aid those with achondroplasia, I think it would also be useful to indicate whether adjustable_height is a feature of the table, though I guess they are already prepared to use the floor anyway.On Mon, Apr 22, 2019 at 2:22 PM Paul Allen  wrote:On Mon, 22 Apr 2019 at 00:50, marc marc  wrote:
if the goal is to talk about accessibility, then use the wheelchair tag.That just says if you can get a wheelchair into the toilet. 
but if by measuring the height of the table, you think you have done 
what it's need to inform accessibility, you are wrong, this detail is 
almost anecdotal in accessibility.No more anecdotal than anything else anybody maps. for all the others, no need to have a meter in your pocket,
it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3DAnd how about those with achondroplasia?To be honest, I doubt many mappers would bother mapping the height and it'sprobably not all that useful in most situations.  But the fact that somebody heresuggested it means it is likely that somebody will decide to map the height, in whichcase let's decide how to do it now.
>     same thing for the description key, I can't imagine when it's useful to
>     describe the table with words so I find it not very useful to promote itSecurity through obscurity doesn't work.  As for promoting it or not, it depends very much onwhat editors offer in their presets.the question is "can we expect to have changing tables on a regular 
basis that are different from what we can expect with other tags,
which would justify encouraging people to put a description ?Actually, no.  It's can we expect it on an irregular basis.  Because description is only rarelynecessary for anything.
access=* don't said anything about public view.
changing tables in a private area does not mean that your child
is protected from a public view (I know a changing table in
the private part of the maternity just in front of a windows
with a public corridor)
a changing table in a public toilet can be in a room that
is respectful of privacy.
if you want to inform this kind of info, it's probably better
to make another proposal for another key in stead of promoting
to hijack the access key to talk about public view when using
the feature.I already suggested that in private mail  to Valor for other reasons.  The developers ofsome editors don't like re-using keys with a subset of values and remove such usage frompresets.  If offering the full list of values doesn't make sense they either have to hard-code theexceptions or refuse to implement it in a preset, and these days it's usually refusal.  And, asyou've pointed out, not only does the syntax differ (only a subset of values make sense) so doesthe semantics.  So changing_table:access would be better.-- Paul
___
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] Variable position

[Paul Allen]

On Mon, 22 Apr 2019 at 13:49, bkil  wrote:

> Note that outdoor_seating is usually for customers, so don't forget to add:
> access=yes
>

True, usually it's associated with customers.  But there may be public
outdoor seating,
possibly covered.

Also, why not simply use the already established:
> shelter=no + covered=no?
>

Because an uncovered shelter isn't much of a shelter (not in places where
it rains a lot).  And
a shelter doesn't necessarily have any seating.

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[bkil]

To aid those with achondroplasia, I think it would also be useful to
indicate whether adjustable_height is a feature of the table, though I
guess they are already prepared to use the floor anyway.

On Mon, Apr 22, 2019 at 2:22 PM Paul Allen  wrote:

>
>
> On Mon, 22 Apr 2019 at 00:50, marc marc  wrote:
>
>>
>> if the goal is to talk about accessibility, then use the wheelchair tag.
>>
>
> That just says if you can get a wheelchair into the toilet.
>
> but if by measuring the height of the table, you think you have done
>> what it's need to inform accessibility, you are wrong, this detail is
>> almost anecdotal in accessibility.
>
>
> No more anecdotal than anything else anybody maps.
>
>
>> for all the others, no need to have a meter in your pocket,
>> it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3D
>>
>
> And how about those with achondroplasia?
>
> To be honest, I doubt many mappers would bother mapping the height and it's
> probably not all that useful in most situations.  But the fact that
> somebody here
> suggested it means it is likely that somebody will decide to map the
> height, in which
> case let's decide how to do it now.
>
> > same thing for the description key, I can't imagine when it's useful
>> to
>> > describe the table with words so I find it not very useful to
>> promote it
>>
>
> Security through obscurity doesn't work.  As for promoting it or not, it
> depends very much on
> what editors offer in their presets.
>
> the question is "can we expect to have changing tables on a regular
>>
> basis that are different from what we can expect with other tags,
>> which would justify encouraging people to put a description ?
>>
>
> Actually, no.  It's can we expect it on an irregular basis.  Because
> description is only rarely
> necessary for anything.
>
> access=* don't said anything about public view.
>> changing tables in a private area does not mean that your child
>> is protected from a public view (I know a changing table in
>> the private part of the maternity just in front of a windows
>> with a public corridor)
>> a changing table in a public toilet can be in a room that
>> is respectful of privacy.
>> if you want to inform this kind of info, it's probably better
>> to make another proposal for another key in stead of promoting
>> to hijack the access key to talk about public view when using
>> the feature.
>>
>
> I already suggested that in private mail  to Valor for other reasons.  The
> developers of
> some editors don't like re-using keys with a subset of values and remove
> such usage from
> presets.  If offering the full list of values doesn't make sense they
> either have to hard-code the
> exceptions or refuse to implement it in a preset, and these days it's
> usually refusal.  And, as
> you've pointed out, not only does the syntax differ (only a subset of
> values make sense) so does
> the semantics.  So changing_table:access would be better.
>
> --
> Paul
>
> ___
> 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] Variable position

[bkil]

Note that outdoor_seating is usually for customers, so don't forget to add:
access=yes

Also, why not simply use the already established:
shelter=no + covered=no?

On Mon, Apr 22, 2019 at 2:35 PM Paul Allen  wrote:

> On Mon, 22 Apr 2019 at 11:01, bkil  wrote:
>
>> This is what note=* is for - when you'd like to disclose an important
>> fact with future mappers that is not that interesting to non-mappers. You
>> may also draw a way/area and indicate the count of benches there or the
>> total sitting capacity. We may need to submit a proposal this, though.
>>
>
> Or use leisure=outdoor_seating.  Not a solution if you're mapping musical
> benches that are
> indoors, but otherwise it does what is required.  It doesn't offer a bench
> count but does say you
> can use capacity.  And it renders.
>
> My only gripe with this tag is the icon.  The same icon is used whether
> the area has weather
> protection (such as a canopy) or not: the icon shows a bench with a roof
> over it.  Most outdoor
> seating areas I've encountered around here are not covered (I believe the
> situation is the reverse
> in some countries) and I find the icon to be very misleading.  Tourism is
> a big part of the local
> economy here, and a tourist planning a trip on a rainy day could end up
> being unhappy to find
> the outdoor seating isn't actually covered.  I raised this with carto who
> dismissed the idea of
> using a different icon where weather_protection=no.
>
> --
> Paul
>
> ___
> 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 - Baby changing table

[Valor Naram]

I need to clarify the access=* key for my proposal to pleace this discussion.changing_table:access=yesThe changing table is accessible to the public. This means you can change the nappy of your baby without being a customer. This happens rarely.changing_table:access=noThe changing table isn't also accessible for the customers. We should leave this value anyway because parents don't have any doubt of asking. It applies also for rooms for which you need a key.changing_table:access=customersThe changing table is only accessible for customers. This is a value that applies to most POIs.changing_table:access=permissiveThe use of the changing table is accessible to the public but access can be revoked at any time for just one or few individuals while some are allowed.In fact: We can delete this subkey because the most changing tables in POIs are for customers only and permission of using it by others may be given out on a individual basic. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Mon, 22 Apr 2019 at 00:50, marc marc  wrote:
if the goal is to talk about accessibility, then use the wheelchair tag.That just says if you can get a wheelchair into the toilet. 
but if by measuring the height of the table, you think you have done 
what it's need to inform accessibility, you are wrong, this detail is 
almost anecdotal in accessibility.No more anecdotal than anything else anybody maps. for all the others, no need to have a meter in your pocket,
it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3DAnd how about those with achondroplasia?To be honest, I doubt many mappers would bother mapping the height and it'sprobably not all that useful in most situations.  But the fact that somebody heresuggested it means it is likely that somebody will decide to map the height, in whichcase let's decide how to do it now.
>     same thing for the description key, I can't imagine when it's useful to
>     describe the table with words so I find it not very useful to promote itSecurity through obscurity doesn't work.  As for promoting it or not, it depends very much onwhat editors offer in their presets.the question is "can we expect to have changing tables on a regular 
basis that are different from what we can expect with other tags,
which would justify encouraging people to put a description ?Actually, no.  It's can we expect it on an irregular basis.  Because description is only rarelynecessary for anything.
access=* don't said anything about public view.
changing tables in a private area does not mean that your child
is protected from a public view (I know a changing table in
the private part of the maternity just in front of a windows
with a public corridor)
a changing table in a public toilet can be in a room that
is respectful of privacy.
if you want to inform this kind of info, it's probably better
to make another proposal for another key in stead of promoting
to hijack the access key to talk about public view when using
the feature.I already suggested that in private mail  to Valor for other reasons.  The developers ofsome editors don't like re-using keys with a subset of values and remove such usage frompresets.  If offering the full list of values doesn't make sense they either have to hard-code theexceptions or refuse to implement it in a preset, and these days it's usually refusal.  And, asyou've pointed out, not only does the syntax differ (only a subset of values make sense) so doesthe semantics.  So changing_table:access would be better.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Variable position

[Paul Allen]

On Mon, 22 Apr 2019 at 11:01, bkil  wrote:

> This is what note=* is for - when you'd like to disclose an important fact
> with future mappers that is not that interesting to non-mappers. You may
> also draw a way/area and indicate the count of benches there or the total
> sitting capacity. We may need to submit a proposal this, though.
>

Or use leisure=outdoor_seating.  Not a solution if you're mapping musical
benches that are
indoors, but otherwise it does what is required.  It doesn't offer a bench
count but does say you
can use capacity.  And it renders.

My only gripe with this tag is the icon.  The same icon is used whether the
area has weather
protection (such as a canopy) or not: the icon shows a bench with a roof
over it.  Most outdoor
seating areas I've encountered around here are not covered (I believe the
situation is the reverse
in some countries) and I find the icon to be very misleading.  Tourism is a
big part of the local
economy here, and a tourist planning a trip on a rainy day could end up
being unhappy to find
the outdoor seating isn't actually covered.  I raised this with carto who
dismissed the idea of
using a different icon where weather_protection=no.

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Paul Allen]

On Mon, 22 Apr 2019 at 00:50, marc marc  wrote:

>
> if the goal is to talk about accessibility, then use the wheelchair tag.
>

That just says if you can get a wheelchair into the toilet.

but if by measuring the height of the table, you think you have done
> what it's need to inform accessibility, you are wrong, this detail is
> almost anecdotal in accessibility.


No more anecdotal than anything else anybody maps.


> for all the others, no need to have a meter in your pocket,
> it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3D
>

And how about those with achondroplasia?

To be honest, I doubt many mappers would bother mapping the height and it's
probably not all that useful in most situations.  But the fact that
somebody here
suggested it means it is likely that somebody will decide to map the
height, in which
case let's decide how to do it now.

> same thing for the description key, I can't imagine when it's useful
> to
> > describe the table with words so I find it not very useful to
> promote it
>

Security through obscurity doesn't work.  As for promoting it or not, it
depends very much on
what editors offer in their presets.

the question is "can we expect to have changing tables on a regular
>
basis that are different from what we can expect with other tags,
> which would justify encouraging people to put a description ?
>

Actually, no.  It's can we expect it on an irregular basis.  Because
description is only rarely
necessary for anything.

access=* don't said anything about public view.
> changing tables in a private area does not mean that your child
> is protected from a public view (I know a changing table in
> the private part of the maternity just in front of a windows
> with a public corridor)
> a changing table in a public toilet can be in a room that
> is respectful of privacy.
> if you want to inform this kind of info, it's probably better
> to make another proposal for another key in stead of promoting
> to hijack the access key to talk about public view when using
> the feature.
>

I already suggested that in private mail  to Valor for other reasons.  The
developers of
some editors don't like re-using keys with a subset of values and remove
such usage from
presets.  If offering the full list of values doesn't make sense they
either have to hard-code the
exceptions or refuse to implement it in a preset, and these days it's
usually refusal.  And, as
you've pointed out, not only does the syntax differ (only a subset of
values make sense) so does
the semantics.  So changing_table:access would be better.

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

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

 changing_table:location=unisex_toilet;wheelchair_toilet Original Message Subject: Re: [Tagging] diaper subkey for wheelchair toilets including a changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: Well, the place I had in mind only had a unisex toilet - a single, unsegregated entrance with possible multiple booths. In this case, the two are equivalent. If there exist two entrances: one unisex and one wheelchair, then it is reasonable to differentiate the two.On Mon, Apr 22, 2019 at 12:27 AM marc marc  wrote:Le 20.04.19 à 00:36, bkil a écrit :
> Is it correct that nappy_changing:location=toilets is equivalent to 
> nappy_changing:location=unisex?

not really, having a changing table somewhere in the toilet area doesn't 
give any information about whether these toilets are unisex or not
___
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 - Baby changing table

[bkil]

height=* was my fault, but I don't feel strongly about it, you may remove
it then. "straps" and "tilting" could still go under the list of
*:feature=*, though, that's a good idea.

toilet vs. room vs. dedicated_room:
How do you map a changing table that is found inside a small "toilets"
corridor/area behind closed doors but before entering the door for a
specific gender's toilet?

access=private
I always remind others to focus on points of _public_ interest when they
are working on extending our public map. This is the same reason we don't
map all Wi-Fi, even if they are completely open to the public, but operated
by a home owner who is otherwise not a point of interest.

Although, verifying whether wi-fi still works would be straight forward
(could even be automated using an app) and you might also see the mapped
private statue through the window or one residing on the front yard,
mapping private water taps are not verifiable for example, as it is not
realistic that dozens of passer by mappers will ring the doorbell every day
to double check whether the tap is still operable.

On Mon, Apr 22, 2019 at 9:02 AM Warin <61sundow...@gmail.com> wrote:

> On 22/04/19 09:49, marc marc wrote:
> > Le 22.04.19 à 00:39, Paul Allen a écrit :
> >> On Sun, 21 Apr 2019 at 22:56, marc marc wrote:
> >>
> >>  however I wonder if it's useful to promote changing_table:height
> >>  is there really any use for this tag ?
> >>
> >> A parent in a wheelchair might find that useful information,
> > if the goal is to talk about accessibility, then use the wheelchair tag.
> > but if by measuring the height of the table, you think you have done
> > what it's need to inform accessibility, you are wrong, this detail is
> > almost anecdotal in accessibility. the entrance of the poi must be
> > accessible, at least one path need to be accessible from the entrance to
> > the changing table (including door and corridor).
>
> Think the door has to be some 900mm wide and so on.
>
> >   and if the height of
> > the table then fits, a lot of tilting changing table are inaccessible
> > because the lock is often too high even if the table height is very low.
> > that's why I think promoting changing_table:height is a bad idea,
> > the contributor thinks he has entered useful information but it's not.
> > let's keep it simple, if one day someone see an accessible changing
> > table, add the tag wheelchair=yes
> > for all the others, no need to have a meter in your pocket,
> > it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3D
>
> Not just the height of the table, but also to be able to push the
> wheelchair at least partially under the table reduces arm strain a lot.
> And wheelchair users probably want the table at a lower height than 1.1
> metres.
>
> >
> >>  same thing for the description key, I can't imagine when it's
> useful to
> >>  describe the table with words so I find it not very useful to
> promote it
> >>
> >> Description is a standard tag applicable
> > I know the tag description, thanks :)
> > the question is "can we expect to have changing tables on a regular
> > basis that are different from what we can expect with other tags,
> > which would justify encouraging people to put a description ?
> > because if it is to inform the existence of a tag, we can edit
> > the whole wiki to say that the description tag exists,
> > which would increase the background noise without any added value.
> >
> >>  I also ask where a changing_table:access=private or =no may be
> usefull
> >>  I think the reasoning used for toilets should also apply to
> equipment
> >>  such as a changing_table: if it is totally private, such as the
> >>  changing
> >>  table in your home bathroom, it is not necessary to add in osm.
> >>
> >>
> >> Some people may feel uncomfortable changing their baby in public view.
> > access=* don't said anything about public view.
> > changing tables in a private area does not mean that your child
> > is protected from a public view (I know a changing table in
> > the private part of the maternity just in front of a windows
> > with a public corridor)
> > a changing table in a public toilet can be in a room that
> > is respectful of privacy.
> > if you want to inform this kind of info, it's probably better
> > to make another proposal for another key in stead of promoting
> > to hijack the access key to talk about public view when using
> > the feature.
>
> There are a few toilets with very nice views...
>
> >
> >>  changing_table:location=dedicated_room
> >>  if the purpose is to change the key diaper=room to diaper=yes +
> >>  location=dedicated_room I think this value is an too precise
> >>  assumption
> >> If you never encountered a changing table in a dedicated room
> >> then don't map it as such.
> > that's not what I said.
> > what I'm saying is : diaper=room doesn't have the same meaning
> > as changing_table:location=dedicated_room
> > if the 

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[bkil]

Well, the place I had in mind only had a unisex toilet - a single,
unsegregated entrance with possible multiple booths. In this case, the two
are equivalent. If there exist two entrances: one unisex and one
wheelchair, then it is reasonable to differentiate the two.

On Mon, Apr 22, 2019 at 12:27 AM marc marc 
wrote:

> Le 20.04.19 à 00:36, bkil a écrit :
> > Is it correct that nappy_changing:location=toilets is equivalent to
> > nappy_changing:location=unisex?
>
> not really, having a changing table somewhere in the toilet area doesn't
> give any information about whether these toilets are unisex or not
> ___
> 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] Variable position

[bkil]

This is what note=* is for - when you'd like to disclose an important fact
with future mappers that is not that interesting to non-mappers. You may
also draw a way/area and indicate the count of benches there or the total
sitting capacity. We may need to submit a proposal this, though.
https://wiki.openstreetmap.org/wiki/Key:note

On Mon, Apr 22, 2019 at 2:53 AM André Pirard 
wrote:

> On 24/12/2017 02.21, Matej Lieskovský wrote:
>
> Hello,
>
> is there a way to map objects, whose position changes slightly?
>
> In fact, the position of all objects changes slightly over time and a
> coordinate should be a vector indicating a position and a (presently best
> value of) direction and speed of drift.
> The Greenwich meridian is presently 102m west away of the zero latitude of
> a GPS and it continues to drift.
> See Greenwich Meridian 
> which is now 0.0014864° W by its nodes (which should have the same value
> BTW).
>
> All the best,
>
> André.
>
> Example:
> I know a park that has a few dozen benches. They are there practically
> all-year-round, but their position changes every now and then. A fixme
> would imply that the problem can be fixed (which does not seem practical),
> leaving them out completely is less than ideal and leaving them as nodes
> gives a false sense of precision, which is not perfect either. Is there a
> way of saying "there are benches somewhere around here"?
>
> Merry X-mas,
>
> Matej
>
>
> ___
> 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 - Baby changing table

[Warin]

On 22/04/19 09:49, marc marc wrote:

Le 22.04.19 à 00:39, Paul Allen a écrit :

On Sun, 21 Apr 2019 at 22:56, marc marc wrote:

 however I wonder if it's useful to promote changing_table:height
 is there really any use for this tag ?

A parent in a wheelchair might find that useful information,

if the goal is to talk about accessibility, then use the wheelchair tag.
but if by measuring the height of the table, you think you have done
what it's need to inform accessibility, you are wrong, this detail is
almost anecdotal in accessibility. the entrance of the poi must be
accessible, at least one path need to be accessible from the entrance to
the changing table (including door and corridor).


Think the door has to be some 900mm wide and so on.


  and if the height of
the table then fits, a lot of tilting changing table are inaccessible
because the lock is often too high even if the table height is very low.
that's why I think promoting changing_table:height is a bad idea,
the contributor thinks he has entered useful information but it's not.
let's keep it simple, if one day someone see an accessible changing
table, add the tag wheelchair=yes
for all the others, no need to have a meter in your pocket,
it's wheelchair=no, no need to fill heigh=1 or 1.05 or .95 except for 3D


Not just the height of the table, but also to be able to push the wheelchair at 
least partially under the table reduces arm strain a lot.
And wheelchair users probably want the table at a lower height than 1.1 metres.




 same thing for the description key, I can't imagine when it's useful to
 describe the table with words so I find it not very useful to promote it

Description is a standard tag applicable

I know the tag description, thanks :)
the question is "can we expect to have changing tables on a regular
basis that are different from what we can expect with other tags,
which would justify encouraging people to put a description ?
because if it is to inform the existence of a tag, we can edit
the whole wiki to say that the description tag exists,
which would increase the background noise without any added value.


 I also ask where a changing_table:access=private or =no may be usefull
 I think the reasoning used for toilets should also apply to equipment
 such as a changing_table: if it is totally private, such as the
 changing
 table in your home bathroom, it is not necessary to add in osm.


Some people may feel uncomfortable changing their baby in public view.

access=* don't said anything about public view.
changing tables in a private area does not mean that your child
is protected from a public view (I know a changing table in
the private part of the maternity just in front of a windows
with a public corridor)
a changing table in a public toilet can be in a room that
is respectful of privacy.
if you want to inform this kind of info, it's probably better
to make another proposal for another key in stead of promoting
to hijack the access key to talk about public view when using
the feature.


There are a few toilets with very nice views...




 changing_table:location=dedicated_room
 if the purpose is to change the key diaper=room to diaper=yes +
 location=dedicated_room I think this value is an too precise
 assumption
If you never encountered a changing table in a dedicated room
then don't map it as such.

that's not what I said.
what I'm saying is : diaper=room doesn't have the same meaning
as changing_table:location=dedicated_room
if the proposal wants to change one by the other, that's not true.
so at least changing_table:location=room is needed to be able to
convert existing information without making any erroneous assumption.
Of course, i didn't disagree to use dedicated_room when it's
a dedicated_room :)

Regards,
Marc
___
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 - Baby changing table

[Valor Naram]

+1 I agree with Paul Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Sun, 21 Apr 2019 at 22:56, marc marc  wrote:
however I wonder if it's useful to promote changing_table:height
is there really any use for this tag ?A parent in a wheelchair might find that useful information, although it would only influence adecision if there were similar facilities nearby.
same thing for the description key, I can't imagine when it's useful to 
describe the table with words so I find it not very useful to promote itDescription is a standard tag applicable (at least in theory) to all objects and used wherethere is something that distinguishes the object from others in its class or where it differssignificantly from what might otherwise be expected.  It's rare that I use description=* forany object, but occasionally it is useful.
I also ask where a changing_table:access=private or =no may be usefull
I think the reasoning used for toilets should also apply to equipment 
such as a changing_table: if it is totally private, such as the changing 
table in your home bathroom, it is not necessary to add in osm.Some people may feel uncomfortable changing their baby in public view.  Especially ifa down-market tabloid newspaper recently fuelled fear of paedophiles to boost itscirculation.
even access=permissive seems strange to me for this kind of equipment,
I don't know of any law instituting a right to the changing table, so 
all those who are access=yes are access=permissive because their
owner has the right to change their mind without asking someone elseNot sure about this one.  There are all sorts of fine distinctions.  A cafe might have a changingtable for use by customers, or may permit non-customers to use it if they ask.
changing_table:location=dedicated_room
if the purpose is to change the key diaper=room to diaper=yes + 
diaper:location=dedicated_room I think this value is an too precise 
assumption. the few changing tables I met in a room separate from the 
toilets were not in a dedicated room. it was often in the room with
the sinks, the entrance hall of the different toilets or in a 
multi-purpose room.If you never encountered a changing table in a dedicated room then don't map it as such.I have no problem with future-proofing a proposal.  Because eventually somebody will encountera changing table in a dedicated room and wonder how to map it.  Let's decide on a sensible way ofdoing it now rather than regretting we had not done so after somebody invents an ad-hoc way oftagging it.
since this proposal is to replace an existing key, it is useful
to make a short list of current usage and their new key/valueGood point. 

don't be afraid of the suggestion list, they are only suggestions to 
discuss in order to try to make the proposal as useful as possible.Don't say that!  You/ll make us seem warm and cuddly.  I've worked hard over many decades toappear curmudgeonly.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Warin]

On 22/04/19 00:48, Paul Allen wrote:
On Sun, 21 Apr 2019 at 15:43, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


"Changing table" is also the term that makes sense to me as a speaker
of American English.


The only possible ambiguity is if it is located in a temple.  It could 
belong to the money changers.




OSM has a tag for currency exchange ... arr

Amenity(what else?)=bureau_de_change (French ... for British English .. 
I suppose that is historical as the brits went overseas to France first.. )





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