Alan McConchie wrote:
> Some commenters have suggested using the existing highway=path tag,
> with supplemental tags such as access=no or informal=yes, or a new
> supplemental tag path=social_trail, or adding an operator tag. However,
> these supplemental tags are too easily ignored by data consumers and
> renderers, which is problematic given the destructive and hazardous
> nature of social trails in many areas.
First, big thanks for bringing this to the list.
I do think, however, you are mistaken with the above rationale, which
appears to be the sole rationale for the proposal.
access=no is absolutely a core tag within OSM, dating back to the very first
iteration of Map Features. It isn't "easily ignored". Any router which
ignores it is unambiguously bugged. Any renderer intended for walkers'
consumption which shows it as a walkable path is unambiguously bugged.
It is not, however, documented or safe to assume that renderers and routers
will always fall back to "no". There have been renderers which will render
the name for an unknown highway value, so 'highway=social_path;
name=Shortcut' would show on the map as a label saying 'Shortcut'. There are
routers which will assume a default speed for unknown highway values. That
isn't always daft: you can envisage a single typo in one two-node way
('highway=mptorway, maxspeed=70mph, surface=paved, access=yes...') which
would otherwise break routing across a continent if the router was entirely
fault-intolerant.
To widen the discussion, introducing new core path values is bad OSM
citizenship.
Path tagging in OSM is notoriously complex, for one reason: people keep
reworking the core model to deal with their edge-cases.
We began with highway=footway/bridleway/cycleway/track, surface=*, and
access/foot/bicycle/horse/motor_vehicle=*. With these values, you can model
the essential characteristic of 95% of paths (conservative estimate).
Some people identified edge cases which they felt were not adequately
captured by this scheme, and therefore introduced a new, more complex
scheme, highway=path.
Later, others identified still further edge cases and introduced yet more
values: access/foot/bicycle/etc.=designated. Later later, others identified
still further edge cases, and we got access/foot/bicycle/etc.=official.
And so on. Every such change has made the system more impenetrable for
mappers and consumers, and we have, I believe, a collective responsibility
to keep OSM usable. I won't bore you with the details of the Lua tag parsers
I use for cycle.travel's path routing and rendering, but they are insanely
complex - hashes upon hashes upon hashes, special cases upon special cases -
and yet there are still bugs and edge cases. How anyone who doesn't have
years of experience in OSM is meant to cope with this, I don't know.
The best way to map these, without adding further burdens to mappers or
consumers, is to use broad-brush, well-established tags such as:
highway=footway
access=no
and then, if you feel this doesn't fully capture your particular edge case,
some sort of _additional_ tag:
social_path=yes
(The classic example of this is motorroad=yes, which the German community
introduced as a refinement on highway=trunk/primary, and which has since
become a successful and widely-adopted tag without breaking highway routing
or rendering.)
But please don't extend existing core tagging, such as highway=, in new and
exciting ways. It doesn't necessarily solve the problem in the way you think
it will, and it makes it harder for everyone to use OSM.
cheers
Richard
--
View this message in context:
http://gis.19327.n5.nabble.com/Subject-Feature-Proposal-RFC-highway-social-path-tp5870639p5870698.html
Sent from the Tagging mailing list archive at Nabble.com.
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
