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
404 stars 108 forks source link

Georeferencing Data Unavailable to External Apps #2188

Open mavery1763 opened 1 year ago

mavery1763 commented 1 year ago

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 commented 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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: image So situation like this shall be considered invalid by Mapper: image Is this what you are up to, @mavery1763?

mavery1763 commented 1 year 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.

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 1 year ago

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

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.