search

OpenOrienteering / mapper

OpenOrienteering Mapper is a software for creating maps for the orienteering sport.
https://www.openorienteering.org/apps/mapper/
GNU General Public License v3.0
402 stars 106 forks source link

Imported vector data misaligned when CRS set to 5514 #1981

Open jmacura opened 3 years ago

jmacura commented 3 years ago

Steps to reproduce

  1. set coordinate system to EPSG:5514 (S-JTSK / Krovak EastNorth, the national system of CZ)
  2. add raster template to Mapper
  3. File->Import->Anything (tested SHP and GPKG)

Actual behaviour

The imported data are misaligned by some 13 metres. By follow-up verification, I have realized that the imported vector data are misplaced while the raster (JPG, tested also with GeoTIFF) is placed correctly.

Expected behaviour

All data should fit.

Configuration

Mapper Version: 0.9.5, 0.9.4, 0.9.2 Operating System: Windows 10 Pro 20H2

image The semi-transparent-purple areas are buildings imported from Shapefile. Contours (here in blue) are imported from another Shapefile and also shifted. The WMS84->local system transformation is not to blame here as the contours were created in the EPSG:5514 CRS from a point-cloud originally captured in EPSG:5514.

image (More or less) the same area in QGIS 3.20 where everything fits.

image Now the full-purple areas are the same buildings imported from Shapefile, yet now were saved in EPSG:3045 (ETRS89/UTM33N)

krticka commented 3 years ago

Yes, there is a problem with importing 5514 vector data into 5514 project when transformation is adding extra shift to the imported data. Current workaround is to import these data just using real coordinates only (without using CRS).

jmacura commented 3 years ago

Yes, there is a problem with importing 5514 vector data into 5514 project when transformation is adding extra shift to the imported data. Current workaround is to import these data just using real coordinates only (without using CRS).

Could you be more descriptive about that workaround? Shall I delete the CRS information from the file?

krticka commented 3 years ago

Deleting the PRJ file when using shapefile is the easiest solution.

jmacura commented 3 years ago

Deleting the PRJ file when using shapefile is the easiest solution.

Oddly, it indeed works. Díky za tip!

Keeping this issue opened as it is still a bug that needs to be resolved.

jmacura commented 1 year ago

This is a sad story. I have opened this issue some two years ago and meanwhile myself forgot about this issue. Today I have spent 2 hours figuring out why the map background is misaligned against imported contour data and my colleague spent countless hours mapping on misaligned contours 😭

I am not posting this just to complaint. I am aware OO Mapper is a voluntary project (and a great one!). I am posting this in curiosity whether I am really the only one hitting this issue again and again?

dg0yt commented 1 year ago

If I didn't miss it: Did you provide test files to reproduce and resolve the issue? We can establish a confidential channel for sensitive data.

lpechacek commented 1 year ago

I am posting this in curiosity whether I am really the only one hitting this issue again and again?

Nope, I'm stumbling over it again and again as well. AFAIU, the root of all evil is a broken EPSG:5514 definition in PROJ. Mapper has a hack in place to silently replace the broken definition with a good one (https://github.com/OpenOrienteering/mapper/commit/910d725c19b40aee885dedd5cc6743c07086238f). Good for users (most of the time) but bad for code maintainers (when issue reports arrive).

For template images there is a workaround to skip the coordinate translation by telling the import code that the data to be imported have the same CRS as the map. That works great for raster templates but the solution does not cover vector data import.

lpechacek commented 1 year ago

FWIW, (public) test data for this issue. issue-1981-shifted-krovak.zip