[Tagging] Traffic sign direction tagging..
baloo at ursamundi.org
Tue Oct 2 02:48:33 UTC 2018
On Sat, Sep 29, 2018 at 8:41 PM Kevin Kenny <kevin.b.kenny at gmail.com> wrote:
> On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson <baloo at 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging