-
Notifications
You must be signed in to change notification settings - Fork 157
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
"14/0/0" as expiretile even its not in the limitto area #298
Comments
I don't see 14/0/0 in the last 30 days. There are changes at 14/0/* and 14/16383/*, things crossing the dateline. |
But we have had it several times now: For example: |
14/0/0 is a valid tile to expire, so if the rest of your toolchain can't handle it, that's a bug. Without enough details to reproduce, it's not possible to say if 14/0/0 showing up in the expire list is an error or not. |
You´re right, sorry. But our WMS is not valid in this location, so this is the reason why the error appears in mapproxy. This is the BBOX of the limitto geometry [7.1 ,51.2 ,9.9 ,52.5]. Because it is limited to this extent, I assume that the 14/0/0 tile can not be laying in this extent, doesn´t it? |
Please always provide as much information as you can. That you are using -limitto, and that it only occurred in the last hours and not often is important information. I suggest that you try another smaller import with a -limitto and try to import the changesets from this night. Let me know if and how you can reproduce the issue. |
I have made a new data import and furthermore I have made a new imposm_cache directory to exclude the possibility of version incompatibilities. Despite it I have this 14/0/0 expire tiles again. This is our import command:
This is the import log:
This is our run command to keep the data up to date:
This is the imposm_config.json:
Do you need some more informations @olt? |
The error occurs permanently, every day. Yesterday with nearly 500 occurences. I exit the program at the end of the day, delete all occurrences of the string and restart the program in the morning. Were you able to reproduce the error @olt ? |
I haven't found a single 14/0/0 on our servers. It's on my list to check for any obvious errors in the tile expire lists in combination with limitto. But please note that I won't be able to do a full countrywide import to hunt down this issue. |
Ok, thanks. Notice, that the import isn´t countrywide, just Bielefeld and the surrounding area. Until then we will switch back to the older version. |
We switched back to an older version and now the error doesn´t occur anymore. |
I checked the implementation, and the generated expire tiles are not checked for -limitto. So it is correct that there are tiles outside of -limitto (from larger ways and relations). There was a bug where it created expire tiles for points outside of the valid Web Mercator boundaries. This is now fixed. It is still possible to see 14/0/0 tiles, as it is a valid tile. |
Thank you. I'll let you know when we've tested the new version. I'm aware that the 14/0/0 tile can appear. But in this frequency it was definitely wrong. |
With the newest version of Imposm (v0.14.0) we are facing an issue in the expire directory. The expire tile "14/0/0" is often created, which just can be a bug. Did anyone have an idea what can be the reason?
As a result, mapproxy becomes a problem caching a WMS because an incorrect BBOX is calculated from this tile.
The text was updated successfully, but these errors were encountered: