Blank PNG files?

[Chris Fox]

Just working on converting my app to use the new API. 

Using PNG as the app uses Leaflet.

Using

https://api.tiles.openaip.net/api/data/airspaces/{z}/{x}/{y}.png?apiKey=xxxx

the requests are succeeding but the returned tiles are all a transparent square. For example

https://api.tiles.openaip.net/api/data/airspaces/8/125/171.png?apiKey=xxxxx

I know there is airspace in this location!

If I ask for the same 'tile' but in pbf format with

https://api.tiles.openaip.net/api/data/openaip/7/269/1733.pbf?apiKey=xxxx

I get what looks like a reasonable data set, but I can't display that in Leaflet.

What am I doing wrong?

[Chris Fox]

Sorted - I had previously had 'tms:true' in my Leaflet tileLayer initialisation. Not required any more!

[Antoine Megens]

Thanks for posting the solution, I had the exact same issue

Op donderdag 11 augustus 2022 om 18:43:32 UTC+2 schreef glidin...@gmail.com:

[Inno Sist]

I'm new in OpenAIP,  I have the same issue, but the posted solution not working for me.

That's my leaflet code, and like you, I receive a transparent square.

 L.tileLayer("https://api.tiles.openaip.net/api/data/airspaces/{z}/{x}/{y}.png?apiKey=${API_KEY}", {
                    maxZoom: 14,
                    minZoom: 4,
                    tms: true,
                    detectRetina: true,
                    format: 'image/png',
                    transparent: true,
                    opacity: 0.5
                });

Please, could someone help me?

Thanks 

[openaip net]

As stated above, you have to remove the "tms: true". Then it should work.

[Inno Sist]

Yes, Thanks!!!

[Lukas Lücking]

I have the same behavior. 

Just that I cannot leave "tms:true" out of my code, because I don't use that leavelet.

Does anyone has a clue what that removed "tms:true" actually does?

How should I modify the https request to get actual image data?

Are additional POST/GET parameters needed?
Are special HTTPS header parameter requiered?

Thank you very much.

Lukas

[openaip net]

Some map clients had problems with the TMS URIs, especially the z/x/y order. Two dimensions were "flipped" by default (cant remember which) which results in blank or not the expected tiles for the requested area. The "tms:true" config for leaflet was used to configure the client to treat the TMS URIs correctly. 

But it's very hard to help if we don't know the library you are using. Code example would be nice too.

Cheers,

Stephan 

[Lukas Lücking]

Thank you Stephan for your quick answer.

Now I see, that the responses are fine, just the requested z/x/y coordinates are another format than they were before in openaip tms server.

Thank you again, you helped me a lot.

[openaip net]

Glad to hear it's solved now :) 

[Claudio Silenzi]

I have the same problem, and even changing the TMS parameter, or changing the order of Z/X/Y, I always get a white tile of 116 bytes. This is my python code : 

url = 'https://api.tiles.openaip.net/api/data/openaip/7/269/733.png'
params = {'apiKey': 'MY_KEY', "tms": "true"}
headers = {'accept': 'application/binary', 'x-openaip-client-id': 'MY_KEY'}
response = requests.get(url, params=params, headers=headers)

I've also seen your API test has the same code in HTML and return a blank tile of 116 bytes. 

Thanks for any help

Claudio

[openaip net]

The TMS parameter is specifically used in leaflet (or maybe other web map clients) to tell the library how to handle the response of the TMS. From the code you posted, it seems that you are simply

requesting the raw tile from the server. If this is the case and if you get a 200 response and the tile is blank, i would assume that this is correct. Did you try another tile that:

https://a.api.tiles.openaip.net/api/data/openaip/8/150/105.png?apiKey=API_KEY_HEREip.net/api/data/openaip/8/150/105.png?apiKey=31a1d6eaa99a4f37a11a9c734dd744c0

 The TMS for PNG files is working fine. Just checked

[Claudio Silenzi]

Ok, yes with your example now it works. I've understood what was my issue. The zoom below 7 return an empty tile, so I must keep zoom>=7. I guess it is related to server overload? But something I noticed is that the resolution of the png is very low compared to the map shown in your site. Is there an option to have tiles with increased resolution? Or the only way to have high resolution images is converting the pbf?

Thanks 

Claudio

[openaip net]

Ah, yes. The zoom levels are restricted from 7 - 18 to reduce server load. I can look into possible ways to improve the image quality for the PNGs but I suppose they will never match the quality when using PBFs. The style is actually drawn on the client when using the PBFs on the openaip map which offers a lot more flexibility. like realtime filtering of items, styling etc. 

