Random blocking of OpenStreetMap tiles on Lizmap ?

Help and support
1

Hello,

I’m posting this topic here because I don’t know who else to contact about this issue (I’m French). We use open-source software Lizmap (version 3.9 - French society), and Lizmap interface allows us to add the OpenStreetMap basemap.

However, when uploading projects with this basemap, we encounter a problem with a part of OSM tiles (see picture) that we can’t figure out why after reading the terms of use (Tile Usage Policy).

As you can see in the picture, most of the tiles display correctly, and it’s worth noting that when the page is refreshed, it’s not always the same tiles that are blocked.

image
image945×436 75.5 KB

The terms of use specify that you must:

• Use the correct URL: https://tile.openstreetmap.org/{z}/{x}/{y}.png.

This is correctly configured for this URL in our QGIS project.

• Provide visible license attribution, following the Attribution Guidelines.

We clearly display the license in the bottom right corner of Lizmap software.

• Send a valid HTTP User-Agent that clearly identifies your application (or a platform X-Requested-With app ID where set automatically).

HTTP User-Agent appears correct: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36”

• From web pages, ensure a valid HTTP Referer header is sent.

Given that most tiles are displayed, can we really consider the HTTP Referer to be blocking?

If so, is there a specific place to check this? What should the HTTP Referer look like to be good?

• Cache tiles locally according to HTTP caching headers (or at least 7 days if your cache cannot read them).

Similarly, since most tiles are displaying correctly, can we really consider the cache to be the blocking factor? If so, should this be configured in the Lizmap software code or on the Apache server?

• Avoid encouraging or enabling copyright infringement.

Our application is accessible only to certain users, and their access is password-protected. In no way we are trying to encourage copyright infringement.

Thank you for your help. If you have any ideas on how to fix this tile display issue while respecting the OSM terms of service, please share them.

1 Like
2

Yes.

Please look through the other threads on the forum such as here and here where other people have reported similar things. It may also help to try a different browser, try a new incognito browser, turn off all plugins, try a different computer and a different network.

It is likely that you will need to discuss the problem with the people who develop “Lizmap”, whatever that is. You could also consider:

  • Try a different source of tiles. Whether this will work for you will depend on where you are, where you want raster tiles of, and what detail you want in them
  • Create your own tiles and point at those.
1 Like
3

Thanks for your help ! I’m going to check the different options you give to try to fix that

1 Like
4

I’ve seen the same thing happen on OpenRailwayMap.app and, funnily enough, on the Carto layer at osm.org.

5

Alas, without information about what the problem actually is and what you are doing different to everyone else no-one will be able to help… Please try the things suggested above.

6

AFAIK the blocks on the OSM server side are done as a warning ‘brownout’ where not all requests are blocked immediately, only some will randomly be replaced with the block notification image. So if you see any affected tile, that means you aren’t in compliance.

3 Likes
7

Wasn’t trying to get help for it, just mentioned it as an anecdote relevant to the thread.

8

Network log. Browser have one built-in.

If referer header is missing altogether, then situation is obvious.
I have not yet seen case where referer is present and this warning was applied.

Confirming this.

9

As far as I know, there are two possible reasons:

  1. You load the page from the filesystem, not from a webserver, look at the location bar of your webbrowsers if it says https:// or file:/// in the beginning - the latter then is the cause, there is a separate topic on that already.
  2. If the address starts with https:// then it gets more tricky - somehow your webserver instructs the browser to not send a referer header to openstreetmap, you should talk to this with your webspace provider/technician and point them e.g. here Access Blocked - Leaflet tiles. Just me? - #14 by Firefishy
1 Like
10

Lizmap is a web mapping solution where one can prepare geo data and styling in QGIS and then publish it as web map.

One of the public demos uses Carto tiles as background layer. It works for me and all tiles are displayed. The Referer header is sent.

So I think that it works with Lizmap in general, and there’s something special about @OSM_Geo34’s installation.

@OSM_Geo34, are you opening the app in a browser via https:// ? Or is it opened by some other means, e.g. from a file share?

In the browser, could you

  • press F12
  • go to the “Network” tab
  • pan the map until you see OSM tiles being requested in the network requests
  • click on one of the requests with the domain tile.openstreetmap.org
  • in the “Headers” section, in “Request Headers”, do you see Referer and User-Agent?
1 Like
11

Add referer header to requests sent to Qgis server (or other backend) · Issue #2521 · 3liz/lizmap-web-client · GitHub may or may not be about this situation

I do not see issue about this at GitHub · Where software is built

I guess that someone impacted by this may make a PR or report issue to them, if it happens without weird browser extensions etc.

12

After exchange about the issue with our web software developer, the problem was resolved by modifying the server configuration (in our case, Nginx) to change the Referrer-Policy (HTTP Referer) header from “no-referrer” to “strict-origin-when-cross-origin”.

Thank you all for your feedback.

4 Likes