[OSM-dev] Questions regarding carto 4.0 release and German style fork

Paul Norman 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
   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.



More information about the dev mailing list