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:
<PropertyIsEqualTo>
<PropertyName>dateProperty</PropertyName>
<Literal>2006-12-12Z</Literal>
</PropertyIsEqualTo>
Gets 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:PropertyName>sf:decimalProperty</ogc:PropertyName>
<ogc:Sub>
<ogc:PropertyName>sf:intProperty</ogc:PropertyName>
<ogc:Literal>149.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.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
