[Mapcss] another css-for-maps implementation

[David Winslow]

On Wed, Sep 29, 2010 at 3:36 AM, Komяpa <me at komzpa.net> wrote:

> Hi,
> nice to see you here too :)
>
> 2010/9/29 David Winslow <cdwinslow at gmail.com>:
>
> > From a brief perusal of the documentation on the OSM wiki, I see the
> > following major differences between my take on CSS-for-maps and MapCSS:
> > square brackets for expressions vs. eval('')
>
> Well, I'd want to explain my vision of why it's called eval() and
> better to be so.
> There are renderers in different languages, including Python,
> ActionScript, tcl, JS and so on. Hard for me to imagine something that
> will execute at roughly the same speed as native eval() in those
> environments. That's why MapCSS eval (
> http://wiki.openstreetmap.org/wiki/MapCSS/0.2/eval ) syntax was
> designed in a way that those languages can just take as-is and
> execute, providing a faster development and nice features on the cost
> of some "security issues". At least for Python there are "restricted
> eval" implementations that can't do anything except for what author
> allowed.
>
> MapCSS is not the only who does that; http://cartagen.org/ has the
> same idea in their maps language.
>
> In case someone cares a lot of security, he is free to reimplement a
> runtime for eval() expressions that won't do any harm for sure.


I understand that MapCSS has (so far) been developed with ease of
implementation in mind.  My design goals have been slightly different
(create a CSS language which exposes as much as possible of vector styling
functionality in SLD).  I have been thinking for some time about providing a
restricted filter syntax that is more CSS-like, and I like the eval()
notation as opposed to [].  Currently I am thinking about adding eval() and
cql() functions, or something along those lines, to expose the two
expression languages.  Perhaps the cql function should have a prefix like
-gt- to indicate behavior not adopted by the general mapcss community.

> repeated properties (inspired by CSS3;
> > see http://www.w3.org/TR/css3-background/#layering) vs. repeated
> property
> > lists.
>
> Nice idea. Things that stop from taking it as-is is that
> 1) we've got comma-separated lists for dashes - how to stack them?
> 2) cascading becomes somewhat undefined. i.e.:
> .... {linecap:butt,round; width: 2,3}
>  .... {width:2 }
> what color and how many lines will we get if both are applied?


1) I represent dash arrays using whitespace-separated lists, so the commas
work as usual.  Same for other list-ish properties (font-family is the only
one that comes to mind...)

2) There is a "key" property for each type of rendering:

   - "stroke" for line strokes (the stroke color/image)
   - "fill" for area fills (the fill color/image)
   - "mark" for point markers (the icon or symbol)
   - "label" for text labels

Each of these properties "activates" a particular type of rendering, so if
you specify stroke-opacity, stroke-width, and stroke-linecap, but omit
stroke itself, no lines will be rendered.  Additionally, repeated values of
these key properties activates repeated rendering.  Any "extra" values for
non-key properties are omitted; property lists that are shorter than the
"key" property list will be repeated as needed to pad out the list.
 Example:

* {
  stroke: red, blue, green;
  stroke-width: 8px;
  stroke-opacity: 100%, 80%, 60%, 40%, 50%;
}

is equivalent to

* {
   stroke: red, blue, green;
   stroke-width: 8px, 8px, 8px;
   stroke-opacity: 100%, 80%, 60%;
}



> > the concept of "well-known marks" (cribbed from GeoServer's native
> styling
> > language, SLD, see
> >
> http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/points.html#simple-point
> ),
> > basically built-in simple geometries which have their own styling
> attributes
> Nice. For now we've got only square and circle for nodes, emulated as
> if it was a zero-length horizontal line (just two linecaps near one
> another).


Well, well-known marks in SLD and thus my CSS have a couple of interesting
properties:

   - dynamic styling like normal features
   - can be used anywhere an image goes (ie, fill and stroke patterns as
   well as point markers).

This makes them a lot more flexible than static images... but also doesn't
help my case for inclusion in mapcss 0.2.


> But, seems to me that this idea (to extend that list) is probably not
> for 0.2 mapcss - 'til now it was more-or-less happily done with
> images. We still don't have a reference renderer that supports 100% of
> mapcss 0.2, though Kothic is near to that :)

--
> Darafei "Komяpa" Praliaskouski
> OSMF BY Team
> xmpp:me at komzpa.net <xmpp%3Ame at komzpa.net> mailto:me at komzpa.net
>
> _______________________________________________
> 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/20100929/c90f3fc3/attachment.html>