UTM zone in georeferencing dialog off by one

[dg0yt]

dl3sdo reported on Sourceforge [tickets:#432]:

I tried to set up a new georeferenced map (ISOM 10000) and it seems that the UTM zone shown in the Map Georeferencing Dialog Box is off by one:

• if you enter the dialog for the first time and select UTM, Mapper proposes 30 N and an east value of -1.48874388 °
• now select 32 N, Mapper now sets the east value to 4.51125612 °, close dialog with OK
• re-enter dialog, Mapper now has set UTM zone to 31 N!

If you select 33 N, Mapper proposes 10.51125612 ° and will switch back to 32 N when re-entering the dialog. Since the proposed value of 10.51125612 ° is within 32 N and 4.51125612 ° is within 31 N, it seems that the finally used UTM zone is off by one when entering the UTM zone number.

Tested with 0.5.96, x64 version.

[dg0yt]

I can't see problems for real valid values.

When select "UTM" for a new map, the easting value which is used to determine Lat/Lon is at 0: This is effectively in the zone west of the current zone.

However, if you use coordinates outside the current zone and close the dialog, upon opening the dialog again it will not display that zone, but rather the one the current lat/lon belongs to. Easting/northing remains untouched. This is incorrect.

[dg0yt]

dl3sdo posted on Sourceforge:

It's certainly working, no doubt, however the behaviour is somehow weird. Try for example to set the CRS to Gauss-Krüger, the zone then starts with 1. If you increase the zone step by step the east value of the Geographic coordinates has extreme jumps (e.g., zones 24-25-26: 107.23587081 ° => -27.42845919 ° => 141.65418836 °)

Attached is a screenshot showing the east value, when for a new map UTM is selected. I can't see where the east value stays at 0, instead it becomes the already mentioned -1.48874388°. But maybe we are talking about different fields.

Another screenshot shows the behaviour immediately after the CRS is switched to UTM and Zone 32 N is selected. 4.51125612 ° is the proposed value by Mapper and this is not within 32N.

You are right, the other way from entering Geographic coordinates to the UTM Zone set by Mapper works well.

BTW: Mapper 0.53 started with 31 N and the fields remained at 0.00000000 °.

[dg0yt]

As long as "On CRS changes, keep: Projected coordinates" is selected, the dialog does not touch the projected coordinates. In this regard it works as expected. However, Mapper 0.5.3's default was "On CRS changes, keep: Geographic coordinates". I guess that most people will have base maps in a particular projected CRS, thus the new default should make sense if one wants to use a particular reference point from the base map.

Your trouble is that you enable a zone-based CRS while projected reference point coordinates are 0,0 and shall be kept. At this point there is no general way to guess both the zone and the geographic coordinates. For UTM, the zone can only be determined from geographic coordinates, or from the zone entered by the user. (For GK, nothing is currently implemented.)

Now you change the zone while keeping the out-of-zone projected coordinates. Then it is not surprising to find weird behavior. Note that the easting value of (German) GK coordinates starts with / depends on the zone number. It might be hard to define correct behavior for this corner case.

Maybe the best we could do is to track whether latitude, longitude and zone are based on actual input or valid calculation, and to block any calculation based on undefined initial values.

[dg0yt]

gandym01 posted on Sourceforge:

I like the new way UTM zones are being handled, but there are definitely some teething issues.

The following two scenarios unexpectedly produce different results:

First scenario:

– Open a blank map in OOM – Set CRS to UTM – In the zone box type "50 S" – Press Return – Move the cursor to the easting box and type "4". The UTM zone number remains unchanged.

Second scenario:

– Open a blank map in OOM – Set CRS to UTM – In the zone box type "50" – Select "50 S" from the drop down list using mouse left-click – Move the cursor to the easting box and type "4". The UTM zone number changes to "49 N" – If I now continue typing and enter a valid value (like 455371), then the UTM zone changes to "50 N" – If I now enter a valid northing, like 6245000, the UTM zone remains set to 50 N. – If I change 50 N to 50 S by typing "50 S" then pressing return, the geographic coordinates are updated. But, if I type "50" into the zone box, then choose "50 S" via mouse left-click from the drop down box, the geographic coordinates are not updated.

Suggestions:

– The zone value entered by the user should not be changed automatically by OOM under any circumstances. – Since you have now implemented an input mask for UTM zones, it is now not possible to enter an incorrect zone so the "status" is no longer needed.

This all got discovered when I opened a very old OCAD file to find that no offsets were specified. You wouldn't usually encounter the problems above unless you were altering the offsets...

gandym

[dg0yt]

gandym01 posted on Sourceforge:

Sorry, forgot to say this was tested in 0.5.96 W7x64.

gandym

[dg0yt]

baronmax posted on Sourceforge:

As a newbie I am really confused by the Georeferencing system and can't seem to get it to do what I want it to... For example if I import a osm map I get the 'correct' geolocation data (I assume - although the UTM zone seemed like it was one off - but I assume that just changes the offset) I then want to import two non geolocated ocad files that are adjacent to each other. Can I do it? No! (at least not for my second OCAD) It insists on putting my OSM map at something like 139000mm and 607000mm from the map origin whereas my second imported OCAD is near zero. I've tried modifying the geolocation co-ordinates in all of the files and resaving and reimporting but whilst I've managed put the correct information so that it matches all files in the geolocation box when I actually put my cursor on the map the mm figures are completely different (and so on different parts of the computer map...) It would be helpful to better indicate on this screen what relates to what and what impact changing one thing has on another parameter.... and I have a sneaking suspicion that it may not be my ineptitude that is at fault but there seem to be too many variables to figure it out... apart from that great program! (this is on the Mac version 0.5.96)