I'm looking for people's experience on software that can take data from OSM and get it into a PostGIS database for rendering and analysis. For several years, I've been using 'osm2pgsql', but I've recently 'bumped my head on the ceiling' in that I need the database to be capable of querying relations as first-class entities. 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.
My requirements are few, but apparently tough: 1. Able to import nodes, open ways and closed ways as points-of-interest, lines, and polygons, respectively, with database columns derived from the tags on those nodes and ways. 2. Able to import multipolygon relations as multipolygons in the database. 3. Able to import relations other than multipolygons in such a way that an efficient SQL query can take a single PoI, line, polygon, multipolygon or other relation, and identify all relations (or all relations of a given type) of which it is a member - along with position and role, and similarly, efficiently identify all members of the relation (or all PoI's, lines, or areas) with their positions and roles. In other words, it must be taken as given that the association between relation and member is inherently many-to-many, and the association must be traversable in either direction. 4. Able, as a current requirement, to handle continent-scale imports from GeoFabrik with daily diffs from the same source. 5. Scalable, at least in principle, to full-planet imports with minutely diffs. My current interim solution, which works well enough in the short term, is to use 'osm2pgsql' with some auxiliary processing based on the 'slim tables' to address requirement #3. I am given to understand that there are no immediate plans to change the schema of the slim tables in such a way that it would break my use case, but am warned in no uncertain terms that such a use is entirely unsupported and I should expect it to break at some time in the future. I am, to say the least, not optimistic that it is possible to develop an alternative within the osm2pgsql framework that will meet all the other constraints, irrelevant to my application, that osm2pgsql's developers face. It appears that osm2pgsql is simply the wrong tool for the job. What, then, are my alternatives? Do I, in fact, inhabit a "box with no inside", or are there alternative data import paths that I ought to be investigating? In particular, does anyone have actual experience with using any of the alternatives, and the ability to report on perfomance, scalability and stability? _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us