How does FeaturesAt Work?

[hallahan]

I'm interested in adding the ability to highlight and select features in mapbox-gl-js, I'm also interested in fully understanding what is going on so I can reimplement this in native.

I spent some time studying the code, and I made a Gist walking through what is happening. I have 4 questions that I'm hoping someone who has dug into the weeds here can answer:

Question 1

What exactly is transform.pointCoordinate doing?

Question 2

Could you explain how TilePyramid works, paricularly tileAt? My assumption of the word pyramid is that this is where we keep track of tiles loaded, and the QuadTree of tiles in the Google Z/X/Y tile schema can be thought of as a pyramid.

Question 3

One obvious use case of a featuresAt would be to select and highlight a given map feature and provide the user with contextual information. Now that we have the desired vector tile feature, how do we extend this to tell the renderer to actually style this specific feature differently to the user?

Question 4

I like like that we are getting GeoJSON of the vector tile features, however, isn't this going to be simplified, non-original vector data? How would this be useful?

I'd appreciate any insight from anyone, thank you!

[tmcw]

What exactly is transform.pointCoordinate doing?

pointCoordinate converts a point (a screen pixel location relative to the top-left corner of the map viewport) into a coordinate - a row, tile, zoom level combination that uniquely identifies a tile.

Could you explain how TilePyramid works, paricularly tileAt?

Exactly how you describe, though the tricky part is

• z/x/y coordinates are represented as compact integer-packed ids
• there's no 'zoom level nesting', it's just a big object with keys

Your positionAt question is legit: I don't know why we're looking through all tiles and calling positionAt on all of them, rather than deriving the specific tiles that will return a valid positionAt value. A question for @kkaefer or @ansis maybe.

how do we extend this to tell the renderer to actually style this specific feature differently to the user?

Right now we're using featuresAt mostly for tooltips but the styling of individual features is over at #200

I like like that we are getting GeoJSON of the vector tile features, however, isn't this going to be simplified, non-original vector data? How would this be useful?

Yep, it's going to be simplified. It'll be useful if it's not simplified too much, so one can do basic GeoJSON-like things on it, like calculating rough areas or popping it out into a separate layer. Pushing the 'original data' - and in a lot of cases the original data is much unlike GeoJSON, like OSM XML or complex PostGIS geoms - isn't a priority of gl-js because the challenge of doing vector maps w/ speed is exactly that simplification process.

[ansis]

I don't know why we're looking through all tiles and calling positionAt on all of them, rather than deriving the specific tiles that will return a valid positionAt value. A question for @kkaefer or @ansis maybe.

I'm not sure why it's written the way it is but I don't think it matters. I don't think there are enough tiles loaded at once for this to be a performance concern. And if it was implemented the other way it would also need to check if the child/parent tiles of the tile at that point are present.