Questions regarding carto 4.0 release and German style fork

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions regarding carto 4.0 release and German style fork

Sven Geggus
Hello,

looking at the Openstreetmap Carto 4.0  release I see two major changes
regarding the database layout.

1. We finally have hstore
2. Tags are pre-processed by a lua script.

Is there more which might be relevant for the fork?

Up till know Mapnik German style (an Openstreetmap Carto fork) has been
using an hstore-only database with no sepearte tag columns at all and a
database view emulationg the column based layout.  Upstream style has always
been usable using this approach.

With the recent introduction of hstore in upstream this setup will get more
complicated.  Especially the l10n code is currently dependent on the fact,
that all name tags are present inside the hstore column.

However this can be changed and looks like a manageable approach.

So the question I have to answer for myself now is if it would be worth the
effort working in a direction to be able to use an unchanged database layout
from upstream style.

For this reason I need to know, what the lua script is doing to make shure,
that nothing is processed in a way which will alter the appearance of my
style.

So can somebody please explain in a few words what the lua script is actually
doing?

Sorry, I am neither familiar with lua nor ist osm2pgsql interface.

I suspected it might prevent me from redering mountain paths in a different
way than footways, but as far as I can see this is not the case.

Regards

Sven

--
"Thinking of using NT for your critical apps?
                                  Isn't there enough suffering in the world?"
                   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding carto 4.0 release and German style fork

Hartmut Holzgraefe-2
On 28.05.2017 21:05, Sven Geggus wrote:

> looking at the Openstreetmap Carto 4.0  release I see two major changes
> regarding the database layout.
>
> 1. We finally have hstore
> 2. Tags are pre-processed by a lua script.
>
> Is there more which might be relevant for the fork?

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?

--
hartmut

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding carto 4.0 release and German style fork

Paul Norman
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
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding carto 4.0 release and German style fork

Paul Norman
On 5/28/2017 1:59 PM, Paul Norman wrote:
> 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.

I should add that this was a conscious decision by the osm-carto
developers, and we discussed a number of options before settling on what
we're doing as the best option.

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev