[Tagging] Traffic sign direction tagging..

Kevin Kenny kevin.b.kenny at gmail.com
Mon Oct 1 20:28:11 UTC 2018


On Mon, Oct 1, 2018 at 4:31 AM Paul Norman <penorman at mac.com> wrote:
> Could you provide a link to the osm2pgql issue tracker with the issue in question? I don't recall it, but I've been away a lot and haven't kept up with everything.

I hadn't opened a fresh ticket, because there are existing tickets
against the tools, notably

https://github.com/openstreetmap/osm2pgsql/issues/230#issuecomment-418517270
https://github.com/gravitystorm/openstreetmap-carto/issues/596#issuecomment-418518388

I also made a query to the 'tile-serving' mailing list.

The proposal can be found here:
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql

and I'm asking that comments be posted against this issue:

https://github.com/kennykb/osm-shields/issues/4

------------------------------------------------------------------------

Where I've got so far is that I have a stand-alone converter that can
produce the
tables by querying the slim tables (Yes, I understand why that's a bad idea, but
it's what I have to work with before I start bashing away at osm2pgsql, and it
at least gets me rendering. It's also a very fast way to upgrade the
tables without
having to reimport everything.)

I also have a set of stored procedures (insanely complex, but extensively
documented) for placing route markers so that Mapnik can render them, and
a topographic-map rendering that uses the placement.
http://kbk.is-a-geek.net/catskills/test4.html?la=42.7276&lo=-72.4507&z=12
shows the result. The area that I'm linking to is chosen because it has a mix
of route relations and routes tagged on individual ways, so it demonstrates
that both function.

As far as changes to osm2pgsql go, i looks as if the top-level relation table
 can be handled with fairly light mods to the pathway that imports 'point',
'line', 'polygon' and 'roads'. It essentially could use the same sort of
conversion rules for tags. The big difference is that a relation would have
no geometry.  (This similarity extends to the Lua code for filtering objects,
as well, which appears to be relatively ignorant of geometry in any case.)
The relation-member table is its own sort of object. It has no properties
other than 'role', and it must be populated for everything that's in the
relation table, so there's really no opportunity for fine control the way
we do with tagged objects; a member will either be included (because
its relation is) or not.

It's still a bit of a daunting prospect for me, because I'm not yet
intimately familiar with the code, and there doesn't appear to be
a simple 'road map' for what happens where. If your're amenable to
pull requests for simple improvements to commentary, I'll certainly
try to document what I learn as I learn it.

My understanding is that Sarah 'lonvia' Hoffmann has a very
similar structure underlying the rendering on waymarkedtrails.org,
but I've not examined her code.



More information about the Tagging mailing list