Open afsmythe opened 2 years ago
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
?
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.
Right now, the specification requires that externally stored spatial features are linked to Precinct using the feature's attribute table's record index.
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 toFeatureIdentifier.Index
we might also support aFeatureIdentifier.FeatureAttribute
type.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 asFeatureIndentifier.Index
in 6.0 feeds.