[Sbeuh]

Hello

Also having the same issue using leaflet without TMS. I though about a database rebuild issue but it is happening in all parts of the world. 

Trying to fetch directly the links to PNG images give the same results:

As example for these three tile: 

https://api.tiles.openaip.net/api/data/openaip/11/1043/751.png?apiKey={mykey} 

https://api.tiles.openaip.net/api/data/openaip/11/1044/751.png?apiKey={mykey} 

https://api.tiles.openaip.net/api/data/openaip/11/1045/751.png?apiKey={mykey} 

These three tiles are in a row and I'm just playing with the X parameter

The end map result looks like this:

The leaflet Tile layer code used is the following: 

L.tileLayer("https://{s}.api.tiles.openaip.net/api/data/openaip/{z}/{x}/{y}.png?apiKey={myrealapikey}", {attribution: "https://www.openaip.net", zoomOffset: 0, minZoom: 8, minNativeZoom: 8, maxNativeZoom: 16, maxZoom: 20});

I also tried to use the pbf files directly using Leadlet but I can't find the styling json which can be used to render the different elements. Do you have some or it is provided directly by mapbox on your side? 

Thanks a lot for your help.

Regards

Sébastien

[Lukas Lücking]

Hi everyone,

I have the same issue. Some tiles are just blank.

(OK)

https://api.tiles.openaip.net/api/data/openaip/12/2118/1358.png?apiKey={key}

(Error)

https://api.tiles.openaip.net/api/data/openaip/12/2118/1359.png?apiKey={key}

(OK)

https://api.tiles.openaip.net/api/data/openaip/12/2118/1360.png?apiKey={key}

And that leaves blank spaces all over the place...

This issue exists quiet some time now. Any Ideas what causes this issue?

Thanks a lot,

Lukas

[Sbeuh]

Never had an answer to this question. My guess is that maybe it is related to when they rebuild the image database as the issue disappeared and appeared again but not confirmed at all. 

[webmaster]

Hello everyone,

this problem may occur because of several reasons. I suppose that it is a combination of 

- tile cache rebuild

- tile cache invalidation

- browser cache invalidation

- errors (connection problem to database, general rendering error,...) when generating PNG tiles

- sync problem between main and spatial database

- scaling / connection issues

- database not responding fast enough

We run a completely custom tile service for both the TMS and MVT. Since our dataset receives a lot of updates, we have a fairly complex logic in place that handles the near-realtime sync between addition/updates to our main database and our spatial database including the re-generation of tiles for the specific area that received the change. This works very well for the MVT part since the generation and also the "on-the-fly" calculation of binary tiles does not take much power and is very fast. In contrast, re-building a PNG tile cache takes considerably more time and CPU power especially with the high zoom-levels that we have to support. The service scales its instances depending on the load and thus they are designed to be stateless. All instances share a pool of re-build tasks that are picked up by a single instances. Each task has a specific "try-X-times-then-discard" configuration. It looks like that in this case, several tile re-build tasks have been dropped due to a reoccurring problem during the rebuild task. What it was, not sure - most likely the database cluster cannot keep up with the amount of requests it receives. Unfortunately there is no easy fix to this. The easiest way (and the last resort) would be to handle it like most other services and rebuild the tile cache depending on a specific schedule. But this means that the PNG tiles will "lag" behind the current dataset depending on the rebuild interval and that this will introduce other problems that have to be solved, e.g. making sure that there are no inconsistencies that arise when a change happens during the rebuild process etc.

I'll have a look at it the next days and reset the cache or even maybe lower the cache expiration to have a better "self healing" of the PNG tile cache but I'm unsure of the outcome. Our focus is currently on the completely new webinterface which will be released shortly. After that, this will get high priority and I can take an in-depth look at it. 

Cheers,

Stephan

[Lukas Lücking]

Hi Stephan,

Thank you very much for the detailed explanation! I appreciate you taking the effort to fix this.

I hope you can find a solution that does not require too much work.

Lukas

[webmaster]

Hi group,

I took a closer look at this issue and I have yet to find an area where this happens with my "test rig" which is a simple leaflet client that queries our TMS tiles endpoint. Is anyone still experience this issue with "blank tiles"? If so, it would we be helpful to know the exact position where this happens and also the setup that is used to visualize the tiles i.e. client, browser caching settings and if there is a caching proxy involved on client side (that may server pre-requested tiles from openaip API etc.).

Cheers,

Stephan