[Tagging] New Key capacity:*=n values

2015-07-31 Thread johnw
TL;DR:  
suggesting creation of
capacity:motorcycle/scooter/moped=n
capacity:senior=n and capacity:priority=n
and maybe 
access=disabled for service roads / gates

~~~

Talking about stuff missing from 
http://wiki.openstreetmap.org/wiki/Key:capacity 
http://wiki.openstreetmap.org/wiki/Key:capacity

We all know about the capacity:disabled=n extension on the disability key, but 
there are other very common parking types that are not represented. 

Usually large parking lots for big public retail, commercial, and now some 
government business offer separate “elderly”  “pregnant woman” parking, which 
is separate and (sometimes legally) different from disabled parking. sometimes 
this is separate and sometimes this is grouped together, as “priority” - which 
would be a more flexible value - and similar to the Japanese “priority seat” 
values 
http://sandierpastures.com/wp-content/uploads/2011/10/priority-seat-train-in-Japan-550x412.jpg
 
http://sandierpastures.com/wp-content/uploads/2011/10/priority-seat-train-in-Japan-550x412.jpg
 


Also, there are parking lots for motorcycles / scooters, but there is no 
separate standardized and documented motorized cycle parking key and/or no 
capacity:scooter/moped/motobike/=n . In Japan, Bicycle is “jitensha” and 
scooters are “baiku” (bike), and often separated parking for both. 

https://www.google.com/maps/@35.7139475,140.2925493,73m/data=!3m1!1e3 
https://www.google.com/maps/@35.7139475,140.2925493,73m/data=!3m1!1e3

“baiku” parking north of the driveway, “Jitensha” parking to the south. 

Japan has a “elderly” symbol, which is an optional badge to affix to a car 
(mandatory over 75) to show that it is an elderly driver, and now is used as a 
badge for “senior” parking in Japan.  This is separate from truly disabled 
parking. https://en.wikipedia.org/wiki/Koreisha_mark 
https://en.wikipedia.org/wiki/Koreisha_mark 

https://www.google.com/maps/@35.7126866,140.292717,36m/data=!3m1!1e3 
https://www.google.com/maps/@35.7126866,140.292717,36m/data=!3m1!1e3

Blue disabled parking and yellow “elderly” parking

We should be able to add capacity:*=n for  “motorcycle” “senior” “and 
“priority/pregnant” values should be considered. Thoughts? 

Also, disabled parking more and more recently have actual access restrictions - 
gates and driveways to access separate parking spaces that require some kind of 
transmitter or a call box for the staff to allow access to lot so only truly 
disabled people take the special spaces for specialized vehicles. i saw gates 
blocking individual parking spaces at malls. 
https://www.google.com/maps/@36.1420991,139.5427032,72m/data=!3m1!1e3 
https://www.google.com/maps/@36.1420991,139.5427032,72m/data=!3m1!1e3 

Access=disabled would be good for this situation, but even access=customers is 
not documented on the wiki - which seems very outdated.

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


Re: [Tagging] Feature Proposal - RFC - indoormark=beacon

2015-07-31 Thread Guillermo Amat
Hello

Mainly because we think we have more similarities with seamark and airmark
tags. The usage is almost the same as what you can find on:
https://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values  or
https://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values.It is
suggested to use a similar schema, for instance indormark:type is the
equivalent to  seamark:type

Moreover, we are using the indoor key as explained in Simple Indoor Tagging
(http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging) In that proposal
indoor is used for rooms, corridors, walls, areas and levels, in other
words, the main structures which compound a building.

Regards


2015-07-30 14:25 GMT+02:00 panierav...@riseup.net:

 Hello,

 Why don't you use the indoor key directly ?

 Cordially.

 Le 2015-07-30 11:36, Guillermo Amat a écrit :

 Hello

 My group is working on an indoor project and we have the necessity to
 place
 indoor beacons inside a building. As we are using OSM, we need a way to
 store all the data for any beacon in order to position the user and
 provide
 navigation.

 Our proposal is based on what we have found for labeling beacons for sea
 https://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values and
 air
 https://wiki.openstreetmap.org/wiki/DE:Tag:airmark%3Dbeacon transport.

 https://wiki.openstreetmap.org/wiki/Proposed_features/indoormark%3Dbeacon

 Regards


 ___
 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] Rendering for shop=boutique/fashion on default style

2015-07-31 Thread Daniel Koć
I was about to add new icon for shop=boutique and shop=fashion on our 
default style, but after short discussion it seems we need some 
clarification of these schemes definition:


https://github.com/gravitystorm/openstreetmap-carto/issues/1706

The only sure thing is shop=clothes, both boutique and fashion are not 
clearly defined and have de facto status. What should we do with them? 
Is there a way to clearly define such shops and - if yes - what tagging 
scheme should be used and which one should be deprecated? Should they 
have their own tag at all or just additional tag for shop=clothes?


--
The train is always on time / The trick is to be ready to put your bags 
down [A. Cohen]


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