Mapper: Magnetic declination online lookup does not work

[yevhenmazur]

Steps to reproduce

1. Setup map coordinate reference system
2. Press 'Lookup' button in the 'Map north' section and confirm the source.

Actual behaviour

The online declination lookup failed:
Expected ' ', but got '>'.

Expected behaviour

The declaration field is filled automatically.

Configuration

• Mapper Version: Any version (all stable builds from 0.6.1 till 0.6.6 + current have been tested)
• Operating System: Any platform (Windows and Linux have been tested)

Obviously, something wrong with endpoint http://www.ngdc.noaa.gov/geomag-web/ . I think the Mapper should have the list of sources of declaration, in order to avoid such situations.

[Symbian9]

This option depend on 3rd party API, that from time to time changed by organisations not related to OpenOrienteering Project.
As for me, better choice there would be make own database for magnetic variations, that would be hosted (and cached) on openorienteering.org website with own stable API for OOM.

Another option is adding in main "Settings" dialog special tab for "Geodata sources" where user can input/edit URL for external websites API used in OOM if it will be changed after release of OOM.
No need recompile everytime full OOM for fix 3rd party API links.
This is my point of view.

[dg0yt]

The response from this service not well-formed XML. The whitespace around = in the latitude line is probably causing the errors at the moment:

~


0.5.0.7



2016.95355


50.00000


8.00000


0.00000


2.06092


0.13074


0.36144



~

There is no other standard format, not even another service which provides machine-readable data, so we cannot easily provide alternative services just by configuration (unless you also want to configure a regular expression or XPath expression).

[dg0yt]

The issue is that the service moved to https. So far our builds of Qt do not support https, and I'm not sure this will change: There are some legal aspects to be reviewed.

[Symbian9]

@dg0yt, follow this for latest changes in API:

• https://www.ngdc.noaa.gov/geomag/WMM/WMMChangesToTheCode.shtml

[dg0yt]

@symbian9 This API is not relevant for us. Stop the noise.

[Symbian9]

The response from this service not well-formed XML.

This is an API problem and maybe better firstly try connect to its owners ([email protected]) and give info about problem with spaces near = symbols?

@dg0yt, Tell me if you will send report to NOAA about problem in their XML output. (If not I will try do this report)

[mitchellkrome]

The problem is simply that the service moved to https and responds with a 301 (page moved) error because the url used in mapper is http. When you point it at the right page the xml parsing is fine (but as was already mentioned the packaged Qt build doesn't have https networking enabled)

[dg0yt]

@Symbian9 I had an e-mail prepared but had to stop it because I found the real issue. Just read my second post. And note that API you linked in your second post IS NOT the web service API. So even if it were an API problem, this API [you linked in your second post] is not relevant for us (using the web service). Now you created even more noise. Please stop giving advice where you are unable to understand the problem. I do not have the time to explain every detail, everytime.

[dg0yt]

The OpenSSL license is incompatible with the (pure) GPL 3 license used for OpenOrienteering Mapper. This is not an issue for Linux distributions which distribute OpenSSL with their operating system. But this is the minority of the users. For Windows, macOS and Android, we cannot provide OpenSSL for this reason.

For Windows, WinHTTP might provide an alternative ways to fetch the required information.

For macOS, I have no idea if alternative APIs exist.

For any system, a separate executable under a more permissive license would be another option to decouple Mapper and OpenSSL (or alternative providers). Invoking this executable is not considered a violation of the GPL.

The next release will probably have this feature disabled for anything but Linux.

[dg0yt]

So now we open the browser window instead. Should be convenient enough for a feature which is used once in a while per map.

[dl3sdo]

Would be curl an option?
https://curl.haxx.se/

[dg0yt]

curl or wget would do. curl could even use the operating system's Schannel on Windows. The question is how much we want to add to the packages for a feature which is used once in a while per map.

[yevhenmazur]

Or replacement OpenSSL with static linked GNUTLS? (as a long term solution of course)

[dg0yt]

So far the network request is made via Qt which doesn't seem to support anything but OpenSSL.

Note that this whole feature was done as a proof-of-concept of what is easy to achieve...

[dg0yt]

For the record: For future online features (like WMS) via GDAL, we will need the curl library anyway.
https://trac.osgeo.org/gdal/wiki/LibCurl

[Symbian9]

So now we open the browser window instead. Should be convenient enough for a feature which is used once in a while per map.

Think, that it's the best solution for this problem.

[Abbe98]

Would a proxy be a acceptable temporary solution? I could set one up over at Google App Engine.

[dg0yt]

Well, curl already landed in unstable and 0.7.0. Now someone has to write the HTTP request with curl API.

[dl3sdo]

I have implemented and successfully tested (Ubuntu 16.04) the HTTPS access with curl.
I send you the modified files by email.

[Symbian9]

@dg0yt, Remo Madella create alternative lookup webpage, so maybe if we connect to him we could use it as alternative

• MAGNETIC AND GRID DECLINATION FOR ORIENTEERING MAPS (by Remo Madella)
  
  
  
  • http://www.remmaps.it/mag/
  
  

P.S.: This webpage in development, so could be not stable or wont work yet propperly

[wanacode]

As the magnetic declination lookup is currently out of action the website mentioned in the above comment has proved useful. The correct link is http://www.remmaps.it/mag/

[Symbian9]

@wanacode, thanks, I just fixed link in my comment too ;)