1)
I would like to have more details on GeoServer implementation. More
precisely, I'd like to know what is missing to complete WFS 1.1.0
Compliance.
Well, I have no idea what is missing for complete WFS 1.1.0 compliance,
since as far as I know that spec isn't out yet. As far as 1.0 compliance,
all the large pieces are in - transactions, locking, multiple namespaces.
We can't handle complex features, but that is a _major_ undertaking,
requiring rethinking and rewriting much of geotools. So what really
remains for 1.0 compliance is testing everything as closely as possibly.
Luckily geoserver is participating in extensive testing to make sure it is
1.0 compliant. Capabilities and Describe are working quite well, and
we're working on GetFeatures right now. The testing initiative will
finish up sometime in september, so geoserver will be completely OGC
certified 1.0 compliant by then. Advanced filters will probably need the
most work, which is why we haven't put them in the capabilities document
yet. And there are a number of little things in the code I'd like to fix,
like better pooling of connections, some of the sax parsing, reading of
features, a few speed improvements, and a rewrite of the gml generating
code. But I'm not sure if all those things are needed for 1.0 compliance.
2)
Quizz : What is wrong with this delete request ?
<?xml version="1.0" encoding='ISO-8859-1' ?>
<wfs:Transaction
xmlns:wfs="http://www.opengis.net/wfs"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="1.0.0" service="WFS" outputFormat="XMLSCHEMA">
<wfs:Delete typeName="commune">
<ogc:Filter>
<ogc:PropertyIsLike wildCard="*" singleChar="?" escape="\">
<ogc:PropertyName>NOM_COMM</ogc:PropertyName>
<ogc:Literal>chew*</ogc:Literal>
</ogc:PropertyIsLike>
</ogc:Filter>
</wfs:Delete>
</wfs:Transaction>
It seems to be well parsed by SAX, but I don't have more information. This
request leads to a servlet exception error (with resin). But where's the
mistake ?
escape should be escapeChar. But I did a little testing, and it looks
like the filter will only work if you do nom_comm in lower case. Which is
the reason I haven't put like filters in the capabilities document -
they're nasty, and I haven't really tested them at all. They're just in
geotools, so they work, but they don't work well. One caveat to using
like filters - they're slow. They are not yet done in postgis with a sql
like statement, instead all features are selected, constructed into
geotools, and then filtered out. This is why upper case will not work -
everything in postgis is lowercase, so it creates the attribute to be
nom_comm, not NOM_COMM. If you want to write the visitor function for
org.geotools.filter.SQLEncoder it would be a _huge_ help, as it's a task
I've been putting off for awhile now. It's tricky, because you have to
get all the escape translation right, from the internal geotools filter to
the sql way of doing things. I started it, but I had other tasks to do,
so I left it to be finished later. It shouldn't take you that long, you
just need to think it through and test it well, to make sure that all
cases are covered. This will also naturally fix the uppercase problem,
and will make things _much_ faster. Or you can just wait till we get to
it, probably sometime in the next few months.
Chris