On Sat, Sep 29, 2018 at 8:41 PM Kevin Kenny <kevin.b.ke...@gmail.com> wrote:
> On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson <ba...@ursamundi.org> 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. > It still feels a bit brittle, especially if the data consumer is assuming (correctly) that nodes by themselves lack a direction. Which is fine when the traffic control applies to all possible ways and approaches connected to a node. A relation does explicitly define how it applies, however, by defining which nodes are affecting which ways and how without having to make a lot of assumptions. > 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.) > I don't see a regression in some downstream application as being a reason not to do it. > 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. Osmand handles it fine. > 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. > Doing good work there, fixing the problem.
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
