Make WFS FID's compliant...

[sdlime]

MapServer by default will output non-compliant feature-id's with WFS output. Here's a piece of a thread by Jukka Rahkonen...

---

a) An excerpt from gml 2.1.2 feature.xsd schema:

<documentation>

An abstract feature provides a set of common properties. A concrete feature type must derive from this type and specify additional properties in an application schema. A feature may optionally possess an identifying attribute ('fid').

</documentation>

</annotation> <sequence>

<element ref="gml:description" minOccurs="0"/> <element ref="gml:name" minOccurs="0"/> <element ref="gml:boundedBy" minOccurs="0"/> <!-- additional properties must be specified in an application schema -->

</sequence> <attribute name="fid" type="ID" use="optional"/>

So fid seems to be of type "ID" b) Reference ​http://matcmadison.edu/schmidt/xml/dtdattr.htm says:

ID is used to uniquely identify an element in the [XML] document

• It cannot be repeated within the document
• Cannot have a fixed default value (#FIXED), since these cannot change
• Most IDs use #REQUIRED for a default value, since an ID is required
• ID values must conform to the rules for valid XML names
• ID must be a valid XML name - must start with a letter or underscore
• An ID using a pure number, such as a credit card number, social security number, telephone number or any other pure numeric value is not valid

There seem to exist WFS clients which are strict in validating the GML returned from the server. Shouldn't there be some mechanism in Mapserver WFS that automatically generates some valid character in the beginning of fid? At least in our database the most suitable columns that could be used as basis for fid are numeric, primary key taken from sequence or the kind. Now taking the most suitable column for fid by adddint "wfs_featureid" "ID" to LAYER METADATA section leads to non-standard result. Adding an underscore should make it valid for any client. Do WFS specialists agree?

---

The easiest fix would be to output the typename then a dot then the id. Apparently this is how both GeoServer and Ionic do things. The fid query support would need to be updated to reflect this new convention.

[sdlime]

I committed a change to the GML writer to write FIDs in the form typename.id so this should fix WFS output in 5.0. Might consider a backport because it looks as if you can't query by FID anyway so we could output anything there as long as it conformed to name spec mentioned in the description. I'd like to fix that query shortcoming but that's another bug.

Jukka, any chance you could try the main SVN branch?

Steve

[tomkralidis]

To confirm: I just tested this against r6142. Here's a snippet of the GetFeature response:

<gml:featureMember>

<owscat:service_endpoints fid="owscat:service_endpoints.1118"> <gml:boundedBy> <gml:Box srsName="EPSG:4326">\

so @fid is written out (as wfs_namespace_prefix:layer_name:MAP/LAYER/METADATA/gml_featureid), if MAP/LAYER/METADATA/gml_featureid is set. If it is not set, @fid is not output.

[sdlime]

Replying to tomkralidis:

Nuts, I don't think that's quite what we want. The namespace prefix shouldn't be there. I think it should be:

<owscat:service_endpoints fid="service_endpoints.1118">

Correct? Your interpretation of when an FID is output is correct although I'm thinking that could change too. We could output the shape id if the FID metadata is not set. We really need to be able to query by FID then.

[tomkralidis]

Fixed in r6143.

When you say shape id, do you mean any underlying data type (i.e. postgresql, mapinfo)?

Agreed querying by FID would be valuable.

[sdlime]

Replying to tomkralidis:

Fixed in r6143.

Excellent, thanks!

When you say shape id, do you mean any underlying data type (i.e. postgresql, mapinfo)?

Each shape carries an integer ID that allows msLayerGetFeature() to work. It's an artifact of the two-stage query process. For a shapefile it's the sequential number in the file. PostGIS and the other drivers all have something equivalent. They are not stable over the long term so perhaps we should avoid and force users to set one.

Agreed querying by FID would be valuable.

By outputing the typename along with the ID this should be pretty easy and shouldn't require an RFC.

[tomkralidis]

Replying to sdlime:

Replying to tomkralidis:

Fixed in r6143.

Excellent, thanks!

When you say shape id, do you mean any underlying data type (i.e. postgresql, mapinfo)?

Each shape carries an integer ID that allows msLayerGetFeature() to work. It's an artifact of the two-stage query process. For a shapefile it's the sequential number in the file. PostGIS and the other drivers all have something equivalent. They are not stable over the long term so perhaps we should avoid and force users to set one.

I agree that users should be setting this metadata, if it is important to them, and to keep persistence.

Agreed querying by FID would be valuable.

By outputing the typename along with the ID this should be pretty easy and shouldn't require an RFC.

Let's open another ticket for this one, and close this one...

[tomkralidis]

I meant open another ticket for that one, and close this one :P

[tomkralidis]

Closing. #2102 covers implementation of querying by FID.