So here is the deal for wfs cite status:
- wfs 1.0.0
Ran the tests a first time and ran into some failures. A closer look revealed that the postgis datastore was configured to use estimated extents. The issue of using estimated extents in cite tests aside for the moment, there seems to be an issue with the use of st_estimated_extent when a table with uppercase characters are in place. For example:
30 Aug 13:23:06 WARN [org.geotools.jdbc] - Failed to use ST_Estimated_Extent, falling back on envelope aggregation
org.postgresql.util.PSQLException: ERROR: relation “locks” does not exist
Where: SQL statement “SELECT has_table_privilege((SELECT usesysid FROM pg_user WHERE usename = session_user), ‘Locks’, ‘select’)”
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062)
Which seems to me like a bug in postgres. Has anyone run into this one before?
Changing the datastore configuration and turning off estimated extents all tests pass. Also changing to prepared statements also fixes the issue.
- wfs 1.1.0
The first run of wfs 1.1 we did not even pass the sanity checks 
. The reason being some recent modifications to the gml3 encoder to include srsDimension (along with srsName) on all Envelope, Point, LineString, etc… elements. Now while this is perfectly valid according to the gml3 schema proper, it is apparently not valid when it comes to the simple feature profile used by the cite test engine for validation purposes.
Which to me seems like an error. Can anything think of any reason not to allow the srsDimension attribute? Perhaps because simple features assumes 2D geometries? Not sure i have ever heard of that but it is possible. Anyways, I will raise this as an issue on the cite forum.
The second major issue with wfs 1.1.0 is queries that involve date filters. It seems that a query like this:
dateProperty 2006-12-12ZGets transformed into the where clause "WHERE “dateProperty” != ‘2006-12-11 17:00:00.0’ " (i am gmt-7) which drops the timezone information and the query fails. However this is only for the non prepared statement route, the prepared statement route works fine. It is also worth noting that the non prepared statement route also fails because of the estimated extent issue described for wfs 1.0.0.
So the question becomes should we patch the non ps route to include the timezone information? Or should we just turn on prepared statements in the datastore config and call it a day?
Past that only one type of failure remains, which we have seen before. And it is the nasty:
ogc:PropertyIsEqualTo
ogc:PropertyNamesf:decimalProperty</ogc:PropertyName>
ogc:Sub
ogc:PropertyNamesf:intProperty</ogc:PropertyName>
ogc:Literal149.98</ogc:Literal>
</ogc:Sub>
</ogc:PropertyIsEqualTo>
Which does not pass when using prepared statement but does pass when not using prepared statements… sigh.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.