Dear Geoserver and Geotools developers
We are experiencing problems in the handling of data produced by Geoserver WFS
outputs, and ingested by Geotools into FeatureCollections.
Context:
We are using Geotools as our main internal spatial data processing library. Our
data sources are mostly WFS, based on Geoserver (mostly 2.1, with some older –
1.7xxxx). We request the data in the native GML formats.
Problem:
Our problem is that the output GML received from Geoserver WFS queries encode
the srs at the level of Geometries, not at the level of features or Feature
Collections, while the OGC Spec (see footnote) allows for all three levels and
states the preference that the most general level should be used.
Now, in the cases tested, all feature collections were homogeneous in their SRS
(to be honest, I am yet to see a FeatureCOllection with heterogeneous SRSs, in
Geoserver or elsewhere). The datasets exposed through Geoserver had the SRS
defined for the whole dataset. Also, I tried to explicitly define the output
SRS for the entire FeatureType in the query (&srsName=EPSG:XYZV) to no avail.
Each and every single Feature got the new SRS typed.
I was wondering if there is a flag to alter this behaviour of Geoserver, or if
it would be possible to enable this. I am writing this to the Geotools
developers mailing list as well, as I suspect that the behaviour is underpinned
by the FeatureCollection handling in GT.
The problem with the current behaviour is that once we try to ingest the GML
back into a Geotools FeatureCollection, the SRS and envelope informations are
not set, as they are not declared at the Collection level in the GML. The
schema is set before the features are read into it based on describeFeatureType
requests (this has some other additional Geotools-specific problems, which we
will detail in a different email). The Geotools FeatureCOllection created from
the GML does not contain the SRS information at the feature level, and of
course, loses the information contained in the GML (the SRS set for the
Geometries) - assuming because the underpinning JTS library does not have a
concept of SRS for Geometries.
Thus, the information is fully lost – and that even in the situation where the
same underpinning library (Geotools) produces the GML and reads it back in. I
am not sure how generic this behaviour is with relation to other data stores.
I would be happy to lodge a JIRA ticket about this (or a few) but I would like
to get an understanding which project this would be best targeted towards (GS
or GT) and maybe how to break it into its main components. We may be able to
put in some resource to come with patches if we can get direction about which
components should be targeted (as this is an important functionality for our
project).
Thanks,
Martin
----
Footnote:
As per the OGC IS Profile: GML, Simple Features Profile (OGC 10-100r3), GML can
specify the SRS at three levels:
"
a) On the gml:boundedBy Envelope of a top level response container that is a
feature
collection. For example, the WFS response container, wfs:FeatureCollection
defined in the Web Feature Service Implementation standard [OGC 04-094].
b) On the gml:boundedBy Envelope of each feature instance.
c) On the geometry elements "
And continues:
"In order to reduce redundancy, instance documents should specify the srsName
attribute
at the highest possible level. In the case were a CRS is not explicitly
specified for a
geometry instance, the CRS of the geometry instance shall be assumed to take on
the
value of the srsName attribute of the gml:boundedBy Envelope of the nearest
containing element (i.e. feature instance or feature collection) that contains
an Envelope.
This implies that if all geometry instances in a document are in the same CRS,
then the
best practice for a compliant instance document is to not repeatedly specify
that same
value for the srsName attribute for each geometry instance. Instead, the
compliant
document should specify a gml:boundedBy element at the feature collection level
and
specify a value for the srsName attribute on the gml:Envelope element. Thus, the
srsName attribute is specified once in the entire document."
--
Martin Tomko, PhD.
Senior Project Manager, Information Infrastructure Design, AURIN
Level 5, Architecture Building
University of Melbourne VIC 3010
AUSTRALIA
T: +61 3 9035 3298
E: [email protected] <mailto:[email protected]>
W: www.aurin.org.au <www.aurin.org.au>
W: http://www.tomko.org
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
