Georeferencing Data Unavailable to External Apps

mavery1763 commented 10 months ago

Steps to reproduce

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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.

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 https://github.com/OpenOrienteering/mapper/issues/2188#issuecomment-1798351224, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDXQBOZABWYJHY52OOF5ED3YDIN63AVCNFSM6AAAAAA65TULZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGM2TCMRSGQ . You are receiving this because you authored the thread.Message ID: @.***>

dg0yt commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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.

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 https://github.com/OpenOrienteering/mapper/issues/2188#issuecomment-1806500144, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDXQBO4BR4L2RXAJYSQDPGLYD2QPLAVCNFSM6AAAAAA65TULZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGUYDAMJUGQ . You are receiving this because you were mentioned.Message ID: @.***>

pkturner commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 https://github.com/OpenOrienteering/mapper/issues/2188#issuecomment-1807118269, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDXQBOYBQBMGYAR65D2BS63YEDA2PAVCNFSM6AAAAAA65TULZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBXGEYTQMRWHE . You are receiving this because you were mentioned.Message ID: @.***>

dg0yt commented 9 months ago

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.

OpenOrienteering / mapper