Added this:
http://geoserver.org/display/GEOS/Styling+maps+with+CSS
If anybody wants to comment or add details it would be
nice.
Mentor wise I could be the point person for the SLD
side of the fence, but a web designer is kind of
a required complement as I'm certainly no expert
at CSS.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hmmm... The standards work would be good, but I was imagining that implementing the parser in javascript would be better. Parse from the language in to OL Style objects, which can then be persisted out as SLD objects for GeoServer. GS would still use SLD through and through. Doing things this way also gets us the ability to do real time previews on the client side, without GS having to do the rendering. Are there other advantages to a java parser that I'm missing?
Andrea Aime wrote:
Added this:
http://geoserver.org/display/GEOS/Styling+maps+with+CSSIf anybody wants to comment or add details it would be
nice.
Mentor wise I could be the point person for the SLD
side of the fence, but a web designer is kind of
a required complement as I'm certainly no expert
at CSS.Cheers
Andrea
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Chris Holmes ha scritto:
Hmmm... The standards work would be good, but I was imagining that implementing the parser in javascript would be better. Parse from the language in to OL Style objects, which can then be persisted out as SLD objects for GeoServer. GS would still use SLD through and through. Doing things this way also gets us the ability to do real time previews on the client side, without GS having to do the rendering. Are there other advantages to a java parser that I'm missing?
Hmmm... if you're thinking to have a UI on top of this, then it makes
not much sense, since a UI is there to hide the underlying storage
anyways.
CSS based styling idea is there to have web designers work on the
CSS directly, and in that case, turning it into SLD to be
posted on the server side does not look great, as we'd have to
translate back and forth between the two ways of expressing a style,
and possibly loose the CSS on the way along with comments that
the web dev embedded in it.
I mean, if you post the SLD to the server, where do you store the CSS?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Fri, 2009-03-20 at 11:53 +0100, Andrea Aime wrote:
Chris Holmes ha scritto:
> Hmmm... The standards work would be good, but I was imagining that
> implementing the parser in javascript would be better. Parse from the
> language in to OL Style objects, which can then be persisted out as SLD
> objects for GeoServer. GS would still use SLD through and through.
> Doing things this way also gets us the ability to do real time previews
> on the client side, without GS having to do the rendering. Are there
> other advantages to a java parser that I'm missing?Hmmm... if you're thinking to have a UI on top of this, then it makes
not much sense, since a UI is there to hide the underlying storage
anyways.CSS based styling idea is there to have web designers work on the
CSS directly, and in that case, turning it into SLD to be
posted on the server side does not look great, as we'd have to
translate back and forth between the two ways of expressing a style,
and possibly loose the CSS on the way along with comments that
the web dev embedded in it.
I mean, if you post the SLD to the server, where do you store the CSS?Cheers
Andrea
My 2 cents worth: it's valuable to expose the css source to web
designers; sometimes things are just easier in text mode (says the cli
junkie). It's probably possible to ensure a 1:1 mapping between CSS and
SLD, especially if that's taken into account throughout the design
process.
Anyway, just wanted to comment that I have a couple of hundred lines of
javacc written toward CSS support in geotools, so I'd be happy to
(co?)mentor this one.
--
David Winslow
OpenGeo - http://opengeo.org/
David Winslow ha scritto:
On Fri, 2009-03-20 at 11:53 +0100, Andrea Aime wrote:
Chris Holmes ha scritto:
Hmmm... The standards work would be good, but I was imagining that implementing the parser in javascript would be better. Parse from the language in to OL Style objects, which can then be persisted out as SLD objects for GeoServer. GS would still use SLD through and through. Doing things this way also gets us the ability to do real time previews on the client side, without GS having to do the rendering. Are there other advantages to a java parser that I'm missing?
Hmmm... if you're thinking to have a UI on top of this, then it makes
not much sense, since a UI is there to hide the underlying storage
anyways.CSS based styling idea is there to have web designers work on the
CSS directly, and in that case, turning it into SLD to be
posted on the server side does not look great, as we'd have to
translate back and forth between the two ways of expressing a style,
and possibly loose the CSS on the way along with comments that
the web dev embedded in it.
I mean, if you post the SLD to the server, where do you store the CSS?Cheers
AndreaMy 2 cents worth: it's valuable to expose the css source to web
designers; sometimes things are just easier in text mode (says the cli
junkie). It's probably possible to ensure a 1:1 mapping between CSS and
SLD, especially if that's taken into account throughout the design
process.Anyway, just wanted to comment that I have a couple of hundred lines of
javacc written toward CSS support in geotools, so I'd be happy to
(co?)mentor this one.
Did you look in any of the existing Java based CSS parsers?
There are three around, I linked a page in the proposal that
has a list.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Fri, 2009-03-20 at 16:46 +0100, Andrea Aime wrote:
David Winslow ha scritto:
> On Fri, 2009-03-20 at 11:53 +0100, Andrea Aime wrote:
>> Chris Holmes ha scritto:
>>> Hmmm... The standards work would be good, but I was imagining that
>>> implementing the parser in javascript would be better. Parse from the
>>> language in to OL Style objects, which can then be persisted out as SLD
>>> objects for GeoServer. GS would still use SLD through and through.
>>> Doing things this way also gets us the ability to do real time previews
>>> on the client side, without GS having to do the rendering. Are there
>>> other advantages to a java parser that I'm missing?
>> Hmmm... if you're thinking to have a UI on top of this, then it makes
>> not much sense, since a UI is there to hide the underlying storage
>> anyways.
>>
>> CSS based styling idea is there to have web designers work on the
>> CSS directly, and in that case, turning it into SLD to be
>> posted on the server side does not look great, as we'd have to
>> translate back and forth between the two ways of expressing a style,
>> and possibly loose the CSS on the way along with comments that
>> the web dev embedded in it.
>> I mean, if you post the SLD to the server, where do you store the CSS?
>>
>> Cheers
>> Andrea
>>
>
> My 2 cents worth: it's valuable to expose the css source to web
> designers; sometimes things are just easier in text mode (says the cli
> junkie). It's probably possible to ensure a 1:1 mapping between CSS and
> SLD, especially if that's taken into account throughout the design
> process.
>
> Anyway, just wanted to comment that I have a couple of hundred lines of
> javacc written toward CSS support in geotools, so I'd be happy to
> (co?)mentor this one.Did you look in any of the existing Java based CSS parsers?
There are three around, I linked a page in the proposal that
has a list.
Yes. However, there are a few reasons I didn't start out using one of
them:
* I wanted to learn how to use javacc (the biggest reason)
* GeoTools is already using javacc; it's not already using a css parsing
library afaik
* I don't think standards-compliant CSS is going to suffice if we want
to match SLD's capabilities. CSS3 seems to be focused on text
documents, with no analog for BBOX, PropertyIsBetween, filter functions,
etc.
Anyway, my code may not be that useful (there is a reason I haven't
mentioned it by now) but I'd still be up for mentoring this project.
--
David Winslow
OpenGeo - http://opengeo.org/
Cheers
Andrea
David Winslow wrote:
On Fri, 2009-03-20 at 11:53 +0100, Andrea Aime wrote:
Chris Holmes ha scritto:
Hmmm... The standards work would be good, but I was imagining that implementing the parser in javascript would be better. Parse from the language in to OL Style objects, which can then be persisted out as SLD objects for GeoServer. GS would still use SLD through and through. Doing things this way also gets us the ability to do real time previews on the client side, without GS having to do the rendering. Are there other advantages to a java parser that I'm missing?
Hmmm... if you're thinking to have a UI on top of this, then it makes
not much sense, since a UI is there to hide the underlying storage
anyways.CSS based styling idea is there to have web designers work on the
CSS directly, and in that case, turning it into SLD to be
posted on the server side does not look great, as we'd have to
translate back and forth between the two ways of expressing a style,
and possibly loose the CSS on the way along with comments that
the web dev embedded in it.
I mean, if you post the SLD to the server, where do you store the CSS?Cheers
AndreaMy 2 cents worth: it's valuable to expose the css source to web
designers; sometimes things are just easier in text mode (says the cli
junkie). It's probably possible to ensure a 1:1 mapping between CSS and
SLD, especially if that's taken into account throughout the design
process.
Well, I was thinking they'd basically operate in a text mode type way, but in a panel in the Styler app, where their changes to the css would be applied instantly.
I guess the one thing that wouldn't work well with the full javascript side would be capture the comments.
But then again the only way to keep the comments if you're doing it in java is to actually store the css file in the data dir, which seems a bit nasty to me, to have two different persistence formats for styles. Or else you again lose the comments
I imagine cascadenik probably loses comments. I don't think the idea behind this is really to make it a CSS thing used up and down in our system. I think it's to give designers a way in to styling maps that they're more comfortable with. The concepts are still going to be a bit different, our goal isn't to give them CSS, it's to give them a css like language and rules to explore these concepts, imho.
C
Anyway, just wanted to comment that I have a couple of hundred lines of
javacc written toward CSS support in geotools, so I'd be happy to
(co?)mentor this one.--
David Winslow
OpenGeo - http://opengeo.org/
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Chris Holmes ha scritto:
But then again the only way to keep the comments if you're doing it in java is to actually store the css file in the data dir, which seems a bit nasty to me, to have two different persistence formats for styles. Or else you again lose the comments
Yep, that's the plan, have different storage formats for styles.
I imagine cascadenik probably loses comments.
Imagine again 
If you want to use Mapnik you have to program in
Python, it's not visual like GeoServer, is meant to be used as a
library, they give you python bindigs, not a visual config
enviroment.
So you write the css by hand and point your python
script to them.
From the mapnik guide, the very first tutorial is:
GettingStarted -- 'Hello,world!' using pure Python bindings.
(http://trac.mapnik.org/)
And from the very home page, "Getting started: 1) download the sources!"
When that is your starting point writing a CSS file is a piece
of cake. In fact, from a reference on the internet:
"Michal Migurski has build a CSS-style equivalent which _compiles_ down to XML, hopefully making it much quicker and easier to get started with Mapnik customisation"
http://simonwillison.net/2008/Aug/30/cascadenik/
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Chris Holmes ha scritto:
But then again the only way to keep the comments if you're doing it in java is to actually store the css file in the data dir, which seems a bit nasty to me, to have two different persistence formats for styles. Or else you again lose the comments
Yep, that's the plan, have different storage formats for styles.
Huh. Yeah, I browsed that thread. Sounds like adding a good bit of complexity, to properly maintain multiple ones. I guess on the positive side that could mean we could theoretically write parsers to read like AXL files. But even that seems like it wouldn't work easily, since I don't think AXL puts each style in its own file.
And how do we make the decision which storage format to put it in? Like we flag what it's uploaded as? And then what, we provide tools to convert the backend storage format, in case people want to change that? They decide if they want to keep their comments in SLD or in CSS-like language, and the other format gets them blown away?
I imagine cascadenik probably loses comments.
Imagine again
Python, it's not visual like GeoServer, is meant to be used as a
library, they give you python bindigs, not a visual config
enviroment.
So you write the css by hand and point your python
script to them.From the mapnik guide, the very first tutorial is:
GettingStarted -- 'Hello,world!' using pure Python bindings.
(http://trac.mapnik.org/)
And from the very home page, "Getting started: 1) download the sources!"
When that is your starting point writing a CSS file is a piece
of cake. In fact, from a reference on the internet:
"Michal Migurski has build a CSS-style equivalent which _compiles_ down to XML, hopefully making it much quicker and easier to get started with Mapnik customisation"
http://simonwillison.net/2008/Aug/30/cascadenik/
Right, so it loses the comments, you have to compile down to the xml every time.
A similar 'compile down' would be when you're working with the CSS on the javascript side and then persist it to GeoServer, it puts it in to its XML (SLD) format. If a designer wants to maintain comments they can keep a version of the file, and save it to GeoServer when they want to make changes. Heck, we could even have a some part of the rest API let people put and get CSS-styles, so they'd have a nice place to save it. But when they want to apply it they save to GeoServer which stores it as its native format.
Cheers
Andrea
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Chris Holmes ha scritto:
Andrea Aime wrote:
Chris Holmes ha scritto:
But then again the only way to keep the comments if you're doing it in java is to actually store the css file in the data dir, which seems a bit nasty to me, to have two different persistence formats for styles. Or else you again lose the comments
Yep, that's the plan, have different storage formats for styles.
Huh. Yeah, I browsed that thread. Sounds like adding a good bit of complexity, to properly maintain multiple ones. I guess on the positive side that could mean we could theoretically write parsers to read like AXL files. But even that seems like it wouldn't work easily, since I don't think AXL puts each style in its own file.
We also have this ongoing thread about storing multiple styles in
a single SLD. Already two users (BC and Forward Slope) sounded
in telling it's an important feature for them.
And how do we make the decision which storage format to put it in? Like we flag what it's uploaded as? And then what, we provide tools to convert the backend storage format, in case people want to change that? They decide if they want to keep their comments in SLD or in CSS-like language, and the other format gets them blown away?
I guess the simplest idea is to just decide based on the extension
of the stored file: .css, .sld, .axl
You have a number of parsers from file to in memory GT2 Style objects,
you scan them and ask if they can handle the file, if they can,
the parse. No need for extra flags.
I imagine cascadenik probably loses comments.
Imagine again
Python, it's not visual like GeoServer, is meant to be used as a
library, they give you python bindigs, not a visual config
enviroment.
So you write the css by hand and point your python
script to them.From the mapnik guide, the very first tutorial is:
GettingStarted -- 'Hello,world!' using pure Python bindings.
(http://trac.mapnik.org/)
And from the very home page, "Getting started: 1) download the sources!"
When that is your starting point writing a CSS file is a piece
of cake. In fact, from a reference on the internet:
"Michal Migurski has build a CSS-style equivalent which _compiles_ down to XML, hopefully making it much quicker and easier to get started with Mapnik customisation"
http://simonwillison.net/2008/Aug/30/cascadenik/Right, so it loses the comments, you have to compile down to the xml every time.
It's like saying that compiling java sources into binaries
you loose the comments. The binary form does not have them anymore,
but you still have the .java around, and your reference is the source,
the binary is an accident of how java executes the code (if it was
python we'd have no binary at all).
A similar 'compile down' would be when you're working with the CSS on the javascript side and then persist it to GeoServer, it puts it in to its XML (SLD) format. If a designer wants to maintain comments they can keep a version of the file, and save it to GeoServer when they want to make changes. Heck, we could even have a some part of the rest API let people put and get CSS-styles, so they'd have a nice place to save it. But when they want to apply it they save to GeoServer which stores it as its native format.
How do you go the way back? You have a style and you want to see
what was the original format. Maybe two months later?
While debugging styles this is important, if you're forced to debug the
SLD version the CSS does not do you much good anyways.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Thu, 2009-03-26 at 09:29 +0100, Andrea Aime wrote:
How do you go the way back? You have a style and you want to see
what was the original format. Maybe two months later?
While debugging styles this is important, if you're forced to debug
the
SLD version the CSS does not do you much good anyways.
I was thinking that we could do the conversion both ways, probably in
the REST API. We're not storing the configuration in JSON either.
--
David Winslow
OpenGeo - http://opengeo.org/
David Winslow ha scritto:
On Thu, 2009-03-26 at 09:29 +0100, Andrea Aime wrote:
How do you go the way back? You have a style and you want to see
what was the original format. Maybe two months later?
While debugging styles this is important, if you're forced to debug
the
SLD version the CSS does not do you much good anyways.I was thinking that we could do the conversion both ways, probably in
the REST API. We're not storing the configuration in JSON either.
True, but CSS might be long, have comments, have a certain
structure that the designer thought up.
We do the two way conversions, comments are gone, and the
structure might as well, depending on how well the css
and the sld match from an expressiveness and structural
point of view. I mean, the CSS is hands free, could come
up with more compact ways to deal with classifications
for example.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.