Response looks OK but the file wont render. https://b.tile.openstreetmap.org/12/2263/1404.png

asked 18 Nov, 09:52

marianskrisa's gravatar image

marianskrisa
112
accept rate: 0%

2

Looks fine here but as it is cache-dependent, can you post the output of https://tile.openstreetmap.org/cgi-bin/debug ?

(18 Nov, 10:06) Spiekerooger

For completeness https://37.17.173.8/12/2263/1404.png loads in Chrome (including incognito) for me as well and also FWIW Internet Explorer (!). It doesn't mean there isn't a problem with that tile though.

(19 Nov, 16:17) SomeoneElse ♦

tile.openstreetmap.org debug Server Stats Cache Server: sarkany.openstreetmap.org

Render Server: rhaegal.openstreetmap.org Load Average: 14.94

File Status simplified-land-polygons-complete-3857.zip last modified: Wed Nov 11 08:03:27 2020 simplified-water-polygons-split-3857.zip last modified: Wed Nov 11 08:03:46 2020 ne_110m_admin_0_boundary_lines_land.zip last modified: Sun Jul 22 18:07:58 2018 land-polygons-split-3857.zip last modified: Wed Nov 11 08:04:25 2020 water-polygons-split-3857.zip last modified: Wed Nov 11 08:05:31 2020 antarctica-icesheet-polygons-3857.zip last modified: Wed Nov 11 08:06:13 2020 antarctica-icesheet-outlines-3857.zip last modified: Wed Nov 11 08:06:19 2020 Browser Request Headers CONTEXT_DOCUMENT_ROOT: /srv/tile.openstreetmap.org/cgi-bin/ CONTEXT_PREFIX: /cgi-bin/ DOCUMENT_ROOT: /srv/tile.openstreetmap.org/html GATEWAY_INTERFACE: CGI/1.1 HTTPS: on HTTP_CACHE_CONTROL: max-age=1209600 HTTP_CONNECTION: keep-alive HTTP_HOST: tile.openstreetmap.org HTTP_SURROGATE_CAPABILITY: sarkany.openstreetmap.org="Surrogate/1.0 ESI/1.0" HTTP_USER_AGENT: NONE HTTP_VIA: 1.1 sarkany.openstreetmap.org (squid/4.11) HTTP_X_FORWARDED_FOR: 213.160.XXX.XXX, 127.0.0.1 LC_CTYPE: C.UTF-8 PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QUERY_STRING: REMOTE_ADDR: 37.17.173.8 REMOTE_PORT: 22236 REQUEST_METHOD: GET REQUEST_SCHEME: https REQUEST_URI: /cgi-bin/debug SCRIPT_FILENAME: /srv/tile.openstreetmap.org/cgi-bin/debug SCRIPT_NAME: /cgi-bin/debug SCRIPT_URI: https://tile.openstreetmap.org/cgi-bin/debug SCRIPT_URL: /cgi-bin/debug SERVER_ADDR: 10.5.0.77 SERVER_ADMIN: webmaster@openstreetmap.org SERVER_NAME: tile.openstreetmap.org SERVER_PORT: 443 SERVER_PROTOCOL: HTTP/1.1 SERVER_SIGNATURE:

Apache/2.4.41 (Ubuntu) Server at tile.openstreetmap.org Port 443

SERVER_SOFTWARE: Apache/2.4.41 (Ubuntu)

permanent link

answered 18 Nov, 13:44

marianskrisa's gravatar image

marianskrisa
112
accept rate: 0%

edited 18 Nov, 13:57

Spiekerooger's gravatar image

Spiekerooger
8911020

Confirmed that the tile is broken on sarkany. I tried to initiate a re-rendering/re-caching but as of now I'm unsure if the /dirty method still works (maybe someone else or SomeoneElse could confirm?). It does look as only this tile is affected, other tiles surrounding this one are not. Maybe related to an outage of the sarkany cache for about ~ 1 hour today at midnight?

(18 Nov, 14:04) Spiekerooger

Can you open https://www.openstreetmap.org/#map=12/49.1131/18.9420 and do a hard refresh? It should initiate a reload of the tile into the cache.

(18 Nov, 14:48) Spiekerooger

Ok I did, but I see no changes.

(18 Nov, 18:55) marianskrisa

alt text

This is the tile, what is broken?

permanent link

answered 19 Nov, 13:55

andy%20mackey's gravatar image

andy mackey
12.3k79132269
accept rate: 4%

2

That tile form sarkany won't display in (at least) firefox. FF says the png contains errors. So I can confirm what marianskrisa says and I've tried a hard refresh from www.openstreetmap.org, it won't help - as nginx/squid thinks there is a fine file. It does smell as if the png has some extra or mising bytes in there.

(19 Nov, 14:20) Spiekerooger
2

(for Andy Mackey's benefit) The actual location that tiles are loaded from depends where you are in the world. The person who asked this question is trying to load this tile from an address that translates to http://37.17.173.8/12/2263/1404.png - that gives an error. A next-door tile https://37.17.173.8/12/2263/1405.png works OK.

The thing that determines what tile server you get is your DNS, so in the UK I currently get 185.73.44.167, also known as london-02.tile.openstreetmap.org, when I try to load anything from b.tile.openstreetmap.org.

Separately to the PNG error with this tile trying to load, https://37.17.173.8/12/2263/1405.png will of course get a browser certificate warning, because the certificate on the web server is valid for "b.tile.openstreetmap.org" (among others) but not for the raw address 37.17.173.8.

(19 Nov, 14:52) SomeoneElse ♦

To test this further you can manipulate your local hosts file in setting 37.17.173.8 as the A record for tile.openstreetmap.org. If you then open https://www.openstreetmap.org/#map=12/49.1131/18.9420 in FF you'll see the problem as shown by marianskrisa below. And even a hard refresh won't work.

I know that one tile is not the world out of those billions of tiles in 55+ tile caches but it would be really nice to find a solution to solve this by other means than asking the SysOWG. Sth. magic without having to ssh into sarkany ;)

(19 Nov, 15:49) Spiekerooger

alt text

(20 Nov, 06:28) marianskrisa
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×255

question asked: 18 Nov, 09:52

question was seen: 143 times

last updated: 20 Nov, 09:35

powered by OSQA