Re: [Tagging] Avoid using place=locality - find more specific tags instead

[Kevin Kenny]

On Sun, Apr 21, 2019 at 10:40 PM John Willis via Tagging
 wrote:
Kevin Kenny:
> > The administrative boundaries do, of course give rise to corner cases.

> But when you have named places that have no residents (so not a village) but 
> hold some local or greater meaning (such as the stations of Mt Fuji) and are 
> more than the geologic or man made feature that gave them their name (the 
> stations were originally building names, but now they are are much more 
> important navigation aids for hikers, even when the buildings are gone), 
> place=locality is the solution.
>
> all of the old names and old villages make mapping more difficult (every 3 
> blocks there is a new “quarter” here in Japan! it is so dense!), but please 
> do not equate place mapping as somehow dependent on postal addressing 
> boundaries.  ^_^

I surely didn't!  I had already given examples (such as Sled Harbor
and Shattuck Clearing) that are now exactly what you said - named
points for hikers, where the named feature is long lost, but the name
is still current, and the example of the township where my brother
lives, where the settlement that gives the town its name is a ghost
town with little left but stone foundations of buildings. (The town
offices, post office, etc. are in a village of a different name, also
located in the township.)

In many suburban places in the US, the boundaries of the suburbs more
or less match the service areas of the corresponding post offices, and
for some unincorporated communities, that's as formal as the
boundaries get. In other places, the township or county will assign
boundaries to unincorporated communities - where I grew up is like
that, and there are even road signs announcing that you are entering
one or another of the unincorporated Hamlets. Hamlet with a capital H
because it's a legal term - a couple of the Hamlets are in fact small
cities that never adopted a charter of incorporation.

In New York City, in the boroughs of Queens and Staten Island, the
former towns and villages that existed prior to consolidation into
Greater New York retain their old names, and people still know where
the boundaries were, over a century ago. Postal addresses in large
measure reflect these former communities. The other boroughs have
named neighbourhoods, but they no longer have well-defined boundaries,
and do not appear in postal addresses: the remaining boroughs have
addresses that are 'New York', 'Bronx' or 'Brooklyn' irrespective of
the name of the neighbourhood.

These things aren't consistent, and the only answer, ever, is 'ask the locals.'

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

Re: [Tagging] Avoid using place=locality - find more specific tags instead

[John Willis via Tagging]

> On Apr 19, 2019, at 4:58 AM, Kevin Kenny  wrote:
> 
> Part of that is that as our population has grown, so have our
> settlements, to where we have to give greater respect to the
> boundaries between them.
> 


> The administrative boundaries do, of course give rise to corner cases.

Where I lived in San Diego is is the “unincorporated” area of Grossmont / Mt 
Helix, and my location was outside the city, only in the county of San Deigo. 

La Mesa absorbed the old “Grossmont” post office and the entire area is covered 
by the La Mesa Postal code 91941, though it is not in the city. 

Mt Helix - Casa De Oro is a recognized census place, and Grossmont is an (old) 
recognized place, but all are served by the La Mesa post office. the water 
service, the postal service, the school districts, and the city boundaries are 
all different. 

none of this affects the tagging of villages and other residential areas. Those 
boundaries and postal address are something else entirely. 


trying to relate “post offices” to an actual city or address is very difficult. 
the village/neighborhood/hamlet of “Grossmont” is not  a valid city for the 
USPS, but is still a named location (in OSM and other GIS services) - and 
should be mapped as the appropriate town/village/hamlet/quarter etc), not 
place=locality. 

But when you have named places that have no residents (so not a village) but 
hold some local or greater meaning (such as the stations of Mt Fuji) and are 
more than the geologic or man made feature that gave them their name (the 
stations were originally building names, but now they are are much more 
important navigation aids for hikers, even when the buildings are gone), 
place=locality is the solution. 

all of the old names and old villages make mapping more difficult (every 3 
blocks there is a new “quarter” here in Japan! it is so dense!), but please do 
not equate place mapping as somehow dependent on postal addressing boundaries.  
^_^

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

Re: [Tagging] Variable position

[André Pirard]

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

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

[marc marc]

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

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

> 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

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

[Paul Allen]

On Sun, 21 Apr 2019 at 23:42, Warin <61sundow...@gmail.com> wrote:

