Changing georeferencing from .proj4 strings to EPSG is not working

[marcovandersson]

I have an old map created in 0.5.96 in which I have used the .proj4 string definition for the swedish SWEREF99TM, to be able to import and use Kartaapullautin results in a geospatially correct manner. But when I try to change the definition in 0.6.1. to the corresponding EPSG:3006 the true coordinate system seems to be lost. The background template files (georeferenced) is no longer alinged with the maps features.

Not a really big issue since I can keep the .proj4 defintion. But anyway.

[dg0yt]

Could you at least provide your old .proj4 definition?

[marcovandersson]

The used definition is +proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs Which is according to ESPG:3006 @ http://spatialreference.org/ref/epsg/3006/

[dg0yt]

I was not able to reproduce an error with a map created in Mapper 0.6.0 with the Proj4 definition, and then changing georeferencing to EPSG:3006. You may send test files to dg0yt AT darc.de.

[marcovandersson]

The original file was probably created in 0.5.96 and is working in 97. But I cannot redefine to EPSG. The very same map also crashes when trying to open it with 0.6.1 (prob described in #618). I'll email you the file!

[dg0yt]

It is not the change from PROJ.4 to EPSG definition which is causing the trouble. The original georeferencing setting have declination and grivation values of zero degrees. Any change to the georeferencing will trigger a recalculation of grivation. If you adjust the declination to a value such that grivation becomes zero (and don't have the map rotated), the georeferenced templates will stay in their current position, relative to the map

Mapper is designed for IOF standard maps, i.e. top is magnetic north. So the grivation results in a rotation of the grid. There is already ticket #331 for map north other than magnetic, but for now you will have to use a fake declination if you want a different arrangement.

[dg0yt]

I would like to hear opinions on how to handle this. From my point of view it is the old file which has wrong data. In general it is correct to keep the declination when changing the coordinate reference system. However, we have a special case here, with both declination and grivation being zero - this is likely to be wrong and could trigger a dialog. Leaving the wrong data untouched is not an option IMO.

[marcovandersson]

The reason why I changed the grivation was to be able to simply add meridians to the map, since such function (create meridians with a specific symbol) is absent in OOM. If I change it to 0 degrees I easily can switch from proj4 to EPSG. So, does this call for a function to generate meridians manually?

[dg0yt]

Are these types of meridians needed for orienteering maps? Anyway, it is a separate feature request.

For handling parallel north lines, we offer an area symbol of properly spaced lines. You might use a modification of that symbol. Once an object is created for this symbol, you may mark the symbol protected so that it doesn't interfere with editing other objects in the map.

[pkturner]

Saving all 3 of declination, grivation, and CRS in the .omap file will lead to issues like this. When the 3 are inconsistent what can you do? In this case, Mapper worked OK for marcovandersson until the CRS was changed. Up to that point, Mapper needed only the grivation and CRS when performing georeferencing transformations.

Upon changing the CRS, Mapper looked to the former declination, which was inconsistent with the former CRS and grivation, which had been working OK (from the user's point of view).

It is possible to fix this, but I doubt it's worth the effort and the burden of maintaining an obscure feature for the sake of erroneous old files.

[dg0yt]

@pkturner In a perfect world, saving just CRS and declination might be enough. In practice, saving and loading (CRS plus) both declination and grivation, rounded to a fixed number of decimal points,

• helps to maintain numerical stability across differents systems,
• helps to mitigate issues from CRS data changing or being missing (for a recent issue see #1207, OSGeo/proj.4#1245 for effects related to the transition from PROJ 4.9 to 6),
• is consistent with user expectations that the information displayed in the dialog 2 years ago is unchanged when loading the file next year.

The issue is really limited to the initial georeferencing setup via the dialog. The dialog's "grivation locked" feature handles the fact that there is no point in determining grivation while you are entering the CRS and reference points, before you enter the declination. However it needs to be done in the end, instead of leaving all angles at zero.

[pkturner]

I agree with satisfying user expectations that the displayed parameters should not change, and absolutely so if it's under user control such as declination. However, a changed CRS definition is bound to affect users one way or another.

Now I realized that the "initial georeferencing setup" side of this issue is addressed by my PR #1206. I verified that the pull request causes the declination to vary from zero, upon initial setup.