onthegomap / planetiler

Flexible tool to build planet-scale vector tilesets from OpenStreetMap data fast
Apache License 2.0
1.21k stars 101 forks source link

[BUG] GeoPackageReader with EPSG:3067 results in swapped lat & lng #812

Open MaRaSu opened 5 months ago

MaRaSu commented 5 months ago

Describe the bug I have a Geopackage from Finland NLS which is using ETRS-TM35FIN i.e. EPSG:3067 projection. It has northing, easting i.e. lat & lng in swapped order compared to EPSG:4326. I wrote a quick PoC Profile with planetiler-examples support and some gitbug issues as helpers (to figure out GeoPackageReader use) and then generated tiles. All good, except tiles had swapped lat & lng and tile orientation was likewise transformed (90 degrees rotation counterclockwise, then mirrored across vertical axis and stretched vertically) so map was looking quite funny.

To Reproduce I can provide more info if needed, but probably most useful is the Geopackage file & Profile which I can share for anyone needing to repeat this.

Expected behavior Bug description should describe what went wrong vs expected.

Screenshots N/A

Environment (please complete the following information): N/A

Additional context I'm not a Java developer, but since Planetiler has a very easy to understand structure and GPT-4 helps to write Java code, I have successfully implemented previously an openmaptiles-planetiler based extensively customised Profile. Big thanks for creating this tool, it was a key trigger for my transition from raster to vector tiles! For us non-Java folks few extra tips on how to customise it could save a bit of time, but with some effort one can figure out quite easily what is needed.

For this GeoPackageReader problem I managed to fix it with help of GPT-4, making following modifications to GeoPackageReader.java:

var latLonCRS = CRS.decode("EPSG:4326", true);
coordinateTransform = CRS.findMathTransform(sourceCRS, latLonCRS, true);
...
var latLonCRS = CRS.decode("EPSG:4326", true);
CRS.findMathTransform(CRS.decode("EPSG:" + srsId), latLonCRS, true);

I was following a bit blindly GPT-4 guidance so I'm not sure if the change to findMathTransform was actually needed (I only later noticed issue #559 ) as I did not get any "Bursa Wolf" errors in my original tile generation run. To build I had to also change related test testReadGeoPackageby swapping coordinates for assert.

I also had to manually patch ${revision} in Maven local repo to get my custom Planetiler package to work as a dependency. I did not figure out yet if I need some Maven option or should use some other script than set-versions.sh to get the version info right when I did ./mvnw clean install. Thus I'm afraid that with my Java skills I'm not able to contribute a quality PR for this bug ;=)