This helps mappers find similar things all under the one key.
> If highways were placed under amenity so
> amenity=motorway/secondary/primary/residential etc it would make mapping
> harder not easier.
>

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.

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

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

[Graeme Fitzpatrick]

On Mon, 22 Apr 2019 at 08:40, Paul Allen  wrote:

> 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 a
> decision if there were similar facilities nearby.
>

Thinking back (haven't had to use them for *many* years!, & don't often see
them in male public toilets), but I'd say that they're all at a pretty
standard height above the floor - adult waste height or approx 1 - 1.1m

I've worked hard over many decades to appear curmudgeonly.
>

Sorry, Paul - hasn't worked!

Thanks

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

Re: [Tagging] Feature Proposal -- Voting result -- shop=fashion_accessories

[Warin]

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



Would it be possible for there to be some alt text and hover-over text
that shows there is a link to the proposal?


+1


+1

It is certainly less visible, obvious and usable than before. Some alt 
text would be a small step in the right direction. Perhaps a larger icon 
with a more visible color too?


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

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

[Warin]

I am one of the people who disagree about using the key amenity

Would shops, crafts and offices be better in amenity? I think not.
Where any set of features can be grouped together they should be, and 
given there own key, such as education.

This helps mappers find similar things all under the one key.
If highways were placed under amenity so 
amenity=motorway/secondary/primary/residential etc it would make mapping 
harder not easier.


On 21/04/19 18:24, Valor Naram wrote:
I agree since "amenity" is a good tag and there are many different 
types of facilities available. In my view introducing an own key for 
each possibility would be messy.


Leaving it how it is now seems the best. Future proposals should just 
add a value to the "amenity" key



 Original Message 
Subject: Re: [Tagging] Why should we avoid overusage of amenity=* tag?
From: Mateusz Konieczny
To: "Tag discussion, strategy and related tools"
CC:





Apr 21, 2019, 3:55 AM by yumean1...@gmail.com:

I think that our discussion about these tagging schemes is in
very slow progress. In my opinion, a proposal on a new tag
like amenity=educational_services
is more effective rather than shifting to educational=*
tagging schemes.

I agree. Note that there are many people with conflicting opinions
about how tagging
should work and how it should be changed.

For example I see no problem with many features using amenity key.

In some cases there are groups of people with completely opposing
opinions and it
is impossible to please both of them.



___
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

[Paul Allen]

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 a
decision 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 it
>

Description is a standard tag applicable (at least in theory) to all
objects and used where
there is something that distinguishes the object from others in its class
or where it differs
significantly from what might otherwise be expected.  It's rare that I use
description=* for
any 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 if
a down-market tabloid newspaper recently fuelled fear of paedophiles to
boost its
circulation.

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

Not sure about this one.  There are all sorts of fine distinctions.  A cafe
might have a changing
table 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 encounter
a changing table in a dedicated room and wonder how to map it.  Let's
decide on a sensible way of
doing it now rather than regretting we had not done so after somebody
invents an ad-hoc way of
tagging 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/value
>

Good 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 to
appear curmudgeonly.

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

Re: [Tagging] 'track_detail' on railway lines - what does it represent?

[Warin]

On 22/04/19 06:52, Mateusz Konieczny wrote:




Apr 21, 2019, 1:37 PM by tagging@openstreetmap.org:

Hi
'track_detail, used on railway tracks.

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

4700+ total worldwide  3900+ in the UK

I can find nothing in the wiki

Is track_detail meant to indicate that all tracks have been mapped?
Surely that can be noted just by looking at the map?

I asked at https://www.openstreetmap.org/changeset/12684087
(edit that added this tag in your example).

User is still active. Overall, I would ask in at least some changesets
before or together with asking on ml.


The mailing list is a large audience compared to a single mapper 
contacted through a changeset comment .. one of those took years to 
respond despite being an active mapper. So I tend to ask here.


No idea what track_detail means...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[marc marc]

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

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

[marc marc]

Hello,

> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables

First of all, thank you for writing the proposal.

