Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:
Can we finally fix two other longstanding problems, then?
1. The wiki being incorrect about not counting bicycle lanes. That's
not reflective of how validators deal with lanes, how data consumers
like Osmand or Magic Earth deal with lanes, or how ground truth works.
The whole "but you can't fit a motor vehicle down it" argument is
facile, that's what access:lanes=* and width:lanes=* is for.
I agree that width is a poor argument for the status quo, especially
given the common practice (in California, anyways) of bike lanes that
double as right turn lanes for cars.
For what it's worth, the lanes=* documentation has long included a
passage recommending that data consumers treat lanes=* as a minimum
value rather than a reliable exact lane count. Apparently some mappers
only count through lanes but exclude turn lanes.
I'm pretty sure existing routers would have no problem with including
bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=*
are both present. So I think a reasonable migration path would be to use
the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the
non-auto-centric approach you're advocating.
2. Tagging route information on ways. It's about a decade too long at
this point for ref=* on a way to be completely disconnected from the
entity the tag applies to: That's why route relations exist. Biggest
problem child on this at the moment: OSM's own tilesets. Let's drop
rendering for ref=* on ways and just render the route relations already,
this and multipolygons are why relations came to exist in the first place.
I'm as excited about route relations as anyone, especially because route
relations are required for more nuanced route shield selection in
renderers and routers. But for all the problems route relations solve,
there are still some unresolved issues:
* Even once rendered maps display pictioral route shields [2], there
will still be situations where plain text is more appropriate, just as
on the ground. It isn't always obvious how to transform a particular
network=* value into a human-readable ref prefix to display in prose or
read aloud during turn-by-turn navigation. Signposted ref prefixes can
be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly
building up Wikidata's coverage of signposted road networks and linking
it to OSM Wiki data items, to make it easier for data consumers to look
up the human-readable ref prefix on demand [3] or export a lookup table
like [4] to hard-code. Incidentally, I've also proposed a road name
formatter property at Wikidata [5], so that data consumers can expand
network=US:NV:Clark to "Clark County Route", but it hasn't gotten much
traction yet.
* A way's ref=* key is an ordered list, whereas there's no explicit
ordering of a way's membership in multiple route relations. (A relation
explicitly contains its members but not the other way around.) A data
consumer either has to hard-code some heuristics that may not always be
accurate [3] or infer the order from the way refs, as OSRM does. [6]
There's a parallel situation with route numbers associated with a bus
stop. The route_ref=* key on the stop node makes the order explicit,
since some agencies don't sort the routes numerically on signage.
* The destination:ref=* key uses the same prefixed syntax as way refs.
No structured alternative has been formally proposed, but
destination:network=* is common in Australia (where network=* is common
on ways) and I've begun using destination:ref:wikidata=* in some parts
of the U.S. I don't think it's too outlandish to imagine a future where
navigation software uses destination:wikidata=* to detect street names
that should be prefixed by "onto" instead of "toward" (instead of using
destination:street=*, which takes some destinations out of order) and
uses destination:ref:wikidata=* to choose the right shield to display
and the correct ref prefix to read aloud.
[1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
[2] https://github.com/gravitystorm/openstreetmap-carto/issues/508
[3]
https://wiki.openstreetmap.org/wiki/SPARQL_examples#Human-readable_route_refs
[4] https://tinyurl.com/yxk5ux8h
[5]
https://www.wikidata.org/wiki/Wikidata:Property_proposal/road_name_formatter
[6] https://github.com/Project-OSRM/osrm-backend/pull/4524
--
m...@nguyen.cincinnati.oh.us
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
