Mapserver use curveMembers that not part of the Simple Features profile

[sbrunner]

No description provided.

[sbrunner]

Version 1.0 of the Simple Features Profile:
http://portal.opengeospatial.org/files/?artifact_id=15201&passcode=h597f3yybeu8fqxh99kh

Notice that curveMembers is not supported by OpenLayers (openlayers/openlayers#1323)

Concern part of code:
https://github.com/mapserver/mapserver/blob/master/mapgml.c#L625-L646

[aperi2007]

AFAIK the curveMembers is in the GML 3.1.1.
It is for GML response. As example: the WFS could return a GML 2.1.1 or a GML 3.1.1+ . Depend from the request parameters.

[sbrunner]

Yes but not of the "Geography Markup Language (GML) simple features profile" and for example OpenLayers will implement only the simple profile ...

[tbonfort]

see also http://trac.osgeo.org/openlayers/ticket/2388

[sbrunner]

and also: openlayers/openlayers#1323 (I fix my previous comment)

[rouault]

http://mapserver.org/fr/ogc/wfs_server.html refers to http://trac.osgeo.org/mapserver/ticket/884 which seems to indicate that the intent was to have GML3-SF0 indeed. So perhaps there has been a change beetween 04-061 Level 0 Profile of GML3 for WFS and the new 05-049r1 ? (actually now superseeded by 10-100r3, http://portal.opengeospatial.org/files/?artifact_id=42729 for GML 3.2.1)

So your change is in the right direction, but you should also fix pointMembers and surfaceMembers for being consistant.
And the msautotest suite should also likely be adapted.

This change looks only appropriate for a new version, and not a maintenance release, as it could potentially break clients that are ready for the XXXXs variants, but not for XXXX one.

[sbrunner]

Thanks @rouault for Your feedback, it effectively right that some old specification of the simple feature profile contains those tags :-)

I just update my Pull Request and create a Pull Request on the tests: MapServer/msautotest_DEPRECATED#27 :-)

This change looks only appropriate for a new version, and not a maintenance release, as it could potentially break clients that are ready for the XXXXs variants, but not for XXXX one.

I don't understand what you refer with your XXXX, for me it should be included in Mapserver 7.x, not in 6.x :-)

[rouault]

XXXX was meant to be curveMember, pointMember or surfaceMember.
Yes, I meant that it would be OK for 7.0 target, but likely not 6.4.X

It would be usefull if you could mention your fix on mapserver-dev so that all interesting parties can have a look.

[aperi2007]

@rouault
I check the specs WFS 2.0 from OGC and se nothing to refer as a move forward a GML simple-feature.Instead it is still referencing the GML from ISO 19136 (not only simple-feature).

AFAIK the GML simple-feature from OGC doce you refer seem to be for a specific GML not related to the WFS respsonse.

regards,
A.

[rouault]

@aperi2007 Agreed. The WFS spec doesn't speak about SF profile, because WFS can address complex GML. But I think it might be reasonable to restrict ourselves to SF-0, since the MapServer data model is actually compatible of it. The day MapServer would be able to output complex features, then, the GML outputted would have to evolve, but that would be one change among many other complex ones.
The rational for the change is that some clients have targetted SF-0 as the GML profile to decrease the number of GML variants to handle, since they can have many of them (I have recently blogged about at least 25 different ways of encoding a polygon in GML !)

[aperi2007]

@rouault
I understand the question. My doubt are only to have the same response from other wfs server systems.
To avoid that mapserver could have a response different from that of other WFS server (tinyows or geoserver) because the interoperability is mainly to have the same language on every platform.
Meanwhile I do a check on a tinyows to test what it is responding,
and seem to use the curveMember instead of the curvemembers.

http://www502.regione.toscana.it/wfsvector/com.rt.wfs.RTmap/wfs?service=WFS&version=1.1.0&request=GetFeature&typename=sita:idstradertline&propertyName=dug,toponimo&sortBy=toponimo+A,dug+A&Filter=comuneFIRENZEgeometry1668672.06535163032822311,4847423.55851482413709164 1668672.06535163032822311,4852576.36760131828486919 1678669.07608386687934399,4852576.36760131828486919 1678669.07608386687934399,4847423.55851482413709164 1668672.06535163032822311,4847423.55851482413709164 

I dont know the geoserver , but hope it also responde a curveMember.

Regards,
A

[rouault]

http://pastebin.com/PirwWGks seems to be the output of GeoServer WFS, and it is curveMember.

[aperi2007]

my doubt are resolved,

thx,

A.

[jratike80]

Doubt resolved? I am not so sure. I just checked the latest Geoserver 2.6-RC1 and it has configurable output. By default "One featureMembers element" is selected but it can be changed into "Multiple featureMember elements".
And deegree 3.2 demo service with the Utah workspace is sending MultiPolygons with WFS 1.1.0 as:
<app:geometry> <gml:MultiPolygon srsName="EPSG:26912"> <gml:polygonMember> <gml:Polygon srsName="EPSG:26912"> <gml:exterior> <gml:LinearRing srsName="EPSG:26912"> <gml:posList>392102.003 4257640.050

As I wrote, GeoServer 2.6 is now in RC1 phase. It might be possible still to change the default into "Multiple featureMember elements" for 2.6 release. I suggest to drop a mail to Geoserver developers. I suppose that hardly any user ever touches this config option and thousands of Geoservers are running with the defaults. At least I did not know the meaning of that config option until today.

[rouault]

@jratike80 Interesting the Geoserver configurable. But it is not directly related to the geometries, just featureMember. @mkofahl suggested a configuration option for the surfaceMember vs surfaceMembers, etc. in #4978

Regarding deegree output, it is valid GML but does not belong to SF-0. And as raised as
http://trac.osgeo.org/openlayers/ticket/2388, deegree emits other non SF-0 GML.

I'm quite sure we'll find many cases where servers have not the same GML encoding...

Bringing compatibility with SF-0 would bring the clear benefit of interoperability with OpenLayers client, and with a GML profile that aims at making things simpler (lol !) . It would also bring similar output with some other WFS servers.

It would be interesting to know if there are known clients that would not like the SF-0 formulation. If so, the configuration toggle might be needed.

[jratike80]

Ok. After 7 years experience on running WFS-T in production I see that I do not understand it at all. My feeling is that Geoserver is so popular that most clients like the GML it generates and if it is SF-0 then Mapserver could use it as well.

[jratike80]

If I understand right, the "featureMember" vs. "featureMembers" is an analogous case. While Mapserver is using the first, Geoservers with default settings use the latter which is not SF-0. From chapter 8.4.2 of the OGC document Defining feature collections:

"Use of a feature container corresponding to gml:featureMembers in GML 3.1.1 is not allowed by this specification for compliance level SF-0."

[tbonfort]

There seems to be somewhat of a consensus that this patch should go in for 7.0. @sbrunner can you update your pull-request so that pointMembers and surfaceMembers are treated in an analogous way, I'll then apply this for 7.0, unless someone speaks up against it.

[sbrunner]

Already done :-), I as purpose a pull request for the tests. Many thanks for all @rouault and @tbonfort ;-)

To remember: #4978, MapServer/msautotest_DEPRECATED#27, Test results: https://travis-ci.org/sbrunner/mapserver/builds/33490725

[tbonfort]

closed with #4978