Georeferencing Data Unavailable to External Apps

[mavery1763]

Steps to reproduce

1. Create and save a map with georeferencing data using UTM coord ref system, but omitting the N/S designator from the UTM Zone spec (e.g., UTM/WGS84 Zone 17 instead of UTM/WGS84 Zone 17 N). It has been speculated that absence of the N/S zone designator is the cause of the issue.

Actual behaviour

When a recent OOM map is uploaded to Livelox, the georeferencing preview shows the map (that should be in Ohio, USA) positioned in the Pacific Ocean off the coast of South America. When this same map is specified as the base map for course design in Purple Pen, there is no obvious issue until a course file is exported in IOF XML 3.0 format and it is seen that all controls lack geographic coordinates.

When the N designator is added to the UTM Zone spec and the map is saved in omap format, and that omap-formatted map is used as the base map in Purple Pen, the XML course file export includes the geographic coordinates of the control locations. However, the georeference preview in Livelox continues to show the map in the same location off of the South American coast.
 
The workaround is to save the omap file in OCAD format, no other changes required. When uploaded to Livelox, the OCAD-formatted file is properly positioned in the world, and when used as the base map in Purple Pen the exported course file includes geographic coordinates for all controls, even as the UTM Zone spec continues to be without the N/S designator.

Expected behaviour

External apps that rely on an accurate base map should behave exactly the same regardless of the format of the map file (omap or ocd) .

Configuration

Mapper Version: 0.9.5
Operating System: Windows 11 Home, v22H2

[mavery1763]

It is noted that the hemisphere designator in the georef dialog box in OOM is the first letter only, i.e., N or S, whereas in OCAD it is the complete word, i.e., North or South.

Not sure that this is the root cause of the issue, but it is an observed difference.

[matstroeng]

This behavior was caused by a bug in Livelox, which now has been fixed. Still, for clarity, it would be good if the N/S designator was mandatory in the OOM user interface.

[dg0yt]

Thanks for the feedback. AFAICS the Mapper UI really tries hard to suggest the N/S suffix but doesn't enforce it.

We are talking about the user-facing string (a "display name") which was never meant to be directly interpreted in external tools. The precise specification in the file format is carried as <spec language="PROJ.4">+proj=utm +datum=WGS84 +zone=17</spec>.

I tend to close this as wont-fix or invalid, but I'm open to feedback.

[mavery1763]

Thanks to both of you. I am not a programmer, and so have no idea what's being requested in terms of maintenance effort, but I would say that the precise specification in Kai Pastor's comment is ambiguous without the hemisphere designator being included. The better solution is to require the mapper to include it during map development rather than have the authors of external apps that need the information make an assumption that in some cases can be incorrect.

…

On Tue, Nov 7, 2023, 6:50 AM Kai Pastor ***@***.***> wrote: Thanks for the feedback. AFAICS the Mapper UI really tries hard to suggest the N/S suffix but doesn't enforce it. We are talking about the user-facing string (a "display name") which was never meant to be directly interpreted in external tools. The precise specification in the file format is carried as <spec language="PROJ.4">+proj=utm +datum=WGS84 +zone=17</spec>. I tend to close this as wont-fix or invalid, but I'm open to feedback. — Reply to this email directly, view it on GitHub <#2188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDXQBOZABWYJHY52OOF5ED3YDIN63AVCNFSM6AAAAAA65TULZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGM2TCMRSGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dg0yt]

I would say that the precise specification in Kai Pastor's comment is ambiguous without the hemisphere designator being included.

No, there is zero ambiguity in that spec with regard to the hemisphere. This is not common language.

In contrast, a common language display name might even include localized text, e.g. "UTM 17 Südhalbkugel".

[mavery1763]

Well, them let's just agree that we're going to disagree on this small point, as for a given UTM Zone without the hemisphere being specified, for a given set of coordinates there are two positions in the world that are possibly being referred to.

I can agree with a 'wont-fix' as the user can easily add the hemisphere to the Zone in the event that it is missing and causing a problem.

Thank you for your support on this generally outstanding mapping application.

[jmacura]

Dear @mavery1763 , read again this line by @dg0yt :

We are talking about the user-facing string (a "display name") which was never meant to be directly interpreted in external tools. The precise specification in the file format is carried as <spec language="PROJ.4">+proj=utm +datum=WGS84 +zone=17</spec>.

and then consult the PROJ.4 documentation for UTM: https://proj.org/en/9.3/operations/projections/utm.html

There is no ambiguity. The string states clearly it is a projection on the northern hemisphere. If it won't, then there would have been the +south parameter.

I hope this makes the discrepancy clear.

[mavery1763]

