define image order

[andrewharvey]

The graphic indicates that newer images should be places earlier in the tiles array, with older images placed later in the tiles array, but this is never specified in the spec.

If downstream applications make assumptions about what the order of the files in the array represents, we should document that in the spec.

[vincentsarago]

👍 we should add a note about the file order.

[andrewharvey]

Is that going to be 0.0.3, or is it okay to update this in 0.0.2?

[vincentsarago]

@andrewharvey the more I think about it the more I think it's an implementation matter. We can maybe just tell this in here.

For example a mosaic tiler could parse the filename and check for dates to sort the files.

[andrewharvey]

While it could just be an understanding between tools that implement the spec, if it's not in the spec then you end with these informal agreements between tools which become informal specs which aren't documented, it gets messy.

I think if this feature is common and used by implementations, it should be formalised in the spec.

I've been thinking about possible solutions to storing capture dates in the metadata somehow, GeoTIFF has https://www.awaresystems.be/imaging/tiff/tifftags/datetime.html but it's unclear if that date should be when the file was created/processed or the acquisition date of the raster as capture by the sensor.

[vincentsarago]

To be honest I'm not sure what to say. can we just say:

    // REQUIRED. A dictionary of per quadkey dataset in form of {quadkeys: [datasets]} pairs.
    // Keys MUST be valid quadkeys index with zoom level equal to mosaic `minzoom` (or `quadkey_zoom` if present).
    // Values MUST be arrays of strings (url or sceneid) pointing to a 
    // Cloud Optimized dataset with bounds intersecting with the quadkey bounds. 
--> // Implementations MAY decide to treat the order of the list as it is or change it.
    "tiles": {
        "030130": [
            "s3://my-bucket/dir/file1.tif",
            "s3://my-bucket/dir/file2.tif",
        ]
    }

I've been thinking about possible solutions to storing capture dates in the metadata somehow, GeoTIFF has https://www.awaresystems.be/imaging/tiff/tifftags/datetime.html but it's unclear if that date should be when the file was created/processed or the acquisition date of the raster as capture by the sensor.

Well the problem is with that you endup needing to read each file.

[vincentsarago]

Note about the order, in https://github.com/developmentseed/awspds-mosaic the order is determined by the sat-api query which can be ordered by cloud cover.

[andrewharvey]

How about this?

By default the scenes will be drawn in the order of the array, with the first element drawn at the bottom.

The order is quite often changed as you indicated, but should be specify a default order?

The downside to this is by putting it in the spec your forcing that behaviour, and as you indicated sometimes the application may decide it's own order using some other logic.

Okay, maybe it's not a good idea to put this in the spec 🤷‍♂️

Well the problem is with that you endup needing to read each file.

But the mosaicjson spec doesn't allow one to add any metadata like the capture date. For comparison VRT does support free-form metadata so one could add capture dates in VRT.

[vincentsarago]

To be honest for now the spec says the list should be a list of string but if someone wants it could be something like

    "tiles": {
        "030130": [
            {"date": 2019-01-01, "cloud": 0.5, "s3://my-bucket/dir/file1.tif"}
            {"date": 2019-01-11, "cloud": 0.5, "s3://my-bucket/dir/file2.tif"}
        ]
    }

(as long as their mosaic tiler understand it)

The whole list is more implementation specific again in awspds-mosaic we use Landsat scene id instead of Cloud Optimized full path.
Going back to the list order, I think we can just say that rendering order is let to the implementation