refactor oshdb core (and more)

[rtroilo]

Refactoring oshdb core. This PR touches a lot of files because of moving of classes to different packages.

renaming methods

• OSMWay.getRef() to OSMWay.getMembers()
  this makes is more unified with the OSMRelation interface
• OSHDBTimestamp.getRawUnixTimestamp() to OSHDBTimestamp.getEpochSeconds()

deprecations of methods

• OSMEntity.getRawTag
• OSHEntity.getRawTagKeys

removed methods

• OSHDBBoundingBox.add/set
  this makes OSHDBBoundingBox immutable!

reorganisation

• move oshdb.util.OSHDBTag to oshdb.OSHDBTag
• move oshdb.util.OSHDBTimestamp to oshdb.OSHDBTimestamp
• move oshdb.util.OSHDBBoundingBox to oshdb.OSHDBBoundingBox
• move oshdb.util.CellIterator.OSHEntityFilter to oshdb.osh.OSHEntityFilter
• move oshdb.util.CellIterator.OSMEntityFilter to oshdb.osm.OSMEntityFilter
• move oshdb-api.generic.function to oshdb.util.function
  makes a common/central place for our extended java function api.

new interfaces

• OSHDBTimeable
  main interface for OSHDBTimestamp, allows to "flatten" OSMEntity and reduce object creation.
  add methods isAfter/isBefore to OSMEntity so that we directly can check like osmEntity.isAfter(timestamp)
• OSHDBBoundable
  main interface for OSHDBBoundingBox allows to "flatten" OSHEntity and reduce object creation.
  add methods intersects/isInside to OSHEntity so that we direcly can check like oshEntity.intersects(bbox)

notes

• code-style fixes will be in a separate PR to not clutter this PR with "unrelated" changes

Checklist

• I have commented my code
• I have written javadoc (required for public methods)
• I have added sufficient unit tests
• I have made corresponding changes to the documentation
• I have updated the CHANGELOG.md
• I have adjusted the examples or created an issue in the corresponding repository -> https://gitlab.gistools.geog.uni-heidelberg.de/giscience/big-data/ohsome/oshdb-examples/-/merge_requests/15
• I have adjusted the benchmark or created an issue in the corresponding repository -> https://gitlab.gistools.geog.uni-heidelberg.de/giscience/big-data/ohsome/oshdb-benchmarks/-/merge_requests/14

[tyrasd]

• move oshdb-api.generic.function to oshdb.util.function
  makes a common/central place for our extended java function api.

Not sure I can follow here. AFAICS, the "extended" java functions are only ever used in the oshdb-api module, and are only necessary elsewhere (we only need it when running queries on a remote ignite cluster with peer class loading enabled). IMHO we should put as little "stuff" into the "core" module as possible. Keeping it slim allows that some fixes don't need to be deployed on the ignite cluster for example.

PS:

move oshdb.util.CellIterator.OSHEntityFilter to oshdb.osh.OSHEntityFilter
move oshdb.util.CellIterator.OSMEntityFilter to oshdb.osm.OSMEntityFilter

If I remember correctly, we had the two classes before SerializablePredicate<X> was introduced. It could make sense to just use SerializablePredicate<OSHEntity>/SerializablePredicate<OSMEntity> instead of having this extra interface lying around in the global scope. Or, if we want to keep it for readability/simplicity: why not keep it as a subclass of CellIterator?

[rtroilo]

I saw a commit 46ec2eb which introduces an other set of PredicateSerializables again, because of circular dependencies.
So to solve this, and to avoid to have incompatible PredicateSerializables I moved them to a more central place. Also the OSH/OSMEntityFilter fits nicely into the osh/osm packages.

[rtroilo]

IMHO we should put as little "stuff" into the "core" module as possible.

Yes sounds good, so what do you think about to move the SerializedFunctions into the oshdb-util module oshdb.util.function instead of the oshdb-api module. Because there are also used by the oshdb.util.celliterator.CellIterator and oshdb.filter.Filter

[tyrasd]

For this review I only looked at some of the code (i.e. where there are comments below).

In general I like the idea behind the introduction of the new OSHDBTimeable and OSHDBBoundable interfaces, but the naming could be "improved" maybe? IMHO, it could be made clearer the the time aspect is only for points in time, while the spatial aspect is (in general) for bounded regions.

Maybe the point-in-time interface could be just OSHDBEvent (or OSHDBTemporal) which would leave us the door open to later introduce a class for time-intervals similar to OSHDBBoundable) without confusion?!

PS: I found that there were a lot of lines introduced in this PR which contain trailing spaces or empty lines consisting of only spaces. IMHO this should be avoided. Is it not possible to configure your code editor to automatically remove trailing whitespace on save? 😜

[tyrasd]

PS: I've crated branches to update the examples and benchmarks repositories:

• https://gitlab.gistools.geog.uni-heidelberg.de/giscience/big-data/ohsome/oshdb-examples/-/merge_requests/15
• https://gitlab.gistools.geog.uni-heidelberg.de/giscience/big-data/ohsome/oshdb-benchmarks/-/merge_requests/14

[tyrasd]

• I have written javadoc (required for public methods)
• I have added sufficient unit tests

It would be nice to check these off, at least for the newly created interfaces. 🙏

[rtroilo]

I removed the getTimestamp for the OSHDBTemporal interface as well.

[rtroilo]

• I have written javadoc (required for public methods)
• I have added sufficient unit tests

It would be nice to check these off, at least for the newly created interfaces. pray

I added the javadoc but I'm not sure about the uni-tests for the interfaces. I think the should be covered by the implementing classes. Do you think that is enough, or should I write some test again.

[rtroilo]

Thank you and good review!