[Mapcss] Development of MapCSS?

Tom Davie tom.davie at gmail.com
Sat Mar 9 10:56:00 UTC 2013

On 9 Mar 2013, at 10:39, Martin Vonwald <imagic.osm at gmail.com> wrote:

> Hi all,
> I had some thoughts lately about how to improve MapCSS.
> First I quickly compared the MapCSS specification with the JOSM
> implementation. JOSM implements a lot more than specified and many of
> them are really useful. Namely:
> * all the "symbol-" properties
> * text-anchor-....
> * dashes-....
> * The suffix casing applies to more keys than in MapCSS. Furthermore
> JOSM supports also left-casing-... and right-casing-...
> * text-halo-opacity
> * A lot more built-in functions for eval. See below for further
> comments on this.
> Most of them I have already used.

Agreed, most of these are really god, the only tricky one is left-casing and right-casing, which is hard to implement for many.

> There are also some major difference between the specification and the
> JOSM implementation:
> * z-index: MapCSS specifies this only for lines, while JOSM interprets
> this for all objects. The latter makes much more sense IMO.


> * text-offset is also supported as text-offset-y in JOSM; furthermore
> there is a property text-offset-x, but I don't really can think of a
> use-case for this.

Personally what I'd like to see is the user being able to specify label placement techniques, and methods of deciding priority on labels.  That is, if they want to see the names of minor roads – let them, it shouldn't be up to the renderer to decide that major roads are more important.

> * The child and link selectors from JOSM seem to be the combining
> selectors from MapCSS. Parent selectors are missing from MapCSS (I
> think). In my opinion the syntax of JOSM for child and link selectors
> is better readable than the combining selectors of MapCSS.

The problem here is that parent selectors are nearly impossible to implement efficiently.  Child selectors are hard enough in themselves.  Without these two, you can cache common cases for sets of tags (e.g. you can cache the style used for a node with no tags at all on it).  As you can imagine, that saves a lot of processing.  With these two, you have no ability to do this any more, as you need to check each and every empty node's parents for tags too.

> * In MapCSS the testing for truth values is not specified, e.g.
> way[oneway?], which comes in handy quite often.

Yes and no – personally, I'd like to see MapCSS tighten up it's typing much more.  We need to bin the everything is a string philosophy.  Here, I would much rather see a "function" bool(someValue) which interprets a string as a boolean (a well specified one too, not just "uhhh, make up which of '1', 'yes', 'true' and 'oui' are true and what's false").

> * The MapCSS specifications seems to lack the property "offset" from
> JOSM, which moves the line left or right. This is a very important
> property!

I'm not convinced I can think of a use case for it, but if you say so.

> Improvements needed to process data:
> Obviously from the number of built-in functions in JOSM there is a
> strong need of more processing capabilities. Arrays, loops, nested if
> statements are just a few of them. As I'm not really a fan of
> reinventing the wheel again and again I want to suggest something and
> hear your opinions. Here's an example which should make clear what I
> have in mind:

No, the design philosophy here is entirely wrong.

MapCSS is a declarative language.  That means, you say "given this input, the result is this", not "to compute the result from this input do this then this then this".  This has significant benefits to implementors, and to clarity of stylesheets.  If you want to invent MapJavascript, do so, but MapCSS is not the place to put it.

For reference, OpenStreetPad already supports nested selectors, allowing you to do things like this (in a declarative form):

  z-index: -5;
    fill-image: url("fills/military.png");
    width: 3pt;
    color: rgb(1.0, 0.46, 0.47);



Tom Davie

More information about the Mapcss mailing list