however I wonder if it's useful to promote changing_table:height
is there really any use for this tag ? I didn't find this kind of 
information in the current diaper=* key
of course we can always list every possible and imaginable combination 
(color, material, room lighting, width, presence of straps) but I think 
it is useful to encourage people to fill usefull/used information 
instead of asking then to fill a lot of informations not used.

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

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.
nothing obviously prevents someone from mapping his house in osm,
but I don't find it useful to promote it on every page of any equipment 
that may exist at home.

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 else

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.

"Rendered as: hidden" can also be deleted in my opinion. each style 
chooses or not what it wants to display, the only useful thing could be 
to find an icon. but considering the so little style that displays 
diaper=* it is probably not to be expected that many style 'll display 
the new key

since this proposal is to replace an existing key, it is useful
to make a short list of current usage and their new key/value

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.

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

Re: [Tagging] 'track_detail' on railway lines - what does it represent?

[Mateusz Konieczny]

Apr 21, 2019, 1:37 PM by tagging@openstreetmap.org:

> Hi
> 'track_detail, used on railway tracks.
>
> https://www.openstreetmap.org/way/4414158 
> 
>
> 4700+ total worldwide  3900+ in the UK
>
> I can find nothing in the wiki
>
> Is track_detail meant to indicate that all tracks have been mapped?
> Surely that can be noted just by looking at the map?
>
I asked at https://www.openstreetmap.org/changeset/12684087 

(edit that added this tag in your example).

User is still active. Overall, I would ask in at least some changesets
before or together with asking on ml.

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

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

[Michael Brandtner via Tagging]

Even if there is an extra room, there will be a changing table in it. and the 
bench is a substitute for a changing table. So I don't find this tag limiting. 
Of course there will be also a bin and a washing basin in such a room. But the 
table is the most important feature, similar to amenity=toilets


Am Sonntag, April 21, 2019, 5:56 PM schrieb Rory McCann :

The current proposal is baby_changing_table=*, but the common values for 
diaper=* include things like diaper=room, diaper=table, diaper=bench, so 
I think limiting this tag to just tables is bad. May I suggest 
baby_changing_facilities=* instead?




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

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

[Valor Naram]

The name of the key has been changed to "changing_table"
On Sat, 2019-04-20 at 17:12 +0200, Valor Naram wrote:
> Definition: A tag to mark the possibility to change the baby's nappy 
> Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/
> baby_changing_tables
>
> Please join the discussion and I will spend time to make changes.
>
> Cheerio
>
> Sören alias 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

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

[Valor Naram]

> Here are some alternatives, do share your concerns with each:: )1) I am not on the same opinion concerning the name "nappy_changing" or something like nappy:1.1. We've had heard about changing tables for adults hence the name "baby_changing_table" in order to distinguish between changing tables for changing nappies of babies and changing nappies of adult. My idea is that a future proposal could easily adapt from mine. So a "adult_changing_table" key could co-exist with "baby_changing_table".1.2. We could of course name the key "baby_nappy_changing_table" or something like that but it think this would lead to clustering and therefore to the key being harder to remember. Keep it simple ( KISS ) is my devise.2)> nappy_changing_place=*> nappy_changing_table=*> nappy_changing_room=*I don't consider it as good practise. We have the possibility to add subtags and should take use of that. So "place" is a subtag and belongs to "nappy_changing" hence it should be named "nappy_changing:place". Syntax: ":". The same goes for the other two. See also my concerns about the use of "nappy" ( "nappy_changing_table" ) in section 1) of this mail.3)> ... same with _change_ in place of _changing_I could imagine using "change" instead of "changing" e.g. "baby_change_table", "baby_change_table:location", ... Maybe there are some more (different) opinions out there since this discussion is meant to improve my proposal. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: bkil To: "Tag discussion, strategy and related tools" CC: Here are some alternatives, do share your concerns with each:nappy_changing=*nappy_changing_place=*nappy_changing_table=*nappy_changing_room=*... same with _change_ in place of _changing_Some I do not like as much:changing_table=*change_table=*baby_table=*diaper=*diaper_table=*nappy_table=*On Sun, Apr 21, 2019 at 2:07 AM Warin <61sundow...@gmail.com> wrote:
  

  
  
+1 for starting it.
  
  Think the name could be better .. sounds like a baby exchange :)
  
  On 21/04/19 04:59, bkil wrote:


  
  Thank you for taking the time to complete this nice
write up. I obviously support the proposed scheme. ;-)


