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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev