[Potlatch-dev] Stylesheets (Potlatch 2/Halcyon)

[Jeffrey Warren]

Hi Mike, thanks for your insights -

I'll follow up with more in depth comments, but just to add some more info
on the GSS/JSON thought process - we've struggled with trying to create a
format which is terse as well as familiar to users of CSS, while remaining
parse-able by JSON interpreters. While using "foo": {} would indeed be
better JSON, we felt that requiring quotations adds unnecessary (speaking
pragmatically) syntax.
Still, we've been considering moving to quoted 'selectors' so we can support
CSS-isms like "#foo" and ".bar" - separating perhaps true selectors such as
'way' from those which act more like CSS classes, and are based on OSM tags.
We could simply allow those, and filter them before attempting JSON eval,
but we'd like GSS to be natively parse-able without filters.
What's interesting is that when applied to the map features themselves,
Cartagen by default runs the function attributes once, and stores that
static value for use by the renderer. To re-reun for a dynamic style, users
must set a refresher, say, every second, or every minute. This is to
encourage designers not to recalculate their styles every frame unless they
really want to.

The JSON spec does not in fact describe function attribtues; that we are
doing so takes advantage of a JavaScript feature, not a JSON
convention. This suggests that for purposes of translation, we could flatten
GSS into a static format.

I'll follow up later with some more thoughts, but I'd say that this
discussion is very productive even if convergence turns out to be somewhat
premature. Thanks!

Jeff



On Sun, Aug 9, 2009 at 3:34 PM, Michal Migurski <mike at stamen.com> wrote:

> Late chiming in to this, hello again Jeff.
>
> I just wanted to throw in a few cents on the separation of
> presentation, language, behavior, etc.
>
> GSS, as described at http://wiki.cartagen.org/wiki/show/GssUsage, is
> *not* valid JSON. Valid JSON object keys are quoted, while the GSS
> examples are not. E.g., 'way: { ... }' is not valid JSON but '"way":
> { ... }' is. This and other Javascriptisms in GSS such as dynamic
> styles and function literals could prove to be a limiting factor for
> GSS, tying it much too closely to a browser-based execution
> environment. I'm being a little nitpicky with this but I think it's
> important to define the outer bounds of what GSS provides so that it
> can more effectively cross over to other media. Right now, for
> example, it seems impossible to use GSS for printed maps. Ideally, the
> scope of GSS would be similar to that of CSS (which I've used as a
> guide for Cascadenik) with its own syntax and a clear separation from
> content/markup and behavior/scripting.
>
> Would you be open to developing an object and behavior model for GSS
> that makes the dynamic, digital, browser-based interaction model more
> clear? It might be worth looking at some of the work on object models
> being done by the HTML5 group for some guidance here.
>
> The SLD thing is frustrating, partially because it's in XML but mostly
> because it has no provision for a cascade or any sense of objects on
> the map having a classification. (at least I think it doesn't, OGC
> wants me to accept a clickthrough license to read the spec and the
> HTTP response is timing out)
>
> As Richard says in a message today, the style description should be
> "just" an interchange format. However, it does need to have some sense
> of the object domain it's operating on, which currently is very
> closely tied to each target environment: Mapnik wouldn't know what do
> with function literals, while Cartagen lacks a complete labeling
> feature. Cascadenik only allows Mapnik's "Layer" and "Map" element
> names in selectors while GSS seems to like "way" and "building" and
> others.
>
> I guess I'm mostly saying that I'm not sure these different projects
> are yet ready for convergence, since they're all still dealing with
> different unmapped territories.
>
> -mike.
>
> On Aug 3, 2009, at 9:54 AM, Jeffrey Warren wrote:
>
> > Just saying hello from the Cartagen project; we're planning to alias
> > Cascadenik style names, if not pure CSS formatting. We use a JSON
> > format for somewhat expanded capabilities, but we give up a lot of
> > flexibility on naming selectors. I.e. we cannot use tag names that
> > include '=' or '.' or a wide range of other characters. JSON does
> > allow these to be used in quotations. (and JSON is part of core AS3,
> > i believe)
> >
> > There was a good discussion on the scope of stylesheet selectors at
> > wherecamp 09 where there was some debate on whether or not a
> > separation of content and presentation was as clear cut with map
> > stylesheets. The consensus was 'not'.
> >
> > Sorry to drone on but stylesheets are being used in more and more
> > renderers and some convergence (dare we say even standards!) would
> > be great. Our GSS usage page is here:
> http://wiki.cartagen.org/wiki/show/GssUsage
> > .
> >
> >
> > That said, there are standards for style descriptions, though
> > they're really human-readable:
> http://www.opengeospatial.org/standards/sld
> >
> >
> > Best,
> > Jeff
> >
> >
> >  On Thu, Jul 23, 2009 at 1:40 AM, Richard Fairhurst <richard at
> > systemed.net>wrote:
> > > I spent an hour or two looking at the Flash Camouflage CSS parser
> > (> http://flashartofwar.com/2009/02/05/camo > ’s-css-parser/). It's
> > pretty good, so the actual logistics of> converting CSS to Halcyon's
> > internal rendering engine aren't looking> too hard.[1] >> What I'm
> > still unsure about is what the selectors should describe.>> Option 1
> > is basically to write them as tests on OSM tags. So something > like
> > this:>>        highway=primary,oneway=yes { color: red; }>
> > highway=motorway[z10-z15] { color: blue; width: 2px; } >> Option 2
> > is to separate the OSM tag parser from the CSS style names.> So
> > you'd have:>>        primary_oneway { color: red; } >> and something
> > somewhere else in the file would define that>
> > highway=primary,oneway=yes would use the primary_oneway style. >>
> > Option 2 is more 'pure CSS'-like but is another layer of
> > abstraction> for people to get their heads around.> > I'm torn.
> > Advice from wise folk would be welcome. :)>
> >
> > Do the simplest thing possible that works!
> > I'd go with tests on tags directly, you can always add extra syntax
> > toabstract them out later if you decide it's needed.
> >  Dave
> >
> > _______________________________________________
> > Potlatch-dev mailing list
> > Potlatch-dev at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/potlatch-dev
>
> ----------------------------------------------------------------
> michal migurski- mike at stamen.com
>                  415.558.1610
>
>
>
>
> _______________________________________________
> Potlatch-dev mailing list
> Potlatch-dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/potlatch-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/potlatch-dev/attachments/20090809/254fa219/attachment.html>