I have been trying out several solutions to try to process GML 3.2 geometry served through a WFS 2.0 data services. There seems to be very little experience and software out there that manages to handle complex feature types and GML3.2 geometries.
One of the more promissing solutions is in my opinion provided by 52 north's WPS package, it is supposed to fully support GML2.1 > GML3.2 and also has many many processes provided as plugins leveraging libraries like GRASS, sextante etc.
I have installed the latest version, on a Windows Server 2012 R2, running Java 8 with Tomcat 8. Unfortunately the built in demos using GML geometries doesn't work. While trying to POST a processing request, for example unsing one of my GML 3.2 geometries I get the following error:
org.xml.sax.SAXException: Handler for gml:MultiSurface could not be found.
I am using the Open HTTP requester plugin from Firefox to submit this reqeust, sending the request as application/xml. This is the body of the request I am sending:
Hi Ben, the WPS finally works.
I was successfully managed to feed 2 GML 3.2 geometries into the Intersection Algorithm and get a correct geometrical output. Could you tell me what you modified on your demo environment so that I might try to replicate it on my machine? Or will you release a new/patched version of the WPS server for people to download to and use?
I have also seen that the Intersection algorithm declares the GML output's geometry as EPSG:4326 (Lat/Long), instead of the declared EPSG:3035 from the two data endpoints. Is there a way to tell the process what the output geometry's SRS code is?
If the modifications work for you, I will include them in the next patch release. We can do that very soon, let me just look into the SRS stuff you were describing. If needed in the meantime, I could also provide you with the modification directly.
That is very generous and I would galdly like to know the configurations necessary to make it work.
Regarding encoding the SRSNAME I think I found the reason for this: if the GML 3.2 doesn't provide the boundingBox, the process aparently falls back to the default 4326 Lat/Long.
If the boundingBox is provided, (I have since done this on the geoserver), the EPSG code is correctly recognized, however it is still encoded bad. Instead of srsName="http://www.opengis.net/gml/srs/epsg.xml#3035" GML3.2 requires EPSG codes to be encoded like srsName="urn:ogc:def:crs:EPSG::3035"
Also I am spreading the good news about this server to the INSPIRE forums, people need to know 52North WPS can use GML 3.2 (so very few WPS Servers manage to do this).