Loading /entry/3383 triggers three calls to /types/counts, the first of which is invalid:
bounds: -89.75843286519019,-171.90066760000002|89.94774187417445,-4.55691760000002 (invalid because latitudes are not in the interval [-85.0511, 85.0511], the limit for Web Mercator projection)
zoom: 2
bounds: -48.34087279647403,160.85323864999998|80.58991714826183,22.68917614999998 (valid but much larger than the final map bounds)
zoom: 4
bounds: 40.03132590294035,-105.27672979110717|40.049872835813034,-105.24965020889282 (bounds of final map)
zoom: 17
Loading /map triggers two calls to /types/counts, the first of which is invalid:
bounds: -89.75843286519019,-171.90066760000002|89.94774187417445,-4.55691760000002 (invalid, exact same as above)
zoom: 2
bounds: -48.34087279647403,160.85323864999998|80.58991714826183,22.68917614999998 (bounds of final map)
zoom: 4
When loading URLs with explicit map center and zoom (e.g. @40.04059999999998,-105.26319,16z), both problems go away: the API endpoint is only called once, and with the correct bounds.
That this issue only applies to the API calls to /types/counts – and not to e.g. /clusters or /locations – could be a clue. Somehow this API endpoint is called earlier than the others, and ends up using map bounds that are initialized to an invalid and premature value, which results in invalid data, which forces it to run again?
ezwelty
commented
1 month ago
Loading
/entry/3383triggers three calls to/types/counts, the first of which is invalid:bounds: -89.75843286519019,-171.90066760000002|89.94774187417445,-4.55691760000002 (invalid because latitudes are not in the interval [-85.0511, 85.0511], the limit for Web Mercator projection)zoom: 2bounds: -48.34087279647403,160.85323864999998|80.58991714826183,22.68917614999998 (valid but much larger than the final map bounds)zoom: 4bounds: 40.03132590294035,-105.27672979110717|40.049872835813034,-105.24965020889282 (bounds of final map)zoom: 17Loading
/maptriggers two calls to/types/counts, the first of which is invalid:bounds: -89.75843286519019,-171.90066760000002|89.94774187417445,-4.55691760000002 (invalid, exact same as above)zoom: 2bounds: -48.34087279647403,160.85323864999998|80.58991714826183,22.68917614999998 (bounds of final map)zoom: 4When loading URLs with explicit map center and zoom (e.g.
@40.04059999999998,-105.26319,16z), both problems go away: the API endpoint is only called once, and with the correct bounds.That this issue only applies to the API calls to
/types/counts– and not to e.g./clustersor/locations– could be a clue. Somehow this API endpoint is called earlier than the others, and ends up using map bounds that are initialized to an invalid and premature value, which results in invalid data, which forces it to run again?