GeoTIFF GeoTransform not applied when image is displayed on map

[philvarner]

EDIT: see #222 (comment) for an accurate description of this issue.

When viewing an Item with these assets:

  "data_cog": {
          "roles": [
            "data"
          ],
          "href": "https://.....",
          "type": "image/tiff; application=geotiff; profile=cloud-optimized",
          "title": "Data - COG"
    },
        "data_legacy_geotiff": {
          "roles": [
            "data"
          ],
          "href": "https://.....",
          "type": "image/tiff; application=geotiff",
          "title": "Data - Legacy GeoTIFF"
        },

the "Show on Map" button appears for the asset with type image/tiff; application=geotiff but not for the asset with image/tiff; application=geotiff; profile=cloud-optimized. The COG asset has "shown" label on it, but it doesn't appear on the map.

Setting useTileLayerAsFallback to false does cause the COG to display. My guess is there's a logic issue somewhere that the code thinks a non-COG geotiff media type can display in the browser, but a COG geotiff media type can't.

I was looking in Asset.vue#canShow and index.js

tileRendererType: state => {
        if ((state.tileSourceTemplate || state.buildTileUrlTemplate) && !state.useTileLayerAsFallback) {
          return 'server';
        }
        else {
          return 'client';
        }
      },

to figure out how to get the tileRendererType set to server so it would use my tiler. useTileLayerAsFallback seems like it has the opposite effect here that the name implies.

[m-mohr]

Sounds more like an issue in stac-layer, I'll need to investigate. Are there any issues shown in the web browser dev console?

[philvarner]

I didn't see any errors -- it seemed to me like it was working as coded, it was just an issue with the logic that didn't make sense to me.

[m-mohr]

I was wondering why the COG doesn't show up and sometimes they don't show up due to errors such as CORS or "invalid" COGs. But what are you actually trying to do? Do you want to use client-side COG rendering, client-side COG with tiler fallback or enforce the tiler? Could you copy the config so that I can try to reproduce it? Thanks.

[philvarner]

I have CORS turned off b/c I'm running stac-browser locally against a remote stac api.

I set useTileLayerAsFallback back to true, and ran it again. A single request goes out to the url to read 65kb, which I assume is to retrieve the headers, and gets a successful 206 response, but no other requests are made to load the image. Maybe there's something about the header that makes it think it's not a cog?

When I set useTileLayerAsFallback=false, and load it again, the cog is displayed from the titler endpoint. No request goes for the asset href directly.

The cog-relevant part of the metadata is:

Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
  LAYOUT=COG
Band 1 Block=256x256 Type=Byte, ColorInterp=Gray
  Overviews: 4490x5754, 2245x2877, 1123x1439, 562x720, 281x360, 141x180

maybe LZW compression isn't supported? The "legacy" geotiff that does work is uncompressed:

Image Structure Metadata:
  INTERLEAVE=BAND
Band 1 Block=17958x1 Type=Byte, ColorInterp=Gray

[m-mohr]

So the behavior itself that you mention above sounds correct. To me it sounds like for whatever reason the COG can't be read, but LZW can't be the issue as geotiff.js supports it. What's the CRS? It will be hard to debug this without a repro as in general with a COG and GeoTiff asset it works for me and there are so many different details with the COG reader that can go wrong. Can you provide the file? Could be via e-mail if you don't want to post it publicly. Otherwise, I can't really help in this case.

Just to verify, can you load the COG into http://app.geotiff.io/ ? It uses a similar internal software stack so if it works there it's likely a bug on my side that I can work on, but if it also doesn't load there, it's likely an upstream issue which we can't easily solve.

[DanielJDufour]

Hey, I would actually recommend testing trying to load the tiff with https://geotiff.github.io/georaster-layer-for-leaflet-example/examples/load-file.html instead of geotiff.io

The example is guaranteed to be using the newest version of georaster-layer-for-leaflet

[philvarner]

both the legacy and cog loaded with that page.

I'll create a repro case for it.

[philvarner]

I think the issue is that the both the cog and the legacy geotiff have a GeoTransform.

I just noticed that the image does display, it's just in the wrong place. I just didn't notice it because it is much smaller and wasn't in the footprint boundary. It looks like this, where the red is the image and the grey is the footprint:

I tried this with another image in the same stac api that doesn't have GeoTransform and it displays correctly.

I think what is happening is that when the Item page is loaded, the Item geometry is displayed as the footprint. When you explicitly click on any of the assets, the Item geometry is removed and replaced with the asset raster and calculated footprint. When I explicitly add either tif to the map, they don't have the geotransform applied, so they're aligned horizontally and vertically instead of being rotated and scaled as the geotransform defines. The https://geotiff.github.io/ link you sent above has this same behavior of not rotating and scaling.

Sorry I can't allocate any more time to this, but it should be straightforward to reproduce now with a tiff that has a geotransform.

[DanielJDufour]

thanks for the info. yes, you are correct. georaster-layer-for-leaflet simply doesn't support displaying GeoTIFFs with a geotransform/rotation. I would definitely like to add that capability someday, but it is unlikely to happen absent funding. It would involve updating a whole ecosystem of related packages to support geotransforms/rotations.

however, we should make this limitation more clear. I'll explore adding an error message to stac-layer that says "[stac-layer] geotiff with geotransform not supported" (or something to that effect)

[m-mohr]

Thanks for the investigation. Wouldn't that also be a case where we should fallback to the tileserver, if configured?

[DanielJDufour]

@m-mohr , great point. yes, that sounds like the right way to go

[philvarner]

one more follow up question -- I still don't understand exactly what useTileLayerAsFallback is supposed to mean. The behavior I see is that when it's true it tries to load the geotiff directly with georaster-layer-for-leaflet and false it uses the tiler via buildTileUrlTemplate. I had assumed the "TileLayer" referred the tiler, but it seems to refer to a detail about using the geotiff directly, since setting it to false stops that behavior? I don't know if the name needs to be changed, or it just needs explanation in the documentation.

[m-mohr]

This is how I think it is expected to work:

useTileLayerAsFallback	tileSourceTemplate / buildTileUrlTemplate	primary renderer	fallback renderer
true	one of them configured	client-side	tile-server
false	one of them configured	tile-server	none
true	none configured	client-side	none
false	none configured	none	none

The naming is not intuitive, I agree. STAC Browser just passes these options through though, ideally this would be improved upstream in stac-layer.

[philvarner]

that looks right. I see that it is documented (I was looking at master instead of dev), but even reading what's there now that I know what the behavior is, I think it's unclear. This table would help a lot.

[m-mohr]

I've updated the documentation, I hope it helps.

[philvarner]

Just wanted to say that I've been using stac-browser more over the last week, and it's working great.

[m-mohr]

I'm closing this as this is now a purely upstream issue.