[Tagging] Traffic sign direction tagging..

Kevin Kenny kevin.b.kenny at gmail.com
Sun Sep 30 01:40:31 UTC 2018


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.

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.



More information about the Tagging mailing list