-
-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
With mvt_postgis data provider tegola returns mvt file with size 0 byte if the tile have no data #788
Comments
A zero byte file where there's no data is correct. |
The problem is that nginx returns 404 if file 0 bytes and this files can't be cached also. Can you add parameter that make tegola |
Can you expand on this? Are you saying that PostGIS is returning a non 0-byte tile, but tegola is returning a 0-byte tile? |
For example, we have tile which have no data. With postgis data provider (I mean type = postgis in tegola config in [[providers]] section) tegola returns mvt file which will contains all layers names from tegola config even if layers have no objects. You can see something like this inside of mvt file for empty tile: |
@F-15023 Ah yes, I'm thinking that's potentially a bug in tegola as it should probably be returning 0 byte tiles if no data exists. I need to look into this a bit. Can you share any of your nginx config? I'm surprised that it's returning a 404 even though tegola is not. I could maybe understand a 204 No Content, but I'm surprised that changing the status code to 404 on a 0-byte body would be the default behavior. |
Hello, I have encountered with a problem.
If the tile have no data inside of its BBOX tegola with postgis data provider will returns mvt file wich will contains names of layers at least. But with new mvt_postgis data provider tegola will returns empty file with 0 byte size. And the problem is, the caching server can't use this file (because of its size, I think) and returns 404. Is it possible to make this type of files not totally empty and remain names of layers for example?
The text was updated successfully, but these errors were encountered: