On Mon, Oct 1, 2018 at 4:31 AM Paul Norman <penor...@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. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
