You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One option that has been discussed is allowing users to upload whole AOIs, geodatabases, and other such collections of data to be processed as an update/version. This idea is already discussed in issue #18, but one aspect that was not mentioned is what to do about data that has been removed or is otherwise absent from the update upload.
An easy assumption would be that any missing data has been deleted and should be marked as such in the ebagis database. Unfortunately, this scenario breaks down when we consider that an upload may only include portions of the data that are in the database due to selective downloads or the removal of unchanged data for more efficient uploads.
Similarly easy is the assumption that we cannot determine a user's intent merely by the fact that data is absent, and any absences should simply be ignored. I believe this assumption is much safer, but does not allow users with a "batch delete" method: if users want to mark data as removed in ebagis, it would have to be done on each data object individually though the API.
(This workflow may not be a problem, given that previous discussion has hinted at only allowing admin users to mark data as deleted, which would likely not be done using an uploaded update.)
Another option would be to include in the metadata in the upload specific flags for removed data. That is, if a user deletes data via the desktop bagis application, bagis will mark the metadata entry for that data as such. Upon processing the update upload, ebagis will read the metadata for any removed flags; only upon getting this confirmation of removal will ebagis mark data as removed. Otherwise absent data will be ignored.
I'm sure that other hybrid approaches to this problem exist. If after discussion, none of these three ideas adequately solve the problem, then we will have to brainstorm some other ideas.
The text was updated successfully, but these errors were encountered:
One option that has been discussed is allowing users to upload whole AOIs, geodatabases, and other such collections of data to be processed as an update/version. This idea is already discussed in issue #18, but one aspect that was not mentioned is what to do about data that has been removed or is otherwise absent from the update upload.
An easy assumption would be that any missing data has been deleted and should be marked as such in the ebagis database. Unfortunately, this scenario breaks down when we consider that an upload may only include portions of the data that are in the database due to selective downloads or the removal of unchanged data for more efficient uploads.
Similarly easy is the assumption that we cannot determine a user's intent merely by the fact that data is absent, and any absences should simply be ignored. I believe this assumption is much safer, but does not allow users with a "batch delete" method: if users want to mark data as removed in ebagis, it would have to be done on each data object individually though the API.
(This workflow may not be a problem, given that previous discussion has hinted at only allowing admin users to mark data as deleted, which would likely not be done using an uploaded update.)
Another option would be to include in the metadata in the upload specific flags for removed data. That is, if a user deletes data via the desktop bagis application, bagis will mark the metadata entry for that data as such. Upon processing the update upload, ebagis will read the metadata for any removed flags; only upon getting this confirmation of removal will ebagis mark data as removed. Otherwise absent data will be ignored.
I'm sure that other hybrid approaches to this problem exist. If after discussion, none of these three ideas adequately solve the problem, then we will have to brainstorm some other ideas.
The text was updated successfully, but these errors were encountered: