Hi, On 04.10.2018 00:20, Kevin Kenny wrote: > The schema as given by 'osm2pgsql' has first-class relations only in the > 'rels' table, which is one of the 'slim' tables. The maintainers > deprecate using those in the strongest possible terms.
Well, "strongest possible terms" is perhaps not the most fitting summary of https://github.com/openstreetmap/osm2pgsql/issues/230... as has been said there, quite a few people "mis"use osm2pgsql in that fashion, and if they ever were to introduce a breaking change you can simply stick with the osm2pgsql that you have... But answering your question about alternatives: * I have successfully used imposm3 to populate planet-wide databases and keep them current with diffs, and the overall performance was sligthly better than osm2pgsql's (with imposm having some features that osm2pgsql doesn't and vice versa), but what osm2pgsql does with its planet_osm_rels table imposm does with a file-based database and I have no idea how difficult it would be to establish your first-class relation table. * The "PG Snapshot" schema used by Osmosis provides an interesting concept of an "action" table which is filled upon the application of a diff and allows you to run arbitrary code on newly-added or modified things in the course of an update. The performance of Osmosis is, however, far worse than osm2pgsql or imposm in my experience, and the PG Snapshot schema is probably much too close to "raw OSM" for a mainly rendering use case. * If I wanted to achieve what you describe, I would likely either modify osm2pgsql to do what I want, or run stock osm2pgsql and devise a *separate* process, likely based on (py)osmium, that extracts the information I need from a planet file or diff, and somehow adds that to my PostGIS database. That way, I would continue to be able to use osm2pgsql for what it does best, and I could still add my special processing on top. Since my special processing is likely to only need a fraction of the data, and osmium is quite efficient at filtering, the risk of running into performance issues should be limited. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
