On Thu, Sep 24, 2020 at 3:55 AM Minh Nguyen <m...@nguyen.cincinnati.oh.us> wrote:
> 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. > Fortunately, editors will automatically fix this and make lanes=* be the total of lanes:forward=*, lanes:backward=* and lanes:both_ways=*, so this is something that isn't hard to solve long term. Hopefully when id gets lane tools, it does the same thing JOSM does in this regard. > 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. > There's no need. We already have access:lanes=* for this. Lanes are lanes, regardless of access, and it takes a very narrowly motorist-centric view in order to break this already fairly universally implemented assumption. > > 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. > Honestly it isn't that hard to include modifier=* for bannered routes (ie, Business, Bypass, Truck, Express, etc) and match against network on that to get a good starting place without having to look up the whole thing. So, for example, (using NA as an abbreviation for the fictional state of Nebrahoma), US:NA:Nebrahoma with no modifier would be easy to assume "County Route". US:NA:Nebrahoma:Nebrahoma City would be "City Route", US:NA:Business with modifier=Business would be "State Business Route"... > * 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. > Perhaps we can get some insight from Osmand. > * 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. > There's destination relations, and they're implemented in JOSM, but I don't currently know of any consumers, and id breaks them. Also I'm *really* opposed to the idea that we should be making our dataset implistically dependent on Wikidata or any other dataset outside OSMF's purview. This is how shit breaks badly when the other project goes away. Note that I'm not opposed to links to wikidata existing, but more on the context of "Here's a rabbithole of information if you care", just opposed to "Here's this external data source that you need to use in order for this data within OSM to make sense".
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
