-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Georeferencing Data Unavailable to External Apps #2188
Comments
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. |
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. |
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 I tend to close this as wont-fix or invalid, but I'm open to feedback. |
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:
***@***.***>
|
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". |
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. |
Dear @mavery1763 , read again this line by @dg0yt :
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 I hope this makes the discrepancy clear. |
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:
***@***.***>
|
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. |
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: |
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:
***@***.***>
|
Steps to reproduce
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
The text was updated successfully, but these errors were encountered: