What to do about rounding errors in TileSystem? RRS feed

  • Question

  • Hi,

    I've been bitten by rounding problems when using the TileSystem class from the Bing Maps Tile System documentation. The problem can be seen in the below unit test:

    public void REPRO()
        var latitude = 41;
        var longitude = 116;
        var firstLevel = 4;
        var secondLevel = 5;
        TileSystem.LatLongToPixelXY(latitude, longitude, firstLevel, out var pixelX1, out var pixelY1);
        TileSystem.LatLongToPixelXY(latitude, longitude, secondLevel, out var pixelX2, out var pixelY2);
        TileSystem.PixelXYToTileXY(pixelX1, pixelY1, out var tileX1, out var tileY1);
        TileSystem.PixelXYToTileXY(pixelX2, pixelY2, out var tileX2, out var tileY2);
        var firstQuadKey = TileSystem.TileXYToQuadKey(tileX1, tileY1, firstLevel);
        var secondQuadKey = TileSystem.TileXYToQuadKey(tileX2, tileY2, secondLevel);
        Assert.StartsWith(secondQuadKey, firstQuadKey);

    As you can see, I'm resolving the quad key for the same lat/lon, but at different map levels. My expectation was that the more detailed quad key would be within the less detailed quad key. That is, the more detailed quad key would start with the less detailed quad key. Mostly, this expectation holds true, but in very specific scenarios such as the one above, it does not.

    My question is this: what do people generally do about this? My gut reaction was to resolve lat/lons to quads using the maximum detail level, then truncate the result to the level of detail I actually require. Is this the best approach?


    Tuesday, February 12, 2019 5:28 AM

All replies

  • Hi Kent,

    You have it reversed,  the more zoomed in, the longer the key.  The less zoomed in the shorter the key.

    1.  Here is a great article on accessing the tiles in code

    2. At the bottom of the article there are two links that will help you understand what happens when you truncate.



    Tuesday, February 12, 2019 6:03 PM
  • Without debugging the code, it does seem like you're hitting float instability. If you pick a lat/long that's right on a tile boundary, it technically is contained in either tile, so either tile is a valid response. I think your suggested workaround is reasonable - if you need to ensure that one tile is a parent of the other, picking the highest detail tile and then walking up to the parent would always give consistent results.
    Thursday, February 14, 2019 5:43 PM