The more I delve into trying to find a good generic way of handling OSM relations in Maperitive, the more I get the feeling it’s a waste of effort. Relations are just too abstract and require some implicit (and external) semantic knowledge for a map renderer to be able to handle them properly.
Example? Look at multipolygon relations on the OSM wiki. They contain a lot of external knowledge that would be very difficult to codify in a map rendering language. I’ve designed Maperitive’s rendering language to be small & simple to use and I want to avoid creating a more general-purpose language out of it. We already have too many languages.
OK, multipolygons are just one example, and maybe not a good one. You can always say multipolygons are exception and should be treated as such by embedding the semantics directly in the code of the renderer. And I agree, and that’s what I did. But more and more people come up with new types of relations and I don’t want Maperitive to become bloated with all kinds of special cases. I strongly believe in Maperitive as a general-purpose renderer (and not only for OSM-type data).
So what’s the solution? I’m not sure yet. For the last few days I’ve been toying with the idea of providing some kind of Python scripting extension for rendering which would enable users to write custom logic for all kinds of special cases without the need to extend the rendering rules language.
It would probably not be as fast, but if you value the custom rendering features above performance, it could be a good solution.
