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
