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

[Richard Fairhurst]

On holiday but couldn't resist the siren call of (Anna's) iPhone for  
this one. Don't tell the other OSM lists I'm here.

I'm interested in using @import with media types, plus dynamic  
retagging, to surmount the "different media/databases" problem.

In other words, your stylesheet proper can be very CSS-like, properly  
abstracted from the nitty-gritty of your db tables. The remapping is  
done initially by a set of rules in the @imported file.

Convergence may be hard but I'd hope that, as a minimum, we don't do  
anything that might close it off in the future. There's already a  
bunch of OSM-related projects (Kosmos and mkgmap are two that spring  
to mind) which could really do with a simple, near-universal styling  
language. The time is right.

Must go, cider and chocolate cake are calling.

cheers
Richard

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