I don't have strong feelings about the exact naming of the
  used key, as I mentioned previously.
  
  
  
On Sat, Apr 20, 2019 at 5:14
  PM Valor Naram  wrote:


  
Definition: A tag to mark the possibility to
  change the baby's nappy 
Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables


Please join the discussion and I will spend time to
  make changes.


Cheerio


Sören alias 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

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

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

[Paul Allen]

On Sun, 21 Apr 2019 at 16:58, Rory McCann  wrote:

>
> (And as a native (Hiberno) English speaker, "baby changing" sounds fine
> for changing a baby's nappy, not changing the baby for another baby! :P )
>

Changing a baby for a different baby would be silly.  However, if I were
given the
opportunity to change the baby for a cat...

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

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

[Rory McCann]

This would certainly be a little more obvious than the existing `diaper` 
tag.


The current proposal is baby_changing_table=*, but the common values for 
diaper=* include things like diaper=room, diaper=table, diaper=bench, so 
I think limiting this tag to just tables is bad. May I suggest 
baby_changing_facilities=* instead?


Lots of editors support the `diaper` tag, so you should submit patches 
to them to support this.


(And as a native (Hiberno) English speaker, "baby changing" sounds fine 
for changing a baby's nappy, not changing the baby for another baby! :P )


On 20.04.19 17:12, Valor Naram wrote:

*Definition:* A tag to mark the possibility to change the baby's nappy
*Proposal page:* 
https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables


Please join the discussion and I will spend time to make changes.

Cheerio

Sören alias 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

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

[Paul Allen]

On Sun, 21 Apr 2019 at 15:52, Joseph Eisenberg 
wrote:

> In villages and neighborhoods of smaller towns, the school is often
> the largest or only public place.
>

No argument here.

In Central and South America, the public school is also often the
> place where voting takes place for elections,


Also in the UK.

community meetings happen, and cultural events take place.
>

Also in the UK.

However, is the fact that a school is used for voting once every four years
more important
than that is is a place of education?  Is the fact that a school holds a
community event once
a month more important than that it is a place of eduction?

Shouldn't we be tagging the primary use?  A village hall might be built
that is then used for
voting and community events, but the school remains a school (until
budgetary cuts force its
closure).  A school is primarily an educational establishment and only
secondarily something
else.

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

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

[Joseph Eisenberg]

In villages and neighborhoods of smaller towns, the school is often
the largest or only public place.

In Central and South America, the public school is also often the
place where voting takes place for elections, community meetings
happen, and cultural events take place. This is also true of many
rural settlements in North America which lack any other secular
meeting place. In my rural American home town the public school
building was the only place to hold an indoor community event.

I suspect that in many rural areas the school is one of the most
likely places to meet with someone outside of the home or workplace,
because there are no other "third places" such as cafes, restaurants,
libraries, etc.

On 4/21/19, Paul Allen  wrote:
> On Sat, 20 Apr 2019 at 19:52, 石野貴之  wrote:
>
>>
>> I don't know the reason why we should not use amenity=* too much. If you
>> have time, please let me know.
>>
>> Lack of specificity.  It's nice to be able to categorize things.
> Otherwise every physical tag would be
> natural=* (if beaver damns are natural because beavers are natural, then
> all man_made=* is natural
> because man is natural) and every functional tag would be amenity=*.  There
> has, in the past, been
> a tendency to treat amenity=* as misc=* and some of us are trying to limit
> such usage.
>
> There is also a feeling that"amenity" is more suitable for places offering
> leisure activities and
> for actual amenities (such as post boxes) rather than schools.  Very few
> people decide to go on
> holiday to a school, or feel a need to visit a school to do something.
> Schools, like offices, are places
> most of us would prefer not to be and only go there because we're compelled
> or paid to do so.
>
> --
> Paul
>

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

Re: [Tagging] Feature Proposal -- Voting result -- shop=fashion_accessories

[Paul Allen]

On Sun, 21 Apr 2019 at 15:46, Joseph Eisenberg 
wrote:

>
> Would it be possible for there to be some alt text and hover-over text
> that shows there is a link to the proposal?
>

+1

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

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

[Paul Allen]

On Sun, 21 Apr 2019 at 15:43, Joseph Eisenberg 
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.

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

Re: [Tagging] Feature Proposal -- Voting result -- shop=fashion_accessories

[Joseph Eisenberg]

It's also a problem that the image does not have an alt text, so
nothing is visible if you do not load images.

(I usually browse the wiki without loading images, because I use a
satellite internet connection and pay for data)

Would it be possible for there to be some alt text and hover-over text
that shows there is a link to the proposal?

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

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

[Joseph Eisenberg]

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

As a parent I would appreciate knowing if there is a table where I can
place my infant child while changing their diaper ("nappy"); otherwise
I need to use my lap or the floor in the bathroom.

While I have worked in nursing homes, I can't recall seeing anything
that might be considered a "changing table" for adults. There are
hospital beds and examination tables and special wheelchair lifts, but
not something specific for changing adult undergarments.

So I don't think it's necessary to add "baby" or "infant" to the tag.

On 4/21/19, Michael Brandtner via Tagging  wrote:
>  changing_table seems to be the most common term so we should use it.
> https://en.oxforddictionaries.com/definition/changing%20tablehttps://www.dictionary.com/browse/changing-table
>
>
>
> Gesendet von Yahoo Mail für iPad
>
>
> Am Sonntag, April 21, 2019, 9:12 AM schrieb bkil :
>
> Here are some alternatives, do share your concerns with
> each:nappy_changing=*nappy_changing_place=*nappy_changing_table=*nappy_changing_room=*...
> same with _change_ in place of _changing_
> Some I do not like as
> much:changing_table=*change_table=*baby_table=*diaper=*diaper_table=*nappy_table=*
> On Sun, Apr 21, 2019 at 2:07 AM Warin <61sundow...@gmail.com> wrote:
>
>   +1 for starting it.
>
>  Think the name could be better .. sounds like a baby exchange :)
>
>  On 21/04/19 04:59, bkil wrote:
>
>  Thank you for taking the time to complete this nice write up. I obviously
> support the proposed scheme. ;-)
>   I don't have strong feelings about the exact naming of the used key, as I
> mentioned previously.
>   On Sat, Apr 20, 2019 at 5:14 PM Valor Naram  wrote:
>
>   Definition: A tag to mark the possibility to change the baby's nappy
> Proposal page:
> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables
>   Please join the discussion and I will spend time to make changes.
>   Cheerio
>   Sören alias 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
>
> ___
> 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

