[Mapcss] MapCSS 0.2 finalization and cleanup

Peter Wendorff wendorff at uni-paderborn.de
Sat Apr 28 11:06:06 BST 2012

Am 28.04.2012 11:29, schrieb Thomas Davie:
> I like the idea, though I'm not 100% certain how the tool would call 
> out to the various renderers -- there is at least one (mine) which 
> reqires a runtime only available on one OS.
I think about the tool being written in Java (as that should be 
availlable on most OSs, I think)
The Interface to the renderers could be different
1) "server-client style": define some kind of a http request defining 
data and stylesheet, and a url and port that the renderer can support 
(would even allow to use renderers running on different OSes, like in a 
virtual machine)
2) "exec" style: define a shell command to run (slightly different 
depending on OS, but there should be libraries to do that more or less 
OS independent from Java
3) "include" style: for java implementations even running the code 
included as a jar file could work, if a common mapcss-renderer-interface 
would be implemented.

Which renderers to compare and test could be decided by the user (e.g. 
with some presets), depending on the Operating System and defined using 
a config file, that can be exchanged arbitrarily.
> I'd also toyed with the idea of having reference renderings, like the 
> CSS implementers do, but this becomes problematic without specifying 
> things like label positioning algorithms, and conflicting label choice 
> algorithms.
Sure: There may be differences, but comparing renderers does not (only) 
mean validating them. Validation is not easily possible on unspecified 
issues, and definitively not automatically possible, but thats similar 
to the needs designers have for websites: You can follow the HTML and 
CSS standards, but that doesn't make sure that the website looks good or 
even acceptable in all browsers.

That's what map designers should get at hand, I think, so that's how 
it's a useful tool for mapcss design.
For you as mapcss renderer developers it's a useful tool as you can 
compare between renderers and decide on your own, which differences are 
acceptable, and which look like a conflict according to the specs and 
common sense.

This may include judgements like: "these highways look different, but 
only, as A did not support multi-color-dotted casings, yet" or something 
like that, and that's fine, too.


> Bob
> if (*ra4 != 0xffc78948) { return false; }
> On 28 Apr 2012, at 10:25, Peter Wendorff wrote:
>> Hi.
>> I'm not inside MapCSS-Developing currently, but what do you all think 
>> about the idea of implementing a "mapcss test center".
>> It's a idea that came to my mind while reading the last messages on 
>> the list, so probably it's a bad one, but who knows...
>> I guess, all mapcss implementations should be able to take
>> 1) a mapcss file or string
>> 2) map data (not sure, if here osm.xml is or easily could be a common 
>> base format)
>> and produce an image out of that.
>> What about implementing this into e.g. a java toolkit (java, because 
>> it's running on any major OS usually), that enables the user to
>> - write a mapcss-style
>> - get rendering results of all registered renderers
>> This could be used
>> 1) to check rendering results
>> 2) to compare renderings and identify compatibility problems (between 
>> implementations and compared to the "standard")
>> 3) as a design tool for style designers, including mapcss validation, 
>> probably giving hints or helping with "shortcomings" like the idea 
>> proposed by Thomas about nesting rules - as the tool could give an 
>> option for "make more specialized rule".
>> Just an idea - even if I don't have time to work on it.
>> regards
>> Peter
>> Am 28.04.2012 10:59, schrieb Kom?pa:
>>> Hello everyone,
>>> We all know everyone is willing to make their renderer the best one.
>>> Everyone has own purpuose - some are targeting on speed, some are
>>> willing to provide good editing experience, some want to just show
>>> something to the user...
>>> So, what do I propose:
>>> 1. Count and list active renderer developers. Those who really have
>>> time to fix minor things and want to have a badge "Supports MapCSS 0.2
>>> final".
>>> 2. Set up a deadline. Something real, like 1st of June (or July),
>>> 2012, when a spec will be marked "final", and all things post this
>>> date will go to further versions/extensions/discussions.
>>> 3. Chop the current draft to really really basic things. As we see,
>>> almost noone supports extrude, not everyone has support for eval(),
>>> .pseudoclasses aren't widely used, shields aren't implemented in most
>>> software, set and exit; ...
>>> So, we make a list of core features that everyone supports or will be
>>> able to support in the nearest time.
>>> 4. Split all the stuff that's chopped from 0.2 spec into some separate
>>> features for further discussion.
>>> 5. Draw beautiful badges "Powered by MapCSS" for sites and renderers.
>>> Are there any supporters for this initiative? :3
>>> Why:
>>> Lately, I've tried to make a stylesheet that will look the same in
>>> kothic, komap, potlatch and josm, and wasn't able to do it, because
>>> even basic things like casing-width are handled differently in all of
>>> these.
>>> I just want to have a strict subset of MapCSS that will work
>>> everywhere for sure. :3
>> _______________________________________________
>> Mapcss mailing list
>> Mapcss at openstreetmap.org <mailto:Mapcss at openstreetmap.org>
>> http://lists.openstreetmap.org/listinfo/mapcss
> _______________________________________________
> Mapcss mailing list
> Mapcss at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/mapcss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/mapcss/attachments/20120428/b51f6aca/attachment-0001.html>

More information about the Mapcss mailing list