Issue with sample tile system code

[hvanbakel]

I use the tile system class as documented here

This has been working well for years. However recently a bug was reported which boiled down to a lat lng of length x would generate a different key then asking for a key of length x+1.
This violates the rule that removing characters at the end gets you a key to a bigger tile that enconmpasses the smaller one.

I've added a sample test case that fails given the code that's on the page right now.

break the tiles.txt

[timlms]

This is a result of rounding when converting a lat/long pair (double) to a pixel X,Y (integer), which is in the PixelX/Y equations.
This is intended to center the pixel on the integer value, such that a pixel with x=1 would include all longitude values that fall between 0.5 and 1.5.
In some edge cases, a pixel can get rounded into one tile at one level of detail, but into a different tile at another LOD - it is just how the map gets pixelated at a given level of detail.
In your example, your longitude is -117.78443
At LOD 16, this gives an exact value of 2899455.71236978. This gets rounded up to 2899456, which determines the tile and quadkey.
However, at LOD 17, this gives an exact value of 5798911.42473956, which gets rounded down, effectively pushing the pixel left, into the 02301320201131013 quadkey.
If it is important to your algorithm that the pixel always be in the same parent quadkey then you can truncate the double value and that should always keep the pixels together.

[hvanbakel]

Thank you for looking into this.

Your last sentence has me a little confused though

If it is important to your algorithm that the pixel always be in the same parent quadkey then you can truncate the double value and that should always keep the pixels together.

Isn't that the exact purpose of what this algorithm is trying to achieve? What's the rationale for not doing that in the sample code?