[Joseph Eisenberg]

On 4/21/19, Warin <61sundow...@gmail.com> wrote:
> Arch = A hole though some feature, usually rock. Covered overhead and to
> both sides, open at both ends.

This is natural=arch
https://wiki.openstreetmap.org/wiki/Proposed_features/Natural_arch -
as mentioned by Paul Allen above

> archipelago = an island group or island chain

place=archipelago - I recently updated this page but it's been in use
since 2013 https://wiki.openstreetmap.org/wiki/Tag:place%3Darchipelago

> basin = The tract of country drained by a river and its tributaries, or
> which drains into a particular lake or area. Note need to be careful not to
> confuse this with man_made=basin or sea basins.

I asked about this a few months ago. Several people were against
mapping drainage basins, because the verifiable boundaries can be
mapped as natural=ridge, and the others are not verifiable.

> Canyon: A gorge, relatively narrow but of considerable size ...(possibly tag 
> as gorge with
> gorge=canyon?)

The alternative, already suggested on some non-English pages, would be
natural=canyon - used 163 times; or natural=valley with valley=canyon?
I would map these as a node or as a linear way that follows the low
ground or the waterway

> Cap = ???

Misspelling for cape? Or a type of peak? No idea.

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

> couloir (French: [ku.lwaʁ], "passage" or "corridor"), is a narrow gully with
> a steep gradient in a mountainous terrain. Tag as a gully??

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.

> Depression = A sunken place.

Also called sink. The low point of one of these is the opposite of a
peak - but usually they are only found in arid areas or karst, since a
lake normally forms.

We do have the approved tag natural=sinkhole for one common type of
depression, which can work for places where a stream disappears
underground as well.
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dsinkhole

Most other sinks and depressions will be the site of an ephemeral
lake; eg Badwater in Death Valley, lots of intermittent desert lakes
in Australia.

> Gully = natural watercourse, especially a hillside,  It only carries water
> after rain and its sides are generally steep. Usually one of the smallest
> branches of a drainage system, and often associated with erosive action.

