Proposal for new ContributionTypes for CellIterator

[SlowMo24]

The CellIterator is one of the key elements (and a great one, too!) of the DB. These are some proposals for ContributionTypes, to make the results more self-evident, especially when being used through the API:

• [ ] APPEARING and DISAPPEARING instead of CREATION and DELETION if an object is moved to or from the examined Sandbox but existed somewhere else before/after
• [ ] VERSIONONLY for contributions changing only the Versionnumber. The Objective is to never get empty results because every change should be monitored (this might also create the need for other Types I cannot think of now).
• [ ] Be more detailed on TAGCHANGE . The Code already exists here: https://gitlab.gistools.geog.uni-heidelberg.de/giscience/big-data/oshdb/apps/MMNepalAnalyses/blob/master/src/main/java/org/heigit/missingmaps/nepalanalyses/analyses/lambdaimplementations/followup/FMapper.java#L170 and might keep users from coding it again themselves

please consider the discussion on https://gitlab.gistools.geog.uni-heidelberg.de/giscience/big-data/ohsome/oshdb/issues/118

A definite debate is needed on this topic!

[SlowMo24]

I would like to contradict https://gitlab.gistools.geog.uni-heidelberg.de/giscience/big-data/ohsome/oshdb/issues/127 It should be impossible for a contribution to have no ContributionType. If it is we should solve this.

[FabiKo117]

FYI: I stumbled today upon the case, where there was an object in the data extraction response of the ohsome API (https://www.openstreetmap.org/way/150363603) that had two times exactly the same values (geometry and properties) and no contribution type. @SlowMo24 told me that this might be caused by a change in the unclipped geometry of the object, which is not reflected of course in my clipped response. I find that a bit confusing.

[SlowMo24]

• [ ] imo no Contribution should have 0 contribution types (as it is currently the case, e.g. if a the major version of a waymember changed that did not introduce a GEOMETRYCHANGE). So a contribution type OTHER with detailed explanation or more ContributionTypes are necessary.

[tyrasd]

a contribution type OTHER

the point is that contribution types of a contribution is a Set, so if there was a contribution type OTHER, it would result in basically any contribution to be also of type OTHER. This would be confusing.

That said, we had one more distinct contribution type in the past, MEMBERLIST_CHANGE. Maybe we could add this type again (maybe slight changed to MEMBER_CHANGE?).

[SlowMo24]

just to keep the discussion alive: @rtroilo had the Idea of a contribution type: filter-passing or similar that would replace creation and deletion in case of version number >1

[Hagellach37]

We are not considering to extend the ContributionTypes. This can be handled if needed by the client.