-
Notifications
You must be signed in to change notification settings - Fork 25
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
NZTM2000 TMS fails test if BBox is removed #103
Comments
It's funny because I've spend some time couple weeks ago trying to figure how the NZTM2000was made and was intrigued by the bbox too. I guess the best will be to ask directly LINZ people in their repo. |
Note:
Its value is somehow |
Good to know that you've seen something weird too! I will make an issue with the LINZ people and see what they say. |
☝️ changed my mind, I think we should modify https://github.com/developmentseed/morecantile/blob/main/morecantile/models.py#L656-L699 and get the |
Hi Vincent! Thank you for this, I think it's the right call. I'll take it and try and round out 4.0 release next week. |
I wonder if another option here is just to drop this tile matrix? I am unsure how many (if anyone?) actually uses it outside of LINZ, Who have deprecated it for internal use cases. Another fun example for boundingBox math, is the first matrix bounding box does not have to be the same as the second with https://github.com/developmentseed/morecantile/blob/main/morecantile/data/LINZAntarticaMapTilegrid.json#L8 the first two Z's are both 1x1 grids but z1 has a much smaller bounding box. However it is somewhere in our backlog to move this tile grid into a I haven't seen any examples of this in reverse, but there is nothing stopping anyone from making a tileMatrix where z0 is much smaller of a boundingBox than z1 (or even a random z). |
Fine by me as well 🙏 |
Cool! I'll action this |
If you remove the "boundingBox" section from the
NZTM2000.json
TMS definition, the following test failsThis is important because the boundingBox should be able to be calculated without an explicit definition. In TMS 2.0, the boundingBox property is optional, so we can't rely upon the explicit definition.
Steps to reproduce:
Is there something basic about TMS definitions that I'm missing? And is this an issue better suited for the definition repo at LINZ? Thanks!
The text was updated successfully, but these errors were encountered: