OpenStreetMap (Mapnik) no longer works due to http: redirect

[dfandrich]

Downloading OSM tiles has started producing the error Failed to download tile in the UI in the last few days, and a log error message like ** viking [Warning]): curl_download_uri: http response: 301 for uri http://tile.openstreetmap.org/13/1296/2802.png

This appears to be due to OSM changing its server to redirect http: requests to https:

curl --out-null -sL --write-out "%{url_effective}\n" http://tile.openstreetmap.org/13/1296/2802.png
https://tile.openstreetmap.org/13/1296/2802.png

The solution is likely to just switch to https: for OSM tiles. Alternately (or additionally) the libcurl code should enable the CURLOPT_FOLLOWLOCATION and CURLOPT_MAXREDIRS options so this kind of issue doesn't happen again with other map sources.

Additionally, the other map sources should be audited to find which other ones can be switched to https: as downloading over http: is a privacy leak and security hole.

[dfandrich]

I should note I'm experiencing this in ver. 1.10 but I still don't see the current code using https: for Mapnik.

[rnorris]

I have worked on this, but not yet promoted my private code to the mainline.

This change is to make "default download setting to follow all redirects".

Which is (as noted) changing the default 'follow-location' value passed into libcurl (that has been the source of various not downloading issues over the years), as libcurl itself defaults to not following redirects.

Note as a workaround, one can override Viking's default Map entries with your own maps.xml values for the OSM Mapnik entry and specify 'https' for the URL and/or specify a 'follow-location' value. The important part is the id value needs to be 13 to override the internal entry.

i.e. for ~/.config/viking/maps.xml

<objects>
  <object class="VikSlippyMapSource">
    <property name="name">OSM-Mapnik</property>
    <property name="label">OpenStreetMap (Mapnik)</property>
    <property name="url">https://tile.openstreetmap.org/%d/%d/%d.png</property>
    <property name="id">13</property>
    <property name="zoom-min">0</property>
    <property name="zoom-max">19</property>
    <property name="copyright">© OpenStreetMap contributors</property>
    <property name="license">CC-BY-SA</property>
    <property name="license-url">https://www.openstreetmap.org/copyright</property>
    <property name="use-etag">TRUE</property>
    <property name="follow-location">2</property>
  </object>
</objects>

[TurboRadler]

Does the workaround also work with Windows "C:\Program Files\Viking\data\maps.xml"? Seems that will not function on my installation?

Kind regards

[rnorris]

I believe it should do (but I don't have immediate access to a Windows version to confirm).

Viking should read both the 'system' configuration (typically /usr/share/viking/maps.xml on most Linux distros and the Windows one as per @TurboRadler comment) plus the 'users' configuration too; if such files exist.

So for Windows, the user configuration should be C:\Users\<username>\.viking\maps.xml - if one doesn't exist, then you can create it.

[TurboRadler]

There is no success with the workaround in my installation. I had to create the directory C:\Users<username>.viking\ and the corresponding maps.xml. There is another directory C:\Users<username>\AppData\Local\viking" with user specific configurations. Also with the maps.xml in this directory the message "Failed to download tile" remains.

[Rmano]

As a data point, the workaround from @rnorris works for my installation (Manjaro Linux, Viking 1.10). I added the file to the directory because it didn't exist.

[troffasky]

For anyone playing along at home on Debian, it seems to be ~/.viking/maps.xml, ~/.config/viking/ does not exist here.

[vinc17fr]

On my Debian machines, the directory is ~/.config/viking. Perhaps your ~/.viking comes from an old installation. The viking(1) man page says:

The User Configuration File Location directory is ~/.viking for versions up to v1.8. For new installs from v1.9 onwards it is ~/.config/viking If the legacy location exists then Viking will use that in preference to the new location.

[dcom42]

Note as a workaround, one can override Viking's default Map entries with your own maps.xml values for the OSM Mapnik entry and specify 'https' for the URL and/or specify a 'follow-location' value.

thanks a lot, works for my 1.10 install under Ubuntu. I have no .config/viking, so I changed it in /usr/share/viking/maps.xml.

[thetruemist]

Note as a workaround, one can override Viking's default Map entries with your own maps.xml values for the OSM Mapnik entry and specify 'https' for the URL and/or specify a 'follow-location' value.

thanks a lot, works for my 1.10 install under Ubuntu. I have no .config/viking, so I changed it in /usr/share/viking/maps.xml.

Hi, I can confirm that. I'm on Debian now, but my home dir has a longer history...

I did not have a ~/.config/viking, I created it wiht a maps.xml. but this did not work. I do have a ~/.viking, but adding the maps.xml there did also not help. Maybe it's not used at all...

Anyway, I modified the maps.xml in /usr/share/viking, and this worked.

Thanks a lot!

[vinc17fr]

On my Debian machine, ~/.config/viking/maps.xml works as expected. With strace -f, one can see every pathname that is tried.

[sgreenslade-zb]

I mucked around a bit with this on a windows 10 machine. Putting @rnorris 's suggested xml file in C:\Users\<username>\.viking\maps.xml does indeed get Viking to use the new URL, but it immediately runs into a different issue:

Warning curl_download_uri: curl error: 35 for uri https://tile.openstreetmap.org/15/9649/12321.png

From some cursory searching, libcurl error 35 seems to be a generic SSL/TLS error, and my best guess is that curl doesn't have the right CA certificates to validate the HTTPS cert the tile server is sending. I tried a few ill-advised hacky things as a quick fix (copying cacert.pem into various directories, copying a more recent msys2 copy of libcurl-4.dll into viking's dir), but none of them worked. Should probably take this into its own issue thread, but I wanted to get the info out there in case others were confused as to why the above fix works on linux but not windows.

[rnorris]

@sgreenslade-zb As you found out, due to difficulties packaging CA Certificates and making Viking/libcurl use them on Windows; SSL verification is meant to be turned off by default in Vikings own setup in order to have a useful system.

You can try ensuring this by putting "curl_ssl_verifypeer=0" in your viking.ini file specifically. Which should be in C:\Users\<username>\AppData\Local\viking\

[rnorris]

Note that for commit c981194 (use of follow all redirects '-1') may not appear to work, but this is due to a libcurl bug (I think version v8.16 only, at least as used on Debian Unstable at time of writing), fixed in latest libcurl v8.17. See https://github.com/curl/curl/issues/18571

[sgreenslade-zb]

@rnorris Thanks for the suggestion. I tried curl_ssl_verifypeer=0 in my viking.ini, but it had no effect in v1.10. Same curl error 35.

[insomniating]

@rnorris thanks for the workaround, confirmed this is working after creating maps.xml in directory ~/.config/viking/ and adding the objects into the file that you provided. This was on a fresh install from apt on ubuntu/kubuntu 25.04

[migdal-or]

By the way, as there is no updated Windows version compiled, is it possible to setup a redirect URL which would return tiles with non-SSL HTTP? Curl seems to be integrated into windows viking package, cause manual update of my windows curl version did not help. I have tried to setup a Mapproxy on my VPS, but did not succeed.