[Talk-us] While we're fixing things in iterations

[Minh Nguyen]

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

-- 
minh at nguyen.cincinnati.oh.us