[OSM-dev] Questions regarding carto 4.0 release and German style fork
penorman at mac.com
Sun May 28 20:59:12 UTC 2017
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
tags->'addr:housename' AS "addr:housename",
tags->'addr:housenumber' AS "addr:housenumber",
tags->'addr:interpolation' AS "addr:interpolation",
(tags - ARRAY['addr:housename', 'addr:housenumber',
'addr:interpolation', ...]) AS tags
This is not supported, so you'll have to figure out the details
yourself. I recommend writing a script that reads in two osm2pgsql
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
WHERE NOT (man_made IN ('embankment', 'breakwater', ...) OR natural
IN ('cliff', ...) OR ...)
ST_MakePolygon(way) AS way
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.
More information about the dev