queryTile requires lng/lat, while buildQuery requires lat/lng

[mapsam]

I'm looking at the buildQuery function portion that uses spherical mercator and noticing something funky... vector tile query requires lng/lat pairs, like [-116.2683, 46.2312]. When those coordinates are passed into vtquery.loadTiles(points) we use spherical mercator to grab the lowest zoom level tile using the sm.xyz function.

That function requires [w, s, e, n] coordinates as a bounding box, and they are entered as such (since there is a single point, the bounding box is just a point, but still works):

var xyz = sm.xyz([points[i][1], points[i][0], points[i][1], points[i][0]], zoom);

The above comes out as [lat, lng, lat, lng] when the coordinate pair [-116.2683, 46.2312] is passed into vtquery.loadTile(). The resulting ZXY tile changes depending on this order. Is this order correct or are lng/lat getting flipped when finding the ZXY?

cc @springmeyer @dnomadb

[mapsam]

Actually - I think I have it backwards - VTQuery takes lat/lng pairs, which would make this usage of spherical mercator correct. 😐

[mapsam]

That being said, when I look at the output of vtquery.queryTile() passing in a lat/lng pair - it comes back with incorrect key/value pairs:

[ { id: 1,
    latlng: { lat: -116.2683, lng: 46.2312 },
    State: null,
    Label: null } ]

[mapsam]

Okay, I've found my confusion. I'm noticing that the same exact set of coordinates [-116.2683, 46.2312] passed into queryTile and loadTiles don't return the same results. This is due to the flipping of coordinate pairs here when the loadTiles function calls queryTile for each tile found.

Since we expose queryTile and reference the order of coordinates in the README, it seems like this should be updated to ensure coordinate pairs are always in the same order when used in arrays.

Next actions

• [ ] Update the queryTile to assume incoming coordinate pairs are actually lat/lng, not lng/lat.