On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson <[email protected]> wrote: > I'm still against using forward/backward on nodes, it really feels like a > hacky way to avoid using a relation (up there with using ref=* on ways to > describe routes), which would disambiguate things without being so brittle > just because a way reversed, and handle more complex situations like "right > turn permitted without stopping" sign below a "stop" sign, or allow a data > consumer to be able to display a diagram indicating which ways a stop applies > to (handy if you encounter, say, a six way intersection with a four way stop). > > I honestly don't understand why, ten years since it's introduction as OSM's > third basic primitive, there's still this weirdly unnatural aversion to > relations, even though they're quite a powerful primitive in our toolbox.
I agree with you that we need to design relations for the complex cases such as what you describe, but I've no problem with the 'hacky' approach as well - on the principle of 'make simple things easy and complex things possible'. JOSM (and from what I understand, iD, but I rarely use it) handles directional nodes on ways fairly competently, detecting that the mapper is reversing a way that has such nodes attached and asking what to do about them. As far as the aversion to relations goes, I think a big part of it is simply that the downstream support just isn't there. The tools do multipolygons fairly well, but that is the only relation that is really handled well. A bit part of that is that once OSM data has been through a stock osm2pgsql, there are no relations any more. Multipolygons become first class objects, and all other relations are handled at best by devolving their tags upon their components. (The rest of this message is off the topic of stop signs.) You raise the issue of ref=* on ways, and why we still use it. That's a clear case where we use it because the downstream systems can't do route relations. I've been trying to help with this - at least to the extent of trying to revive Phil! Gold's route relation processing. My version is at https://github.com/kennykb/osm-shields, and you can see one rendering with shaped shields based on relations at https://kbk.is-a-geek.net/catskills/test4.html?la=42.7440&lo=-72.4830&z=11. That link is chosen to illustrate an area that intermixes 'tag on way' with 'tag on relation'. Unfortunately, my time is limited, so the project has stagnated for a few weeks. I've not given up, though; the next task will have to be to generate a pull request to adapt osm2pgsql optionally to preserve relations, with two new tables to track them. Alas, I don't have much hope that the pull request will be accepted. I've asked the upstream developers several times if they could possibly review the proposed functionality (I've at least a draft at a formal proposal - https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql) so that I can know whether I'm entirely wasting my time. I've heard nothng but silence. This silence is understandable. The developers are very, very busy, with much more urgent issues to address. I've not yet advanced the idea far enough to merit their attention. But at some point, I will have to conclude that further advances will simply cost me too much in time and money to be worth risking, because a likely outcome is that when I do get someone's attention, the whole idea will be dismissed out of hand. _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
