On Fri, Mar 4, 2011 at 12:51 PM, Charles Galpin <[email protected]> wrote:
>
> On Mar 4, 2011, at 10:37 AM, David Winslow wrote:
>
> On Fri, Mar 4, 2011 at 10:26 AM, Charles Galpin <[email protected]> wrote:
>
>> David, it appears to work ok, but I have run into two issues so far
>>
>> 1. When I used a layer based off a sql view, the data tab didn't show
>> attributes from a join. I have not tried to see if I can use this layer
>> regardless, but thought I'd point that out.
>>
> This sounds like something I can/should fix, could you file a bug report so
> I don't forget about it?
>
>
> Certainly, GEOS-4412. I have confirmed it has no effect on the preview or
> styling, just the data tab, but since this module generates SLD that makes
> sense.
>
Thanks. Since you created this ticket you should receive updates when I
start working on it (warning - it may be a while).
> 2. Using a select of [data_type != 'Historical'] I get the error
>> "Constructor function not defined at data_type != 'Historical'". I can
>> do [data_type = 'Historical'] though.
>>
> The selectors use CQL syntax - see
> http://docs.codehaus.org/display/GEOTOOLS/ECQL+Parser+Design . Your filter
> should work if you use [data_type <> 'Historical'].
>
>
> Ok, I saw that it was CQL but then kept reading and the filter syntax page
> lists this as a valid operator
>
> http://docs.geoserver.org/stable/en/user/community/css/filters.html
>
>
Do you want a bug report for docs? I want to say some of the style values
> are missing too, like round for a stroke-linecap property value.
>
> http://docs.geoserver.org/stable/en/user/community/css/properties.html
>
Yes, bug reports for docs are great. If you are feeling particularly helpful
you can even create a patch and attach it to the ticket - we maintain the
manual in a simple text markup format in SVN just like the source code for
GeoServer. There's more info on contributing to the docs here:
http://docs.geoserver.org/latest/en/docguide/
> Oh, Initially using <> was giving errors, but the css inheritance
> effectively allows me to not need it. I Just went and tried and it worked,
> so not sure what I was doing wrong earlier.
>
>
>
>> But very much liking this so far if I can get my rules implemented!
>>
>
> Excellent, keep me posted :)
>
>
> This tool is AWESOME in every respect.
>
> 1. You get immediate feedback on syntax errors and generated SLD
> 2. When you submit you get a preview
> 3. I went form 1500 lines of xml to 75, over 10 of which are comments :)
>
> I would be great if this became a more integrated part of Geoserver. The
> only thing missing right now is that you don't get any indication on the SLD
> Style editor page that you have a css style defined for this style, but I
> assume this would require a core change. But if this were a core feature you
> could switch between the standard editor and the css one.
>
Yes, this would be nice. Currently it's much easier for extensions to add
new pages to GeoServer than to modify the behavior of existing ones, but I
think a specific extension point for alternative style editors would be
feasible. In core, we're still working the kinks out of supporting multiple
SLD versions in the same GeoServer; hopefully that work will lay some
groundwork for a better integrated CSS extension. (In my unwritten roadmap
the order is something like - support CSS_BODY as an alternative to SLD_BODY
in GetMap requests, make GeoServer aware of the CSS files so it warns you
before editing the 'raw' SLD.) Switching back and forth between editable
CSS and SLD views of the same style is complicated since they are so
different - but that is a bridge we can cross when we come to it.
Anyway, thanks a lot, this is going to make maintenance of styles so much
> easier. And with the more compact notation I can do things like increase the
> granularity of the changes at different scales without cutting and pasting
> hundreds of lines of xml.
>
> charles
>
>
>
>
>
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
