[Mapcss] Development of MapCSS?

Martin Vonwald imagic.osm at gmail.com
Sat Mar 9 18:43:14 UTC 2013


2013/3/9 Tom Davie <tom.davie at gmail.com>:
>> * 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.

That's a very good point indeed.

>> * 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.

Have a look at the screenshot here:
All the lanes use the property offset.

>> 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.

Shouldn't the design philosophy be targeted at the use-cases?

> 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.

I don't want to invent MapJavascript. I - and I guess some others -
need more processing power. Why should we invent something new (did I
already mention I don't like to reinvent the wheel again?) instead of
taking something that works and add what is needed? The approach would
be fully backward-compatible, use existing code (for the javascript
interpreter) and tremendously increase the abilities of MapCSS.

Take a look at the code of the JOSM style. Doesn't this look very
1970ish? Or even 1960ish? For example the style supports eight lanes
in each direction. Why eight? Because I wrote the code for the first
lane and copied it seven times. I wouldn't use the word "elegant" for

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

Nice but too less. Where are loops and arrays? We have an increasing
number of tags that contain multiple information. For example all tags
like turn:lanes or change:lanes contain a list of properties. Some
people need to get a list of all relations attached to a way. We are
completely missing the power to process such information in an
efficient way. Of course we can increase the number of eval-built-in
functions. But I'm asking again: why reinventing the wheel?

best regards,

More information about the Mapcss mailing list