[Geoserver-devel] WFS PPIO and WFS

Andrea_Aime3 · December 22, 2008, 11:13am

Hi,
I have some trobles dealing with WFS collections in WPS
context, in particular with the PPIO api.

The PPIO api is there to allow delegates to parse/encode the
portion of a WPS request that is not WPS XML, but "something
else", such as a base64 encoded binary file, or just some
variant of GML.

For the GML PPIO the mime type is used to distinguish between
the two possibilities, so we know what to use when parsing/encoding:
text/xml; subtype=gml/2.1.2
text/xml; subtype=gml/3.1.1

What about WFS feature collections? Afaik there is no
well defined standard here. The servers do return text/xml
usually for both WFS 1.0 and WFS 1.1, thought in fact
for WFS 1.1 you're requesting "text/xml; subtype=gml/3.1.1"
as the output format...
Suggestions? Shall we use the same mime types as GML,
create our own for WFS? ("text/xml; subtype=wfs/1.0"... eek!)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · December 22, 2008, 4:23pm

Hi Andrea,

So for wfs 1.1, yes I believe that the gml mime types are supposed to be used. But I can see this popping up else where. I remember you, David and I chatted about this some time back. And I seem to remember that using the sub mime type would be a good idea. So I would be for that as well.

Perhaps we should stick with the gml mime types for now, and if this need arrives for other things adopt a sub mime type scheme?

-Justin

Andrea Aime wrote:

Hi,
I have some trobles dealing with WFS collections in WPS
context, in particular with the PPIO api.

The PPIO api is there to allow delegates to parse/encode the
portion of a WPS request that is not WPS XML, but "something
else", such as a base64 encoded binary file, or just some
variant of GML.

For the GML PPIO the mime type is used to distinguish between
the two possibilities, so we know what to use when parsing/encoding:
text/xml; subtype=gml/2.1.2
text/xml; subtype=gml/3.1.1

What about WFS feature collections? Afaik there is no
well defined standard here. The servers do return text/xml
usually for both WFS 1.0 and WFS 1.1, thought in fact
for WFS 1.1 you're requesting "text/xml; subtype=gml/3.1.1"
as the output format...
Suggestions? Shall we use the same mime types as GML,
create our own for WFS? ("text/xml; subtype=wfs/1.0"... eek!)

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · December 22, 2008, 4:25pm

Justin Deoliveira ha scritto:

Hi Andrea,

So for wfs 1.1, yes I believe that the gml mime types are supposed to be used. But I can see this popping up else where. I remember you, David and I chatted about this some time back. And I seem to remember that using the sub mime type would be a good idea. So I would be for that as well.

Perhaps we should stick with the gml mime types for now, and if this need arrives for other things adopt a sub mime type scheme?

Works for me
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · December 22, 2008, 4:27pm

