Hi,
I've seen Arne is about to run the WFS 1.1 cite tests so I have
some suggestions and some considerations.
The first is that if you run the cite tests with geoserver as
is they will fail. This is because current version of geoserver
is only partially aware of the axis order issues.
To make things work you'll have to load the cite-wfs-1.1
sql file as is, and then start GeoServer with the following
parameter:
-Dorg.geotools.referencing.forceXY=false
This way GeoServer will work in lat/lon mode in all its operations,
and it will pass the cite tests.
Now a longer explaination. The cite test suite assumes urn:x-ogc:def:crs:EPSG:6.11.2:4326 everywhere, and that crs
is lat/lon.
The datastores (all of them) work in lon/lat instead.
The data provided in dataset-sf0.sql, the database setup file,
is lat/lon, too. This means it's ordered the opposite of
the usual layout (so, a double mess...).
Running the cite tests like I suggested
above does not match any real production situation, because
we have original data in lat/lon and the epsg authority working
in lat/long as well.
A real world situation would require geoserver and the epsg
factory work in lon/lat instead (just like we always did btw), but
then publish data it in lat/lon when the
urn:x-ogc:def:crs:EPSG:6.11.2:xxxx notation is used (which basically
means every time wfs 1.1 is used).
I do have a modified setup file that has data the
way postgis expects, that is, lon/lat, and I have tried
to run cite wfs 1.1 without any strange parameter: a test
where geoserver works like in production.
The result is that some 10/15 tests do fail for various reasons,
all related to the incomplete axis awarness:
http://jira.codehaus.org/browse/GEOS-1441
http://jira.codehaus.org/browse/GEOS-1440
http://jira.codehaus.org/browse/GEOS-1439
http://jira.codehaus.org/browse/GEOS-1438
http://jira.codehaus.org/browse/GEOS-1437
http://jira.codehaus.org/browse/GEOS-1436
http://jira.codehaus.org/browse/GEOS-1435
If we fix them, I think we'll be able to have GeoServer pass the
cite wfs 1.1 test without any kind of trick. At that point we'll
be really wfs 1.1 compliant.
In the current state, we are wfs 1.1 compliant only provided your
data sources are lat/lon ordered, which in my experience is never
the case.
Chris, I've scheduled those issues for rc1 because they are not
such a big deal to fix (Justin, can you have a look and confirm/confute
my impression?) but just move them away if you prefer have
GeoServer really work in wfs 1.1 in a version later than 1.6.0.
And oh, the situation is much better than some time ago because
of the work we did to allow Tim work in 900913 when the data is
stored in another projection (so we already have code paths
knowing that the request might be in one crs and the data in
another, unlike some months ago).
Cheers
Andrea