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
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:
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 ;=)
The text was updated successfully, but these errors were encountered:
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:
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
testReadGeoPackage
by 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 ;=)The text was updated successfully, but these errors were encountered: