For datasets that have no unique identifier with property name OBJECTID or no feature ID field targeted by metadata.idField, Koop auto-generates an integer OBJECTID by hashing the entire feature. While this is useful for the edge-case in which a feature has no unique identifier, it's potentially problematic because:
it may be costly to hash the whole feature; consider a feature with large number of attributes or complex geometry.
the feature may change with edits, and when it does, the numeric hash with change
My assumption is that most datasets will have some unique-identifier, though it is often the case that such identifiers are NOT integers. It is increasingly common for IDs to be strings. Provider developers can point idField to a string property, but some ArcGIS clients will not be able to properly consume such services (the JS API appears to work, but ArcGIS Pro does not). It would therefore be nice if a developer could direct the hasher to one specific property to hash into an integer.
As an add-on here, it seems like ArcGIS clients now support 64-bit integer IDs, so we should hash to that datatype as we move forward.
For datasets that have no unique identifier with property name
OBJECTIDor no feature ID field targeted bymetadata.idField, Koop auto-generates an integerOBJECTIDby hashing the entire feature. While this is useful for the edge-case in which a feature has no unique identifier, it's potentially problematic because:My assumption is that most datasets will have some unique-identifier, though it is often the case that such identifiers are NOT integers. It is increasingly common for IDs to be strings. Provider developers can point
idFieldto a string property, but some ArcGIS clients will not be able to properly consume such services (the JS API appears to work, but ArcGIS Pro does not). It would therefore be nice if a developer could direct the hasher to one specific property to hash into an integer.As an add-on here, it seems like ArcGIS clients now support 64-bit integer IDs, so we should hash to that datatype as we move forward.