Parser for SOS GetFeatureOfInterest

[bartvde]

The GetFeatureOfInterest request can be used to get the actual locations from a Sensor Observation Service (SOS), so this is the format which will be used by the SOS Protocol to retrieve/parse the vector features.

[bartvde]

patch includes tests

[ahocevar]

I guess I do not understand how the writer works. Shouldn't it take a list of features as argument instead of foids? At least that's what I would expect from a read-write roundtrip capable format. But maybe I'm just missing something here.

Also the change to OpenLayers.Projection looks suspicious. Is this srs parsing based on any specification? If not, it should probably not go into OpenLayers.Projection. But again, I may just be missing something.

[bartvde]

Hi Andreas, the writer writes out the GetFeatureOfInterest request to the SOS, which will return something that looks like GML (so the actual vector features). So the request to the SOS needs to specify the foi identifiers to retrieve.

The change to Projection is based on the OGC recommendation paper for URN, see:  https://portal.opengeospatial.org/files/?artifact_id=8814

This code is also in PROJ4JS, but I did not want to depend on proj4js for parsing the URN notation of EPSG:4326. Not sure how you feel about this though. See also:  http://trac.osgeo.org/proj4js/ticket/39#comment:1

[ahocevar]

Replying to bartvde:

Hi Andreas, the writer writes out the GetFeatureOfInterest request to the SOS, which will return something that looks like GML (so the actual vector features). So the request to the SOS needs to specify the foi identifiers to retrieve.

Ok, I knew I was missing something. So this is like with Format.WFST. That's fine then.

The change to Projection is based on the OGC recommendation paper for URN, see:  https://portal.opengeospatial.org/files/?artifact_id=8814 This code is also in PROJ4JS, but I did not want to depend on proj4js for parsing the URN notation of EPSG:4326. Not sure how you feel about this though. See also:  http://trac.osgeo.org/proj4js/ticket/39#comment:1

Mh. Unfortunately proj4js also converts urn: crs definition to EPSG: definitions. This will make it harder in the future to find a clean solution for axis order (because urn:ogc:def:crs:EPSG::4326 has lat,lon). Personally, I would prefer if OpenLayers would maintain the original srs definitions. An alternative solution that I would be more in favor of would be to add the following in Format/SOSGetFeatureOfInterest.js:

OpenLayers.Projection.addTransform("urn:ogc:def:crs:EPSG::4326", "EPSG:900913",
    OpenLayers.Layer.SphericalMercator.projectForward);

// invalid urn used by some SOS implementations
OpenLayers.Projection.addTransform("urn:ogc:def:crs:EPSG:4326", "EPSG:900913",
    OpenLayers.Layer.SphericalMercator.projectForward);

This would be enough to make it work with Spherical Mercator maps, which is the only tranformation that OpenLayers supports natively anyway. And you also don't need the inverse transforms, because you don't send feature geometries to the service.

If you agree with my reasoning and make this change (don't forget to remove the 1st test from test_read_SOSGetFeatureOfInterest_single, all others pass in IE7), you can commit.

[ahocevar]

Oops, not so fast. I just has a look at Format.WFST, and the write method there takes a feature as argument.

So may I suggest the following: remove the write method from your format, and in the protocol, call

format.writeNode("sos:GetFeatureOfInterest", options)

[ahocevar]

Wait, I'll upload a new patch in a few minutes, so you can see what I mean.

[ahocevar]

Bart, attachment:openlayers-2347.patch contains all my suggested changes. Tests pass in IE7 and FF3.5. Please commit if you agree.

[bartvde]

Hi Andreas, thanks for the changes. Thinking about it a bit more, I would even be okay with leaving out the projection transforms altogether, it that okay with you or do you want to keep them in there?

[ahocevar]

Bart, that's up to you. If you want to remove them, you can also remove the "pos" reader, because the GML.v3 one will do.

[bartvde]

Hi Andreas, but the pos reader is still necessary if reprojection is done with proj4js under the hood of an application. Or am I missing something? For my use cases I depend on proj4js anyways for reprojection, and I don't think the Google Mercator transform will be a common use case, if that use case comes up we can always add the transforms.

[ahocevar]

You're right (at least if you do not want the user to have to define an external projection). Leave the "pos" reader as is then. For people who do not use proj4js, they can always provide externalProjection: new OpenLayers.Projection("EPSG:4326") or something as formatOptions. So I guess you're right, it's best to remove the transforms for now.

[bartvde]

(In [9911]) add parser for Sensor Observation Service GetFeatureOfInterest method, r=ahocevar (closes #2347)