search

koopjs / FeatureServer

An open source Geoservices Implementation (deprecated)
https://geoservices.github.io
Other
104 stars 32 forks source link

Object IDs collide when FeatureServer/Winnow generates them #82

Closed dmfenton closed 6 years ago

dmfenton commented 6 years ago

When there is nothing specified in metadata.idField FeatureServer (by way of Winnow) will generate objectids automatically starting from zero. Because it always starts from zero you could have different source features given the same objectid. This results in bugs due to caching by ArcGIS clients.

Relevant code is here:

https://github.com/koopjs/winnow/blob/master/src/executeQuery.js#L66 https://github.com/koopjs/winnow/blob/master/src/executeQuery.js#L79-L84

FeatureServer and Winnow should avoid this situation with a more intelligent way of generating object ids.

Some options:

  1. don't generate an objectid automatically at all (this may break some clients)
  2. calculate a numeric hash of a feature (this may hurt performance)
  3. generate a random object id per feature (unknown effect on arcgis clients)
  4. add a numeric prefix that maps to the source request where the source features were requested (may be some complex logic here if the clients try to query the source for the same individual feature)
rgwozdz commented 6 years ago

1. don't generate an objectid automatically at all (this may break some clients) . This will definitely break ArcGIS Pro and likely others

2. calculate a numeric hash of a feature (this may hurt performance) This can be done using farmhash, but it results in a 32bit unsigned integer, which can result integers greater than the maximum ObjectID value for ArcGIS Pro (2,147,483,648)

3. generate a random object id per feature (unknown effect on arcgis clients) If these are not persisted across requests, this unfortunately leads to errors in Pro and others. For example, if one loads the attribute table, IDs there can become out of sync with those points on the map that may get generated on follow up requests. So table selects, identifies, and "zoom to feature" functions can fail.

4. add a numeric prefix that maps to the source request where the source features were requested (may be some complex logic here if the clients try to query the source for the same individual feature) I think this is what will need to be done..

rgwozdz commented 6 years ago

Fixed in FeatureServer 2.11.0 and winnow 1.14.0. Used the numeric-hashing method noted above, but rescaled the output so max hash is 2,147,483,648.