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

[Michal Migurski]

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