Oh, this is great, I'd love to see this as a community module in GeoServer (which we can easily get you commit access to), and eventually part of the main distribution. Let me know if we can help out at all. And I imagine you've found the geotools classes that uDig made - I've definitely wanted an interface for GeoServer that would let people get at it.
Cameron, as to your questions, these wouldn't really be an extension to the WFS spec. If one were to do a strict OGC approach it'd probably be in a WPS, since with WFS you always have to return features, whereas this you just want the steps. But if I were doing it I would just do a one off, since I don't feel WPS is that established and it'd take a lot more work.
I do think the SLD spec could be improved with a number of these needs as well.
best regards,
Chris
> Lorenzo,
> It would be good to discuss this in real time. My contact details are at
> http://cameron.shorter.net
> I have a bunch of questions:
> * What will your interface between client and server look like?
> * I don't know much about the algorithms mentioned below, but I'm
> guessing they require attribute Max/min and statistical calculations
> from a collection of features?
> * I wonder how a WFS interface would need to be extended to support
> this and whether it is worth standardising as a spec.
> * The SLD spec has had a slow uptake and I wonder whether your needs
> might highlight deficiencies.
> I'm assuming that you plan to have a browser based client (Openlayers)
> which would need an interface to a server (eg Geoserver).
Lorenzo Becchi wrote:
>
>> Lorenzo,
>> You have sparked my curiosity. Maybe you have identified a user
>> requirement which is not covered by OGC specifications.
>>
>> I'm wondering whether your requirements could be addressed by a WFS
>> or Web Coverage Service (WCS).
>> A WCS can be used to colour a map based on an attribute like
>> population density.
> We didn't felt that confortable looking for a OWS solution for:
> - quantile
> - unique value
> - natural brakes
> - generally every algorithm to create classes passing from real data
> values.
>
> The problem we see is not the possibility to access data values with
> OWS but to parse them on the client (Web Browser) to build the brake
> values and use them in SLD filters.
>
> we are open to any suggestions to do a better job but actually we see
> a solution only in this server component.
>
> ciao
> Lorenzo and Andrea
>
--
Hi Chris,
Oh, this is great, I'd love to see this as a community module in GeoServer (which we can easily get you commit access to), and eventually part of the main distribution. Let me know if we can help out at all. And I imagine you've found the geotools classes that uDig made - I've definitely wanted an interface for GeoServer that would let people get at it.
Andrea Cappugi (CC) is writing the code for the server component. Actually we have an independent module that Andrea would love to integrate in GeoServer. it would be great to me too. We're trying to show it publicly asap.
Andrea had a look to uDig classes and enjoyed many hints from geoSolutions guys.
Cameron, as to your questions, these wouldn't really be an extension to the WFS spec. If one were to do a strict OGC approach it'd probably be in a WPS, since with WFS you always have to return features, whereas this you just want the steps. But if I were doing it I would just do a one off, since I don't feel WPS is that established and it'd take a lot more work.
I really appreciate this comment. This makes things simpler to us.
We've been working with WPS (pywps.ominiverdi.org) and have a similar opinion about it. It's powerful but you need to define a WPS function that can't be granted to be standard in all implementations. More over I don't know when GeoServer will support WPS.
I do think the SLD spec could be improved with a number of these needs as well.
hopefully
I have the feeling this thread is moving randomly on many MLs.
AFAIK OpenLayers DEV List [1] has all posts, actually all posts I've submitted.
ciao
Lorenzo
[1] http://openlayers.org/pipermail/dev/2007-July/001020.html
best regards,
Chris
> Lorenzo,
> It would be good to discuss this in real time. My contact details are at
> http://cameron.shorter.net
> I have a bunch of questions:
> * What will your interface between client and server look like?
> * I don't know much about the algorithms mentioned below, but I'm
> guessing they require attribute Max/min and statistical calculations
> from a collection of features?
> * I wonder how a WFS interface would need to be extended to support
> this and whether it is worth standardising as a spec.
> * The SLD spec has had a slow uptake and I wonder whether your needs
> might highlight deficiencies.
> I'm assuming that you plan to have a browser based client (Openlayers)
> which would need an interface to a server (eg Geoserver).
Lorenzo Becchi wrote:
>
>> Lorenzo,
>> You have sparked my curiosity. Maybe you have identified a user
>> requirement which is not covered by OGC specifications.
>>
>> I'm wondering whether your requirements could be addressed by a WFS
>> or Web Coverage Service (WCS).
>> A WCS can be used to colour a map based on an attribute like
>> population density.
> We didn't felt that confortable looking for a OWS solution for:
> - quantile
> - unique value
> - natural brakes
> - generally every algorithm to create classes passing from real data
> values.
>
> The problem we see is not the possibility to access data values with
> OWS but to parse them on the client (Web Browser) to build the brake
> values and use them in SLD filters.
>
> we are open to any suggestions to do a better job but actually we see
> a solution only in this server component.
>
> ciao
> Lorenzo and Andrea
>