Natural=gully is in use, but not very common. Many could also be
mapped as an intermittent stream. If there are steep slopes
natural=cliff or natural=earth_bank can be used.
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dgully

> fjard = (Swedish: fjärd, IPA: [ˈfjæːɖ]) is an inlet formed by the marine
> submergence of formerly glaciated valleys and depressions within a rocky
> glaciated terrain of low relief. Fjards are characterized by a profile that
> is shorter, shallower, and broader than the profile of a fjord.

Never heard of this before! Wikipedia says: "A fjard is a large open
space of water between groups of islands or mainland in archipelagos.
" It's related to the word "fjord". It sounds like this would usually
be a natural=strait or perhaps natural=bay?

> Fjord ? Not in the data base??? Yet fjard is.

Fjords are often tagged as natural=bay plus bay=fjord:
https://wiki.openstreetmap.org/wiki/Tag:bay%3Dfjord

> fumarole =is an opening in a planet's crust which emits steam and gases
There are 2 proposals, both used less than 20 times:
geological=volcanic_fumarole
https://wiki.openstreetmap.org/wiki/Tag:geological%3Dvolcanic_fumarole
natural=fumarole
https://wiki.openstreetmap.org/wiki/Proposed_features/fumarole

> massif = a section of a planet's crust that is demarcated by faults or
> flexures. In the movement of the crust, a massif tends to retain its
> internal structure while being displaced as a whole. The term also refers to
> a group of mountains formed by such a structure.

This was proposed but abandoned, used less than 20 times: natural=massif
I'm not sure how a non-geologist could map one of these. It sounds
like they are defined by faults and subsurface rock characteristics
that are not really visible?

> Mountain = A large natural elevation of the earth’s surface. Note peaks are
> different from mountains, see below!

Most mountains can be mapped as either a natural=peak (if the named
features is a particular peak) or a natural=ridge (if the mountain is
a linear feature with several peaks), or natural=volcano sometimes.

> mountain_ridge = Use ridge? in OSM already

Yes, natural=ridge is approved

> Oasis =the combination of a human settlement and a cultivated area (often a
> date palm grove) in a desert or semi-desert environment

Just a place=village and various types of landuse and 

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

[Michael Brandtner via Tagging]

 changing_table seems to be the most common term so we should use it.
https://en.oxforddictionaries.com/definition/changing%20tablehttps://www.dictionary.com/browse/changing-table
 



Gesendet von Yahoo Mail für iPad


Am Sonntag, April 21, 2019, 9:12 AM schrieb bkil :

Here are some alternatives, do share your concerns with 
each:nappy_changing=*nappy_changing_place=*nappy_changing_table=*nappy_changing_room=*...
 same with _change_ in place of _changing_
Some I do not like as 
much:changing_table=*change_table=*baby_table=*diaper=*diaper_table=*nappy_table=*
On Sun, Apr 21, 2019 at 2:07 AM Warin <61sundow...@gmail.com> wrote:

  +1 for starting it.
 
 Think the name could be better .. sounds like a baby exchange :)
 
 On 21/04/19 04:59, bkil wrote:
  
 Thank you for taking the time to complete this nice write up. I obviously 
support the proposed scheme. ;-) 
  I don't have strong feelings about the exact naming of the used key, as I 
mentioned previously.  
  On Sat, Apr 20, 2019 at 5:14 PM Valor Naram  wrote:
  
  Definition: A tag to mark the possibility to change the baby's nappy  
Proposal page: 
https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables 
  Please join the discussion and I will spend time to make changes. 
  Cheerio 
  Sören alias 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

___
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

[Paul Allen]

On Sun, 21 Apr 2019 at 01:40, Warin <61sundow...@gmail.com> wrote:

> Arch = A hole though some feature, usually rock. Covered overhead and to
> both sides, open at both ends.
>

Proposed back in  2013 here
https://wiki.openstreetmap.org/wiki/Proposed_features/Natural_arch
(and still underway).  Used 94 times, once by me.

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

Re: [Tagging] Feature Proposal -- Voting result -- shop=fashion_accessories

[Martin Koppenhoefer]

