Item thumbnails are not correctly anchored on STAC Explorer preview maps

[j08lue]

The new item thumbnails are amazing for getting a visual impression of the data in a client application like STAC Explorer!

Unfortunately, for many collections in our VEDA Earthdata catalog which are on global lat/lon grids (e.g. fldas-soil-moisture-anomalies), they do not mount well on the preview map in STAC Browser:

https://staging.openveda.cloud/stac/collections/fldas-soil-moisture-anomalies/items/FLDAS_NOAH01_SoilMoi00_10cm_tavg_C_GL_MA_ANOM202307_20230701?.language=en&.asset=asset-rendered_preview

I guess the thumbnail is not reprojected and just a dump of the native grid (equirectangular, i.e. regular lat/lon), while the little preview map is using Web Mercator. Preview thumbnails in native map projection are more informative than reprojected ones, I'd say, but it just does not look good...

Btw, Planetary Computer STAC / STAC Browser has the same issue with preview thumbnails for global gridded datasets, e.g. https://radiantearth.github.io/stac-browser/#/external/planetarycomputer.microsoft.com/api/stac/v1/collections/noaa-cdr-ocean-heat-content/items/ocean-heat-content-2020-Q2-2000m?.asset=asset-rendered_preview

Can we fix this somehow, so the preview images show nicely on the STAC Browser map - or we disable this map, because it will be wrong for most datasets? (btw, no is also an acceptable answer...)

Acceptance criteria

• STAC Browser does not show a wrong map representation of the preview thumbnails

[anayeaye]

I wonder if setting dst_crs in the renders params would address this?

[j08lue]

Nice, yes, the preview does get reprojected with dst_crs=epsg:3857. Not sure the bounding box is well preserved, though?

https://staging.openveda.cloud/api/raster/collections/fldas-soil-moisture-anomalies/items/FLDAS_NOAH01_SoilMoi00_10cm_tavg_C_GL_MA_ANOM202307_20230701/preview.png?bidx=1&assets=cog_default&rescale=-0.3%2C0.3&colormap_name=rdbu&dst_crs=epsg:3857

This one in particular gets weirdly expanded towards the north.

[anayeaye]

@j08lue that is looooooong. 4326? https://staging.openveda.cloud/api/raster/collections/fldas-soil-moisture-anomalies/items/FLDAS_NOAH01_SoilMoi00_10cm_tavg_C_GL_MA_ANOM202307_20230701/preview.png?bidx=1&assets=cog_default&rescale=-0.3%2C0.3&colormap_name=rdbu&dst_crs=epsg:4326

[j08lue]

4326 is where we are coming from (native projection). We do need 3857 for the Web Mercator map in STAC Browser, I guess...

[anayeaye]

🤔 I tried putting the dst_crs epsg:3857 in the collection renders config just to see if the browser handled it any better. Nope

[j08lue]

Yes, all the Leaflet map does is take the PNG and place it within the given bbox (from STAC). So the long PNG gets used as-is.

[vincentsarago]

👀

I'm pretty sure the preview should be in EPSG:4326, the issue then is to know which bbox (in epsg4326) correspond to image returned by the service

[j08lue]

Which bbox does STAC Browser use to mount the image on the map?

https://github.com/radiantearth/stac-browser/blob/37064de0d5eaf9538c27e50239f6b7507e47140f/src/components/Map.vue#L291-L297

Looks like stac.extent.spatial.bbox[0] for collections and stac.bbox for items.

And why do image and that bbox not match?

?

[smohiudd]

Can we manually deploy a pre-release version of stac browser that is using a different mapping framework other than leaflet?

radiantearth/stac-browser#535

[j08lue]

We are currently working through a similar problem for the UK EO Data Hub Resource Catalogue - we want to mount thumbnails (of products that cannot be rendered otherwise) on a map, so users looking for suitable items can get a good preview of them.

Some collections had item thumbnails that are in native image projection. We chose a hack to derive a rotated and skewed (trapezoid) bounding box from the item geometry. But it is not clean.

It would be great if STAC had a spec for how to provide thumbnails and anchor points. Obviously, if the only anchor points are the lat/lon bbox, the image needs to be non-rotated in geographic projection.

If thumbnails can have arbitrary projections, e.g. the native image projection, we need more information in STAC.

For example, MapLibre can mount rotated images, but requires four image corner coordinates to mount a non-georeferenced ImageSource to the map.

cc @kamicut

[j08lue]

Why do we expect better display of thumbnails from the OpenLayers map in the upcoming STAC Browser version, @smohiudd?

[smohiudd]

@j08lue we don't know for sure but will try anything at this point! It may not work.

If thumbnails can have arbitrary projections, e.g. the native image projection, we need more information in STAC.

What other information do we need or can be derived from stac meta data to help with this?

[j08lue]

A possible solution would be to create georeferenced thumbnails. Probably as small RGB GeoTIFFs.

OpenLayers should be able to load a GeoTIFF thumbnail using GeoTIFFSource, not sure STAC Browser OL already has that logic included - should be easy, based on the mime type of the thumbnail.

Can TiTiler return previews as GeoTIFF instead of PNG or JPEG? If not, that should be an easy addition.

[j08lue]

But thumbnails are also used in all kinds of contexts, not just maps, so maybe we should stick to PNGs.

Then, we should make sure the thumbnails fit he bbox that is stored in STAC. TiTiler's /preview may be inferring the bbox differently from what we have stored in STAC.

We could use TiTiler's /bbox endpoint instead to be sure thumbnail and bbox always match.