Expand ExternalGeospatialFeature.FeatureIdentifier to support column:value pair

[afsmythe]

Right now, the specification requires that externally stored spatial features are linked to Precinct using the feature's attribute table's record index.

<Precinct id ="">
 <..>
 <SpatialBoundary>
   <ExternalGeospatialFeature>
     <ExternalFileId>ef1</ExternalFileId>
     <FileFormat>shp</FileFormat>
     <FeatureIdentifier>
       <Index>3</Index>
     </FeatureIdentifier>
   </ExternalGeospatialFeature>
 </SpatialBoundary>
 <..>
</Precinct>

The VIP 6 Feedback Group identified that there is a possible improvement to support this link to Precinct through using a column:value pair to identify the record in the geo-spatial feature. In addition to FeatureIdentifier.Index we might also support a FeatureIdentifier.FeatureAttribute type.

<Precinct id ="">
 <..>
 <SpatialBoundary>
   <ExternalGeospatialFeature>
     <ExternalFileId>ef1</ExternalFileId>
     <FileFormat>shp</FileFormat>
     <FeatureIdentifier>
       <Index>3</Index>
       <FeatureAttribute>
          <Name>PPartName</Name>
          <Value>0001.06</Value>
       </FeatureAttribute>
     </FeatureIdentifier>
   </ExternalGeospatialFeature>
 </SpatialBoundary>
 <..>
</Precinct>

In the example above, there would exist a record in the shapefile's attribute table with a value of 0001.06 in a column named PPartName. This record would have an attribute table index of 3.

This FAQ from ESRI summarizes the inherent instability of using the attribute table's index value for identifying shapes. Specifically, the FID column is what is used as FeatureIndentifier.Index in 6.0 feeds.

[JDziurlaj]

If the concern is that the shape file(s) and the feed will be out of sync, is that not adequately handled by the use of a Checksum on the ExternalFile?

[afsmythe]

This isn't so much a concern as it is an opportunity to make the associations between the VIP feed and the ExternalGeospatialFeauture more easily managed.

Right now, a data provider would need to "look in" the externally stored files to retrieve the Index value (AKA the FID) from the attribute table. The FID value is not stable and can change frequently.

The FeatureAttribute addition would provide a method of assigning the externally stored feature without having to "look in" to the datset. For example, a data provider might provide a precinct OCDID value in a column "ocdid" of the attribute table that would link the VipObject.Precinct to the externally stored feature in lieu of the (unstable) FID/Index.

The FeatureIdentifier.Index was made optional in the XSD in preparation for the addition of something like a FeatureAttribute, and if this addition was made we'd likely want to wrap Index and FeatureAttribute in a choice element.