Hi,
there is a user on the ml asking about how he could get
the extents of the features rendered by a GetMap with a filter.
The answer is that this is not trivial, because the filter
would have to be matched with the eventual filter embedded
in the SLD, with the scale related rules, and so on.
Long story short, only the WMS knows what was actually rendered.
I was wondering about a WMS output format that instead of
depicting a map, describes it. An xml document containing
the layer names, the feature count and bounds for each layer,
maybe a link to the SLD that was used for a specific layer,
the extra filter applied, the current scale.
Could be useful for this common use case (which will stay
common until WFS can really be used in anger to draw many
features in a browser), and also could be useful for debugging
(as the client and the server don't usually compute the
same scale, or to realize you are not using the style you
thought you were using, or to see a filter is not doing
what you intended it to do).
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
The OWS context stuff (I don't think it is an official spec yet) seems like it fits. I think it hits all the requirements... except for feature count. I am not sure if there is some notion of extensible parameters.
It does have the benefit of being a "standard", and I think there is already some client support around for it around: openlayers, udig, gvsig?, etc...
Worth checking out perhaps.
-Justin
Andrea Aime wrote:
Hi,
there is a user on the ml asking about how he could get
the extents of the features rendered by a GetMap with a filter.
The answer is that this is not trivial, because the filter
would have to be matched with the eventual filter embedded
in the SLD, with the scale related rules, and so on.
Long story short, only the WMS knows what was actually rendered.
I was wondering about a WMS output format that instead of
depicting a map, describes it. An xml document containing
the layer names, the feature count and bounds for each layer,
maybe a link to the SLD that was used for a specific layer,
the extra filter applied, the current scale.
Could be useful for this common use case (which will stay
common until WFS can really be used in anger to draw many
features in a browser), and also could be useful for debugging
(as the client and the server don't usually compute the
same scale, or to realize you are not using the style you
thought you were using, or to see a filter is not doing
what you intended it to do).
Opinions?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I think I like that idea, and I think it's not too hard to expand OWS context if it doesn't support the max features.
In general I'd like to start using context documents a lot more, they're pretty central to my thoughts on bringing more user collaboration in to GeoServer, http://geoserver.org/display/GEOS/User+Collaboration
I had mostly just thought of clients GETing and POSTing context documents, but perhaps it could be useful in some cases for GeoServer to generate them.
Raj, has there been any progress on getting it standardized? I feel like it was pretty close last time. It could also be good to have a json representation of it.
Chris
Justin Deoliveira wrote:
The OWS context stuff (I don't think it is an official spec yet) seems like it fits. I think it hits all the requirements... except for feature count. I am not sure if there is some notion of extensible parameters.
It does have the benefit of being a "standard", and I think there is already some client support around for it around: openlayers, udig, gvsig?, etc...
Worth checking out perhaps.
-Justin
Andrea Aime wrote:
Hi,
there is a user on the ml asking about how he could get
the extents of the features rendered by a GetMap with a filter.
The answer is that this is not trivial, because the filter
would have to be matched with the eventual filter embedded
in the SLD, with the scale related rules, and so on.
Long story short, only the WMS knows what was actually rendered.
I was wondering about a WMS output format that instead of
depicting a map, describes it. An xml document containing
the layer names, the feature count and bounds for each layer,
maybe a link to the SLD that was used for a specific layer,
the extra filter applied, the current scale.
Could be useful for this common use case (which will stay
common until WFS can really be used in anger to draw many
features in a browser), and also could be useful for debugging
(as the client and the server don't usually compute the
same scale, or to realize you are not using the style you
thought you were using, or to see a filter is not doing
what you intended it to do).
Opinions?
Cheers
Andrea
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
The last thing that happened with ows context was a call from me for people to test version 0.3.0 (the version that came out of OWS5 work). That's when we put the KML stuff in and worked on the schema. I think it's solid and just needs someone to do the administrative work to move it forward. I'm happy to work on this and get it ready for a vote at the Athens TC in the mass market WG. Sound good?
---
Raj
On Feb 19, at 2:10 PM, Chris Holmes wrote:
I think I like that idea, and I think it's not too hard to expand OWS context if it doesn't support the max features.
In general I'd like to start using context documents a lot more, they're pretty central to my thoughts on bringing more user collaboration in to GeoServer, http://geoserver.org/display/GEOS/User+Collaboration
I had mostly just thought of clients GETing and POSTing context documents, but perhaps it could be useful in some cases for GeoServer to generate them.
Raj, has there been any progress on getting it standardized? I feel like it was pretty close last time. It could also be good to have a json representation of it.
Chris
Justin Deoliveira wrote:
The OWS context stuff (I don't think it is an official spec yet) seems like it fits. I think it hits all the requirements... except for feature count. I am not sure if there is some notion of extensible parameters.
The schema is here: http://www.ogcnetwork.net/schemas/owc/
It does have the benefit of being a "standard", and I think there is already some client support around for it around: openlayers, udig, gvsig?, etc...
Worth checking out perhaps.
-Justin
Andrea Aime wrote:
Hi,
there is a user on the ml asking about how he could get
the extents of the features rendered by a GetMap with a filter.
The answer is that this is not trivial, because the filter
would have to be matched with the eventual filter embedded
in the SLD, with the scale related rules, and so on.
Long story short, only the WMS knows what was actually rendered.
I was wondering about a WMS output format that instead of
depicting a map, describes it. An xml document containing
the layer names, the feature count and bounds for each layer,
maybe a link to the SLD that was used for a specific layer,
the extra filter applied, the current scale.
Could be useful for this common use case (which will stay
common until WFS can really be used in anger to draw many
features in a browser), and also could be useful for debugging
(as the client and the server don't usually compute the
same scale, or to realize you are not using the style you
thought you were using, or to see a filter is not doing
what you intended it to do).
Opinions?
Cheers
Andrea
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
That is a very useful idea. I have also wanted to request something similar for a summary of the features displayed in an area (like describe feature type but more focused on the data values - like a histogram). I just run into an internal project here where a developer had made a WFS “harvester” inorder to produce similar information (so he could generate a decent SLD).
Hi,
there is a user on the ml asking about how he could get
the extents of the features rendered by a GetMap with a filter.
The answer is that this is not trivial, because the filter
would have to be matched with the eventual filter embedded
in the SLD, with the scale related rules, and so on.
Long story short, only the WMS knows what was actually rendered.
I was wondering about a WMS output format that instead of
depicting a map, describes it. An xml document containing
the layer names, the feature count and bounds for each layer,
maybe a link to the SLD that was used for a specific layer,
the extra filter applied, the current scale.
Could be useful for this common use case (which will stay
common until WFS can really be used in anger to draw many
features in a browser), and also could be useful for debugging
(as the client and the server don’t usually compute the
same scale, or to realize you are not using the style you
thought you were using, or to see a filter is not doing
what you intended it to do).
Opinions?
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
That is a very useful idea. I have also wanted to request something similar for a summary of the features displayed in an area (like describe feature type but more focused on the data values - like a histogram). I just run into an internal project here where a developer had made a WFS "harvester" inorder to produce similar information (so he could generate a decent SLD).
hmm... that looks a little like the sldService community module that
helps you build styles based on quantile/interval/... classifications
of a certain attribute? It's a set of REST calls, needs some cleanup
but shows promise