Open kueda opened 3 years ago
This seems like a pretty good API for this feature. Indeed this would need to be an asynchronous call because the data for raster tiles can only be accessed on our GL thread, not the UI thread. Other considerations:
Integer or floating-point color values? Floating-point channel values in the range [0, 1] would let the caller ignore differences like 8-bit vs 16-bit channels, which is nice. Integer channel values would make it simpler to handle values encoded in multiple channels (like Terrarium elevation), but 32-bit floats have enough precision that conversion should never impose practical limitations. Floating-point seems better.
Screen position or LatLng queries? The answer to which is more convenient for an application probably depends on the use case, but screen position queries are an easy need to imagine. More importantly though: raster data is (generally) only loaded for areas that are visible on screen. Therefore it makes more sense to me to base this query on screen position.
What happens when the query fails? There are multiple ways this could happen:
What happens when the query position is invalid? If the map view is tilted or close to the North or South pole, it's possible to pick a screen position that doesn't correspond to any tile. In this case we can return immediately and send an error value like null
.
What happens when the data is missing? The raster data for a position may not be present if 1) the view is still loading tiles, 2) the position is outside the visible area, or 3) the data could not be loaded due to an error. For the case of 1) we could wait to complete the query until the relevant tiles are loaded, but waiting won't resolve cases 2) or 3). The thing that would be simplest for Tangram to do (and most consistent with the other pick functions) is to immediately complete the query with an error value.
@bcamper I think you were interested in this feature too!
FWIW, all your preferred answers to the questions you posed sound good to me.
Feature request: raster layers include data that could have uses beyond cartography, e.g. the elevation included in a DEM layer, so it would be useful if the application could ask the map for the pixel value at a particular coordinate, perhaps analogous to how
pickFeature
andFeaturePickListener
work in the Android API, though given the potential for multiple overlaid raster layers, it might be useful to specify an optional layer as well, likeand
where
values
is the list of channel values for that pixel, presumably[red,green,blue,alpha]
for an RGBA raster or just[value]
for a single-channel TIF like a DEM. I'm specifically interested in extracting elevation from Mapzen Terrarium tiles to display to the user of a map app, though deriving slope and/or aspect from a normals tile would also be cool.