[OSM-dev] Converting OSM Mapnik stylesheet to Cascadenik or Carto

[Sarah Hoffmann]

On Sat, Jul 30, 2011 at 06:21:51PM +0200, Igor Brejc wrote:
> Great work and thanks for the detailed info.
> 
> One comment/question: from your description (using Mapnik) and from looking
> at the json_getter.py I conclude you rely Osm2pgsql DB schema. I mentioned
> earlier that I didn't want to limit Maperitive to using this flattened
> schema, but would also try to support the "original" OSM DB schema (or even
> some other derived schema). The main reason is that IMHO flattening of OSM
> data  produces some loss of information which is vital for creating high
> quality maps.
> 
> Example: Osm2pgsql flattens bus route relations into one or more chunks of
> consecutive ways. But in order to render a bus network (like this one
> http://www.harvestersway.co.uk/images/location_busmap.jpg), one would need
> to reconstruct a graph of all the bus routes, which can have several routes
> (relations) share the same way, and each relation can consist of several
> ways. So it's a many-to-many relationship, which would be difficult to
> reconstruct from this flattened schema.
> 
> So my question is: how would you go about implementing MapCSS support for an
> "original" schema, if at all? This is why I expressed concerns about
> performance, since I don't see an efficient way of fetching the data using a
> declarative map styling.

If you want to do something like a graph, you need to do heavy preprocessing
and create your own database schema anyways. It is not too difficult
to do this in a way that suits the renderer. I did something like this for
hiking.lonvia.de. The database behind the routes is a graph of hiking
relations and there is a table that defines the render style for each segment
which are then rendered with a handful of Mapnik rules. I looked into using 
a MapCSS-based renderer for that. The main obstacle with MapCSS was that it 
defines selectors that are very much tied to the osm2pgsql schema.
This could be changed by allowing selectors to be an arbitrary
string. Then you can write a generalized renderer that maps these selector 
strings to table names and the element names to columns. This should allow
to use any customized database schema you want (as well as osm2pgsql)	
as long as there is a well-defined way to get the geometry for a table 
row (and the type of geometry, for that matter).

Only the descendant operator, I would not know how to fit into this schema.
Once you do preprocessing, the notion of relation, ways and nodes in an OSM
sense is mostly discarded.

Sarah