Polar Anti-Meridian Dropping Tiles and COGs

[tariqksoliman]

Hi and I've been struggling to get titiler-pgstac (v1.8.0) to properly mosaic tiles at the north pole.

I am using a self-made TileMatrixSet definition for EPSG:3413 and, given everything, I am reasonably confident that this is correct.

This first image visually explains my original issue:

• Dateline is up and the to left with north pole near bottom right.
• (Also ignore the basemap and its alignment -- that's something separate)

---

To address it, the first thing I tried was using MultiPolygon geometries for any COGs that crossed the dateline in the STAC metadata I was bulk uploading. This worked well:

---

However, it still seems like some COGs near the dateline are getting dropped. You can see this a bit in the above image too, but zooming around and it's more pronounced:

---

I also still notice that if I use the map.html directly, I still see missing tiles along the dateline (scaled my browser way out to see it):
http://localhost:8888/titilerpgstac/collections/FrozonSentinel/EarthSeaIceNorthPolarOgraphic/map.html?assets=asset&resampling=nearest&exitwhenfull=false&skipcovered=false&rescale=[0,1024]&colormap_name=bone&items_limit=100000&scan_limit=100000000&time_limit=12

Actually, this is probably a different problem with how map.html handles projections -- it does not even attempt to query those tiles (they are not 204 no content's like in the first image)

---

FWIW, the collection does mosaic properly in WebMercatorQuad:

Any help would be much appreciated. Thanks! The third image is where I am stuck on.

[vincentsarago]

Hi @tariqksoliman

This is super interesting and sadly it's supper hard to debug without accessing neither the COGs and the TMS

FYI we know rio-tiler kinda struggle with dateline crossing dataset cogeotiff/rio-tiler#702

also in https://github.com/cogeotiff/rio-tiler/blob/5a9381d297f119f776cb5ad919f01d6cca034af7/rio_tiler/io/base.py#L196-L204 I don't think we are correctly handling the dateline

Could you share at least one COG and the TMS document you're using?

[tariqksoliman]

Hi @vincentsarago

• Here's the TileMatrixSet definition that I am using: https://github.com/NASA-AMMOS/MMGIS/blob/development/adjacent-servers/resources/tilematrixsets/planetcantile_v4/EarthSeaIceNorthPolarOgraphic.json
• This is the helper script I am using to get the COG metadata and upload it to STAC: https://github.com/NASA-AMMOS/MMGIS/blob/development/auxiliary/stac/create-stac-items/create-stac-items.py
  • Note it is a bit MMGIS specific. The antimeridian and bbox parts are what I believe to be relevant for this example.
• As for the data, could you email me at Tariq.K.Soliman@jpl.nasa.gov with your email and then I can send you a link to download the data. I already have approval to share it (it's derived from public Sentinel1 data, not unlike https://browser.stac.dataspace.copernicus.eu/collections/sentinel-1-grd) but it's probably more convenient to just share the COGs I'm already working with.

Further Investigation:

I've also been investigating this a bit more. I'm more and more suspecting it has to do with the bounding box generation and intersection calculations.

• Green: Original bbox calculated by rio_stac.create_stac_item -- which is wrong.
• Red: Is the multipolygon geometry that I am making for the antimeridian crossing COGs (see create-stac-items.py above).
• Orange: This is actually a bbox. I miscalculated the bbox here but it is what works best -- not right. create-stac-items.py above still includes this wrong bbox calculation.
• Yellow: My most recent attempt at a proper bbox. Unfortunately, while it feels right and looks right on its own, as you can see from the tiles loaded in the background, it messes things up again.

(bbox footprints in iamge above are for S1A_EW_GRDM_1SDH_20241212T191117_20241212T191217_056963_06FF6F_46E8_hh_reproj-cog.tif)

Random other images of me playing with the stac item bounding boxes:

Thanks!