On 5/28/2017 12:25 PM, Hartmut Holzgraefe wrote:
I'd also be interested in the implications of the upcoming changes
as I'm currently running many different styles from the same
--hstore-all import, some of them using the OpenStreetMap Carto
style osm2pgsql tables directly, some using views based on these
instead to add extra columns not available in the base tables.
Would this still be possible with 4.0 style tables, plus an extra
set of views mapping hstore entries to the old v3 layout, or will
there be more substantial changes so that I have to start planning
for maintaining old and new style imports in parallel to be able
to continue using styles based on the older layout?
The OpenStreetMap Carto schema is not backwards or forwards compatible
with osm2pgsql defaults. You can emulate the column differences with
views, but you will find some features difficult to emulate. If I had to
pick a way, I'd import with the OpenStreetMap Carto schema and use views
to emulate the standard osm2pgsql schema. An example of why is
osm-carto's layer column being an integer. This is easy to turn into
text if you don't care about the loss of non-integer layer data (which
is an error), but harder to convert the other way.
The big changes in the schema that are difficult to emulate are
1. different roads table values
2. different z_orders
3. no old-style multipolygons
4. layers are integers
5. different decisions on what is a polygon or linestring
For most purposes osm-carto's decisions will be fine with other styles,
but reverse is not true.
The different columns in the .style file are easy to convert, but fairly
verbose. To use the osm-carto schema of osm2pgsql -G --htore --style
openstreetmap-carto.style --tag-transform-script openstreetmap-carto.lua
as if it were osm2pgsql --prefix foo -G --htore --style default.style
you would need views like
CREATE VIEW foo_point AS
SELECT
osm_id,
access,
tags->'addr:housename' AS "addr:housename",
tags->'addr:housenumber' AS "addr:housenumber",
tags->'addr:interpolation' AS "addr:interpolation",
admin_level,
aerialway,
...,
z_order,
(tags - ARRAY['addr:housename', 'addr:housenumber',
'addr:interpolation', ...]) AS tags
way
FROM planet_osm_point;
This is not supported, so you'll have to figure out the details
yourself. I recommend writing a script that reads in two osm2pgsql
.style files.
If you want to do the reverse conversion, you'll need a UNION ALL in the
line and polygon tables. e.g.
CREATE VIEW planet_osm_polygon AS
SELECT
...,
way
FROM foo_polygon
WHERE NOT (man_made IN ('embankment', 'breakwater', ...) OR natural
IN ('cliff', ...) OR ...)
UNION ALL
SELECT
...,
ST_MakePolygon(way) AS way
FROM foo_line
WHERE ST_IsClosed(way) AND (NOT tags ? 'area' OR tags @> 'area=>yes')
AND (higway IN ('services', ...) OR ...);
You'll also need to handle z_order, layer, roads, etc.
All the queries here have been written without testing so may need
adjustment, and performance and indexes will be difficult.
_______________________________________________
dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/dev