sorry, sent former mail by accident. Yes, I see the icon now. I must have 
missed we changed the structure how we present tags. IMHO the tiny icon beside 
the approved status makes conceptually sense (including the placement), but is 
visually less evident than the former text links which we manually set. If you 
hadn’t told me I would never have clicked on it.

thank you,
Martin

sent from a phone

> On 21. Apr 2019, at 14:28, Martin Koppenhoefer  wrote:
> 
> 
> 
> sent from a phone
> 
>> On 10. Apr 2019, at 11:38, Markus  wrote:
>> 
>> The proposal is already linked from the data item Q19528 [1] and is
>> passed on to the {{ValueDescription}} template on the feature page.
>> There should be a sheet icon behind "Status: approved" on the feature
>> page. Does it not show up in your browser?
>> 
>> [1]: https://wiki.openstreetmap.org/wiki/Item:Q19528
> 
> 
> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfashion_accessories
> 
> 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal -- Voting result -- shop=fashion_accessories

[Martin Koppenhoefer]

sent from a phone

> On 10. Apr 2019, at 11:38, Markus  wrote:
> 
> The proposal is already linked from the data item Q19528 [1] and is
> passed on to the {{ValueDescription}} template on the feature page.
> There should be a sheet icon behind "Status: approved" on the feature
> page. Does it not show up in your browser?
> 
> [1]: https://wiki.openstreetmap.org/wiki/Item:Q19528


https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfashion_accessories


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

[Tagging] 'track_detail' on railway lines - what does it represent?

[Dave F via Tagging]

Hi
'track_detail, used on railway tracks.

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

4700+ total worldwide  3900+ in the UK

I can find nothing in the wiki

Is track_detail meant to indicate that all tracks have been mapped?
Surely that can be noted just by looking at the map?

DaveF



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

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

[Valor Naram]

I agree since "amenity" is a good tag and there are many different types of facilities available. In my view introducing an own key for each possibility would be messy.Leaving it how it is now seems the best. Future proposals should just add a value to the "amenity" key Original Message Subject: Re: [Tagging] Why should we avoid overusage of amenity=* tag?From: Mateusz Konieczny To: "Tag discussion, strategy and related tools" CC: 
  
  
Apr 21, 2019, 3:55 AM by yumean1...@gmail.com:I think that our discussion about these tagging schemes is in very slow progress. In my opinion, a proposal on a new tag like amenity=educational_services is more effective rather than shifting to educational=* tagging schemes.I agree. Note that there are many people with conflicting opinions about how taggingshould work and how it should be changed.For example I see no problem with many features using amenity key.In some cases there are groups of people with completely opposing opinions and itis impossible to please both of them.  

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

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

[Mateusz Konieczny]

Apr 21, 2019, 3:55 AM by yumean1...@gmail.com:

> I think that our discussion about these tagging schemes is in very slow 
> progress. In my opinion, a proposal on a new tag like 
> amenity=educational_services 
> is more effective rather than shifting to educational=* tagging schemes.
>
I agree. Note that there are many people with conflicting opinions about how 
tagging
should work and how it should be changed.

For example I see no problem with many features using amenity key.

In some cases there are groups of people with completely opposing opinions and 
it
is impossible to please both of them.

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

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

[bkil]

Here are some alternatives, do share your concerns with each:
nappy_changing=*
nappy_changing_place=*
nappy_changing_table=*
nappy_changing_room=*
... same with _change_ in place of _changing_

Some I do not like as much:
changing_table=*
change_table=*
baby_table=*
diaper=*
diaper_table=*
nappy_table=*

On Sun, Apr 21, 2019 at 2:07 AM Warin <61sundow...@gmail.com> wrote:

> +1 for starting it.
>
> Think the name could be better .. sounds like a baby exchange :)
>
> On 21/04/19 04:59, bkil wrote:
>
> Thank you for taking the time to complete this nice write up. I obviously
> support the proposed scheme. ;-)
>
> I don't have strong feelings about the exact naming of the used key, as I
> mentioned previously.
>
> On Sat, Apr 20, 2019 at 5:14 PM Valor Naram  wrote:
>
>> *Definition:* A tag to mark the possibility to change the baby's nappy
>> *Proposal page:*
>> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables
>>
>> Please join the discussion and I will spend time to make changes.
>>
>> Cheerio
>>
>> Sören alias Valor Naram
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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