long to int coordinates, refactoring

[rtroilo]

This PR change the internal representation of the "osm-coordinates" from a long to int data-type.
It mainly affects the OSHDBBoundingBox class and a new OSMCoordinates helper class .

The OSHDBBoundingBox had 3 construtors with different data-types as arguments:

• double type arguments, lon/lat wgs48 representation e.g. 8.6724, 49.3988
• int type arguments, also lon/lat wgs48 but omitting the decimal parts, e.g. 8, 49
• long type arguments, the interal "osm-coordinates", e.g. 86724000, 493988000

For better distinction, new constructor functions are introduced,

• bboxLonLatCoordinates, for lon/lat coordinates
• bboxOSMCoordinates, for "osm-coordinates"

And some helper methods

• OSMCoordinates.toDouble -> from "osm-coordinate" to lon/lat coordinate
• OSMCoordinates.toOSM -> from lon/lat to "osm-coordinate"

The refactoring where mostly done with search&replace like

var bbox = new OSHDBBoundingBox(-180, -90, 180, 90); // before
var bbox = OSHDBBoundingBox.bboxLonLatCoordinates(-180.0, -90.0, 180.0, 90.0); // after

OSHDBGeometryBuilder also got a new helper method

• getCoordinate which converts a "osm-coordinates" into jts.Coordinates

other refactorings

OSHEntity

• getNodes, getWays don't throw an exception any more!
• code refactoring to avoid duplicated codelines

OSHDBHandler

The OSHDBHandler class in the etl module got some refactoring, mainly to get rid of duplicated codes sonar-lint warnings. For than a new OSHDBHandlerTest class were written.

Corresponding issue

Closes #320

Checklist

• My code follows the code-style rules, and I have checked on the static analyses and benchmark (if applicable) results
• I have commented my code
• I have written javadoc (required for public classes and 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
• I have adjusted the benchmark or created an issue in the corresponding repository

[rtroilo]

There are some minor code cleanups in e.g. MapReducer

 (new TagTranslator(c)).close(); // before
 new TagTranslator(c).close(); //after

I could revert this, but I think there a reasonable, let me know.

[tyrasd]

At first glance this one looks good, I'll take a deeper look this afternoon. Can you in the meantime add a line or two to the changelog please, so this is ready to be merged?

[rtroilo]

At first glance this one looks good, I'll take a deeper look this afternoon. Can you in the meantime add a line or two to the changelog please, so this is ready to be merged?

Sure, thank you.

Please while you do the review, have a deeper look/critical eye on the changes within the utils/geometry packages. As there are not just search&replace changes. The test run through, though.

Also I'm not happy with the naming of the helper function OSMCoordinates.toDouble. What do you think about toLonLat,toWGS48, or similar.

[tyrasd]

Already some general remarks (mostly inline, and one additional one below).

• couldn't some of the parameters of the ZGrid class also be downgraded to int from long (e.g. as in … int denormalizeLon(int lon) { …)?

Please while you do the review, have a deeper look/critical eye on the changes within the utils/geometry packages. As there are not just search&replace changes.

I'm still taking a deeper look at these parts right now.

[tyrasd]

Also I'm not happy with the naming of the helper function OSMCoordinates.toDouble. What do you think about toLonLat,toWGS48, or similar.

I agree that toDouble is not the best possible name. I'm also not sure what the best one actually is, but toWgs84 does sound ok for me.

[rtroilo]

I agree that toDouble is not the best possible name. I'm also not sure what the best one actually is, but toWgs84 does sound ok for me.

I renamed toDouble to toWgs84. It is definitive better then before.