Re: [Tagging] access in the wiki: move psv to by use
2014/1/13 martinq osm-mart...@fantasymail.de I have interpreted psv (public service VEHICLE), bus and taxi as vehicle categories in the past, but never required these keys in my area. So for me an empty taxi is allowed on taxi=yes. it is not a question whether it is empty or not (it might be going to pick up someone) but whether it is in service. There are two issues, nobody has probably paid attention on so far: 1) public service is not public transport, as intended by the creators of the key. So if people make a road cleaning truck or an ambulance a PSV, then this was maybe not intended, but a result of ambiguous documentation/naming. if you look at wikipedia for instance: http://en.wikipedia.org/wiki/PSVthis get's redirected to bus, so my guess is, that the common usage of this term is the same than the definition in OSM and not including all kind of public vehicles. Also the approach to mix use (public service/transport) with vehicle type was probably not the best choice back in the early days. It created the weird issue of requiring a new category for buses not used for public transport, since orthogonal use and type cannot be freely combined. this is common in legislation too (two types of buses: the vehicle class and those operating as public transport vehicle). Better backward compatibility I refine my proposal in the other post a little bit: 1) Update key hierarchy: + omnibus Vehicle registered as bus +++ busOmnibus vehicle, used for public transport at point of access 2) Introduce value public_transport omnibus=no bus=yes can also be expressed as omnibus=public_transport IMHO we can stick to psv. 3) Depreciatepsv (or broaden the meaning to all public service vehicles) because of the JOSM turn restriction plugin? What about changing that plugin? 4) Depreciate tourist_bus: There is no longer the need for tagging both (bus=yes and tourist_bus=yes) in the case any bus category is meant. It can be expressed by omnibus=yes now. not sure. I introduced this key because of a sign that said explicitly: tourist_bus=no. Maybe this could be represented by omnibus=no bus=yes (or psv=yes), if these will be introduced and accepted, but as long as they arent I'd keep this key. It is currently used 849 times, it seems to be unambiguous, so no need to deprecate IMHO. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unsuitable?
On Wed, Jan 8, 2014 at 8:12 AM, Colin Smale colin.sm...@xs4all.nl wrote: I am not sure why it was suddenly changed (today) from unsuitable to discouraged, but Unsuitable for HGVs is seen frequently in the UK. To my understanding there is a difference between the semantics of unsuitable and discouraged, the former being a simple statement of (official) opinion and the latter indicating that active measures have been taken to decrease its occurrence. In any case it might not be legally enforceable, but if you are shown to have ignored the official warning it may affect your position if it came to an incident (insurance claim). Not sure either. I know there's similar signs in the US (in Oregon, 'Travel at your own risk, emergency and rescue services not available next xx miles' and '4 wheel drive with low range strongly recommended' are two I've seen; though one that's clearly bicycle=no, foot=no is 'Bicycles and pedestrians prohibited; no water or shelter next xx miles, YOU WILL DIE' is a common sighting on side roads from major highways in the Oregon outback, where motorized travel is somewhere between tedious and difficult in general and travel by bicycle or foot is somewhere between extremely difficult to deadly on the main roads, and just totally not doable on the sides. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag max width at chicane-type bicycle barriers
Consider also the discussion at this extensive thread: https://lists.openstreetmap.org/pipermail/tagging/2013-August/thread.html#14590 Useful metrics for exclusion barriers are really hard to come by (check out the sofa problem listed in the thread, and apply it to a bike plus trailer). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag max width at chicane-type bicycle barriers
See in specific for this on 'exclusion' type barrier tagging: https://lists.openstreetmap.org/pipermail/tagging/2013-August/014633.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - trafficability
The tag as proposed leaves much to interpretations. But there are a bunch of things one can say about a road that are crisp and clear: covered_at_high_tide not_plowed_in_winter not_maintained_by_government passing_requires_reversing But at some point you break down into prose and write note='Road maintained by local 4WD club, passes over sandy inlet that floods at high tide, four inch rocks placed by club restrict access to high clearance vehicles, see website for details.' ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Religious Places that belongs to multiple Religion
On 2014-01-13 23:42, Zecke wrote : Am 13.01.2014 23:18, schrieb André Pirard: I also would feel like accepting the semicolon, but after thinking twice I notice that religion=religion1;religion2;;religion denomination=denomination1;denomination2 would become even more problematic already. Why? Of course, you must include the dependencies and keep in mind that religion=religion1 denomination=d1 Simply because ifthe article I mentioned http://wiki.openstreetmap.org/wiki/Semicolon says that ; is problematic because it's not supported, it will certainly say that that two paired lines are even less supported, that's all. (not all religions have denominations necessarily). And so we must be sure that =d1;;d3 is what to use, because that article makes a very unclear specification regarding ;; as an escape character ans is even unsure about ; as the separator. In summary, if this=shop that=shop or amenity=library library:stock:books=yes library:stock:newspapers=yes library:stock:recorded_music=yes have so little consenting echo, ; is the only alternative option to go. And so, the question is: do we wait for a welcoming, correct and precise specification of ; or do we as often go ahead without one, come what may. I pointed out that the article conflicts with the tagging for the renderer nagger. Separate things out into separate nodes/ways to allow them to be tagged separately with normal tags conflicts with the don't tag things that do not exist nagger too. The important point with tagging is being consumable. Cheers, André. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
