7.14.1 Change: feature unique to collection rather than entire dataset.

[JivanAmara]

Some RDBS data sources such as PostGIS or GeoPackage may have collections as tables w/ ids for features in those tables unique only to that table. Making an id unique to all features would require the WFS3 server to create some kind of combination of a table identifier (collection name) and the feature's id to produce an id unique to the entire dataset.

Since the link to reach a particular feature always includes the collection name, I propose changing the requirement so that the feature id need only be unique to the collection it is within.

[pvretano]

I think Requirement 25 already says what you are asking for. No?

[bgsmase]

I haven't been following the progress in detail but I noticed this issue because I seem to remember that WFS 2 has a requirement to have unique identifiers across feature types which does cause difficulties for implementations. (GetFeatureById stored query). However, it seems to me that the draft WFS 3 standard didn't have any such requirement before you added it in the referenced commits #83 and #85?

[JivanAmara]

@pvretano Req 25 requires that ids are unique across the "dataset". From the terms and definitions and speaking with @cportele it means all of the data served up by the instance.

@bgsmase A "dataset" is defined as a "collection of data, published or curated by a single agent, and available for access or download in one or more formats", this would be all of the data across feature collections. #83 and #85 were to clarify this, this issue (#84) is to change it.

[cmheazel]

Any solution to this issue should address the following:

Consider the case where I am pulling Features from multiple tables across multiple databases. I'm then going to build a derived dataset from all of those Features.

1. How do I guarantee unique feature identifiers if feature identifiers are only unique within the table?
   a) I can generate new feature identifiers for the retrieved features. But I loose the association with the source feature.
   b) I can generate new feature identifiers from the URLs for each feature. However, as this process is repeated over time, these feature identifiers could become very large.
   c) I can generate a unique identifier from the URL for each feature (such as a UUID). But I would loose the association with the source feature.
2. How do I guarantee the uniqueness of each feature?
   Since two table entries may have identical content, I could have identical features with different identifiers. Do we need to distinguish the identifier for the feature object (table unique identifier) from the identifier for the feature concept (what the feature object represents)?

[jampukka]

As long as (#66, #30) each feature in the distribution is part of exactly one collection
this change seems logical.

@cmheazel I think the proposed change has no effect on 1. when pulling features from across multiple databases (or "datasets").

[cportele]

Discussion 2018-03-27: Change sentence in the requirement to "id is a local identifier of the feature" and clarify that strictly only the URI needs to be unique. Additional restrictions are implementation dependent.