Thank you for your attempt to add clarity, jmacura, as apparently the points that I submitted about the issue have been unclear as well as my subsequent comments. As things stand today, OOM allows a mapper to leave the georeferencing for their map in an ambiguous state - in common language - by not requiring the hemisphere to be input with the other UTM georeference data. In code, a UTM Zone spec without the hemisphere designation will be unambiguous, as noted in the PROJ.4 documentation, but incorrect if intent is that it be in the Southern hempisphere. The change request intended to be conveyed in the issue submission is to make the hemisphere designation mandatory input when using the UTM CRS. While it is a simple fix for a user in the Southern hemisphere to add the 'S' if it has been omitted, but only if the user has easy access to OOM (or OCAD, etc.). Further, if the user does not take steps to visually confirm that the georeferencing is correct, the error will be unknown to the user and will propagate to other applications.

…

On Fri, Nov 10, 2023 at 5:06 PM jmacura ***@***.***> wrote: Dear @mavery1763 <https://github.com/mavery1763> , read again this line by @dg0yt <https://github.com/dg0yt> : We are talking about the user-facing string (a "display name") which was never meant to be directly interpreted in external tools. The precise specification in the file format is carried as <spec language="PROJ.4">+proj=utm +datum=WGS84 +zone=17</spec>. and then consult the PROJ.4 documentation for UTM: https://proj.org/en/9.3/operations/projections/utm.html There is no ambiguity. The string states clearly it is a projection on the northern hemisphere. If it won't, then there would have been the +south parameter. I hope this makes the discrepancy clear. — Reply to this email directly, view it on GitHub <#2188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDXQBO4BR4L2RXAJYSQDPGLYD2QPLAVCNFSM6AAAAAA65TULZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGUYDAMJUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pkturner]

The points that I submitted about the issue have been unclear ... The change request intended to be conveyed in the issue submission is to make the hemisphere designation mandatory input when using the UTM CRS.

If that was your intent, then this issue has indeed been unclear.

The initial description of the problem is based on the behavior of external apps. In the subsequent discussion, developers describe how the omap file contains a precise specification of the UTM zone, and that the problem was due to a bug in Livelox.

Making the hemisphere designation mandatory in user input to Mapper, is an idea that might have some merit. The current discussion has been tangled up with external applications, and thoroughly obscures that idea. It would need to be a separate issue.

[jmacura]

So if I try to sum up... The issue request is actually to prevent "Map Georeferencing" dialog to show "valid" until there is "N" or "S" filled in the "UTM Zone" field. I mean, here:

So situation like this shall be considered invalid by Mapper:

Is this what you are up to, @mavery1763?

[mavery1763]

Absolutely. In common language, entry of UTM Zone 31 is ambiguous as it can be either UTM Zone 31 N or UTM Zone 31 S, but what it really should be is unspecified by the user requiring OOM, and other applications in turn, to make an assumption. The requested protocol to submit the issue was followed. - The steps to replicate the issue were clearly stated - simply omit the hemisphere designator from the UTM Zone spec - The observed misbehaviors were stated - there's nothing to indicate that anything is wrong except for the observed behavior of external applications. - The expected behavior is as stated - external apps should handle the OOM-formatted map in exactly the same manner as the same map in OCAD format is handled I do not see the value in submitting a separate issue.

…

On Sun, Nov 12, 2023 at 7:50 AM jmacura ***@***.***> wrote: So if I try to sum up... The issue request is actually to prevent "Map Georeferencing" dialog to show "valid" until there is "N" or "S" filled in the "UTM Zone" field. I mean, here: [image: image] <https://user-images.githubusercontent.com/5598693/282299299-a0fdf420-49af-4306-ba35-086ac7d6f6ba.png> So situation like this shall be considered invalid by Mapper: [image: image] <https://user-images.githubusercontent.com/5598693/282299346-101a4655-d97a-4fe6-a84b-e7ff98f3dc36.png> Is this what you are up to, @mavery1763 <https://github.com/mavery1763>? — Reply to this email directly, view it on GitHub <#2188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDXQBOYBQBMGYAR65D2BS63YEDA2PAVCNFSM6AAAAAA65TULZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBXGEYTQMRWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dg0yt]

The steps were clear in all rigor. We just don't make the same conclusions about the relevance.

• IMO it was confirmed that an external explication was interpreting unsuitable data. We are glad that this is fixed now.
  (In fact, the external software's defect would not have been noticed if that data field value would have had a hemisphere indicator.)
• In that sense, the issue title "Georeferencing Data unavailable to external apps" is misleading. OOM uses a (fairly) precise specification based on a popular open source package.
• OOM already strongly suggests to enter the hemisphere indicator, with label, combo box, "Calculate" button.
  

Personally I find it much more confusing that UTM zone 17N isn't 17 N, and 17 S isn't 17S. I think there exist users which will intuitively enter 17 and some geographic coordinates, but will stumble over what to enter after the zone number.

But I see that it is currently possible to enter a configuration that makes no sense, such as zone 17 with southern latitude not mapping to the +south spec output. This should be fixed: Zone and latitude should give a consistent picture. Enforcing the hemisphere indicator input may contribute to solving this issue. It just doesn't update old maps.