Complaint has been raised that another mapper deleted the names “left (& right) manoeuvre” from the relation, but the wiki page makes absolutely no mention of names?
My thought would be that they shouldn’t be there?
@Minh_Nguyen - your baby originally so your thoughts please? (& anybody else’s!)
Not really – I just adapted what the OSRM team had already documented on their relatively obscure wiki. By then, it was already being applied to a number of tricky situations, but I figured it wasn’t very self-explanatory. At the least, most Americans (and initially the OSRM team) have no idea where to put all the extra silent vowels in “manœuvre”.
This relation feels like an act of desperation – throwing spaghetti at the wall and seeing what sticks. As the changeset comment notes, OSRM and Valhalla already recognize the left turn without the need for this relation, so I’m not sure which “GPS” they’re attempting to optimize for. In any case, it would be inadvisable for any router to honour name for the purpose of classifying a manœuvre.
Regardless the merit, or more lack of, of the tagging per se, it has the additional issue that editors will likely break such relations at least when editing from and to members.
I can’t speak for every editor, but iD and Rapid do keep manoeuvre relations intact, despite knowing nothing about this relation type, because their from, via, and to roles resemble restriction or connectivity relations. A few other relation types get lucky in this manner.
And yeah, I wouldn’t consider this fail-safe to be a paragon of tagging elegance either. At the time the OSRM developers introduced support for the maneouvre relation type, it was seen as a less distasteful alternative to the micro-dogleg hack that other platforms like Waze rely on. They hoped to eventually reduce their reliance on maneuver relations as the OSM community figures out a less ambiguous modeling or OSRM implements more intelligent heuristics. Some of the earliest maneuver relations may no longer be necessary, but I think most of them are still functioning as crutches. And some don’t even work anyways, like this “through” maneuver resembling a scythe.
While the heuristics that (hopefully) every editor that allows geometry edits applies will likely catch this, the semantics of it are slightly different, requiring both via node and ways, and there are literally no guarantees that it will work irl.
Gesundheit. All iD does with a to/via/from relation is to prevent the user from introducing a gap in the relation. It doesn’t sort the members, but as far as I know, no one has ever specified a proper order for one of these relations, so it could sort them backwards or forwards or numerically or alphabetically and no one would care.
That wasn’t what I was referring to, but that the relation members might not be downloaded. For your run of the mill simple restriction typically not an issue as you only need the via node to be able to split from/to members correctly (which you always already have).
Right, if you’ve downloaded the from way, then inherently you’ve also downloaded the via node. One possible edge case is that it’s a maneuver relation with one or more via ways and the from way is so long that you haven’t seen the via ways yet. But it would have to be quite a long way, since iD buffers the download by a fairly generous distance. iD has occasionally gotten negative feedback about intentionally truncating restriction relations when splitting a way, but that’s one way it mitigates this issue about partially downloaded relations.