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

Richard Fairhurst richard at systemed.net
Thu Jul 28 10:42:57 BST 2011

Andy Allan wrote:
> MapCSS is (somewhat pointlessly) tied up dreadfully into OSM syntax 
> with selectors based on not-quite-OSM-primitives like "relation" and 
> "way", as well as suffering hugely from the NIH syndrome when it 
> comes to having named every single attribute just slightly differently 
> from those which were already available in the mapnik/cascadenik 
> world, for no fathomable gain.

Clearly the effect of becoming a Potlatch developer is that one becomes very
skilled in spouting half-informed, half-offensive bollocks on mailing lists.

Seriously, Andy, that's way off the truth. I sincerely hope that MapCSS
_isn't_ perfect. It's young; "perfect" now means "outdated" in two years'
time. But to cite NIH syndrome is way off the mark.

As you might expect for a language called "MapCSS", the primary influence
is, well, CSS. The guiding principle is "Be CSS-like". So, when naming an
attribute, the order of preference would be pretty much:

     1. CSS
     2. internal consistency with other MapCSS attributes
     3. SVG
     4. Mapnik

That's a pretty obvious decision. There are about eight people in the world
who understand Mapnik syntax, and eight million who understand CSS. That is
why, for example, fonts are specified with CSS's "font-family" and not
Mapnik's "face_name".

Why OSM primitives rather than OGC Simple Features? Two reasons. Firstly,
because the OSM data model is the new shapefile. Because open mapping,
increasingly, means OSM data. It might not quite be 8:8,000,000 as above,
but for the non-corporate guys, it's getting that way. The people who need
an "it just works" styling language are much more likely to understand ways
and relations than MultiLineStrings and Surfaces. Yes, I did wonder about
inventing something generalised like "group", "polyline" and "point" rather
"relation", "way" and "node", but that's a bit "NIH for no fathomable gain".

Secondly, because it fits with "be CSS-like". Descending selectors map
incredibly well to OSM objects. relation>relation>way>node is trivially
expressed as a CSS selector.

AJ posted upthread that "I suppose the main thing is that Carto is not a
'map styling language' but a 'Mapnik styling language', and stays very close
to Mapnik rendering concepts, which in many ways are very different and even
incompatible with MapCSS". That's pretty much it.

Halcyon originally used YAML stylesheets which were nice in theory but
unworkable in practice. At SOTM-Amsterdam Mike Migurski encouraged me to
look at making them CSS-like instead (and not specifically Cascadenik). I
did go on to consider Cascadenik, and took a fair amount of inspiration from
it, but found that in certain specifics it was much as AJ has described
Carto - very close to Mapnik rendering concepts. That's terrific for people,
like you, who are doing really heavy-duty work with Mapnik, but not
necessarily applicable to the wider case. The fact that, so early in its
life, MapCSS is already supported by five standalone renderers, and all
three OSM editors on three different platforms (Java, Flash, and
experimentally Qt), I think validates that.


View this message in context: http://gis.638310.n2.nabble.com/Converting-OSM-Mapnik-stylesheet-to-Cascadenik-or-Carto-tp6626460p6629264.html
Sent from the Developer Discussion mailing list archive at Nabble.com.

More information about the dev mailing list