I guess your only safe solution is to perform some heuristicts on the
incomming stream. Both Justin (don't quite remember exactly where) and me are
doing that. I'm doing it on the gt WFS module, cause I can't also know
beforehand if the response is and exception report or a wfs featurecollection,
and different parsers shall be used.

Curious, what are you using to parse a WFS response? which GML parser are you
using? I guess we should try and consolidate that, since, for example, the WFS
1.1 datastore is not using the gt-xsd parser nor StreamingParser right now,
but a custom, StAX based one, and it is on my radar to consolidate general GML
parsing too. Thouhg the long term plan is to incorporate StAX as a source for
gt-xsd, and fix the memory problems in gt-xsd's StreamingParser, etc

Now back to your problem, the heuristic is gonna be complicated too I guess.
Say you inferr the response is WFS 1.0 response cause the document's namespace
is the wfs one and the schemaLocation points to the wfs 1.0 one... well..
that's not that easy to inferr cause the schemaLocation may point to a server
customized URL rather than the official http://schemas.opengis.net/wfs/1.0/…

And once you got it is a WFS 1.0 response, you still don't know if the GML
content is GML 2.1.2 or 3.1.1, and do not hold your breath on the server
correctly importing the GML 3.1.1 schemas if need be. Though I may be wrong
and seeing it more complicated than it really is.

-
aside, if GeoServer receives a GetFeature request with version=1.0.0 and
outputFormat=GML3, why does it return a WFS 1.1 response? check this out
<http://sigma.openplans.org:8080/geoserver/ows?service=WFS&request=GetFeature&typeName=topp:states&maxFeatures=1&version=1.0.0&outputFormat=GML3>\)

the response containst xsi:schemaLocation="http://www.opengis.net/wfs
http://sigma.openplans.org:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd", the
feature collection contains the numberOfFeatures attribute, so its clearly a
1.1 response for a 1.0 request...
-

So in general whay I found is that dealing with server responses is an
excersise of patience and adaptation, disregard the existence of standards...

Gabriel

On Monday 22 December 2008 09:13:01 Andrea Aime wrote:

Hi,
I have some trobles dealing with WFS collections in WPS
context, in particular with the PPIO api.

The PPIO api is there to allow delegates to parse/encode the
portion of a WPS request that is not WPS XML, but "something
else", such as a base64 encoded binary file, or just some
variant of GML.

For the GML PPIO the mime type is used to distinguish between
the two possibilities, so we know what to use when parsing/encoding:
text/xml; subtype=gml/2.1.2
text/xml; subtype=gml/3.1.1

What about WFS feature collections? Afaik there is no
well defined standard here. The servers do return text/xml
usually for both WFS 1.0 and WFS 1.1, thought in fact
for WFS 1.1 you're requesting "text/xml; subtype=gml/3.1.1"
as the output format...
Suggestions? Shall we use the same mime types as GML,
create our own for WFS? ("text/xml; subtype=wfs/1.0"... eek!)

Cheers
Andrea

Andrea_Aime3 · December 22, 2008, 4:49pm

Gabriel Roldan ha scritto:

I guess your only safe solution is to perform some heuristicts on the incomming stream. Both Justin (don't quite remember exactly where) and me are doing that. I'm doing it on the gt WFS module, cause I can't also know beforehand if the response is and exception report or a wfs featurecollection, and different parsers shall be used.

Hum, for WPS I believe there is no need for that. The input parameters
have a type specified by a mime type, so as long as we use separate
types for all possible inputs we're good, no need to guess.
The onus to match the mime with a request that returns data into that
form is on the user, the WPS does not have a direct notion of WFS,
just one of a GET/POST request that returns some document.
Depending on the allowed mime types the request can be a direct
reference to a GML document stored somewhere, a link to a zipped
shapefile, or a proper WFS request, the WPS is not really concerned
with it, it just executes whatever request you specified and parses
the results according to the mime type you declared to be using
for that argument.

Curious, what are you using to parse a WFS response? which GML parser are you using?

Atm there is no real support for remote execution, but once I add that,
it will use the XSD parser without streaming, to get started.
Being able to use an efficient version of streaming would be a bonus
thought... thought not to feed the algorithms directly, since there is no rule stating the feature collections must be traversed just once,
if we go streaming then I'll have to find a temporary storage as well,
an H2 database or a shapefile seem like a nice solution for it (shapefile has at least spatial indexing thought has other issues
with complex features and geometry type morphing...)

aside, if GeoServer receives a GetFeature request with version=1.0.0 and outputFormat=GML3, why does it return a WFS 1.1 response? check this out <http://sigma.openplans.org:8080/geoserver/ows?service=WFS&request=GetFeature&typeName=topp:states&maxFeatures=1&version=1.0.0&outputFormat=GML3>\)

the response containst xsi:schemaLocation="http://www.opengis.net/wfs http://sigma.openplans.org:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd", the feature collection contains the numberOfFeatures attribute, so its clearly a 1.1 response for a 1.0 request...

Well, how can we return a WFS 1.0 response when the 1.0 one mandates
GML2 usage? The choice for GML3 output is really to either:
- return a WFS 1.1 one or
- return a raw GML3 collection (which is quite the same, as a WFS 1.1
one is a valid GML3 collection, it's in the same substitution group,
isn't it?)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.