Deduce collection temporal extent from items

[kylebarron]

In general, the temporal extent at the collection level for ongoing data sources has a start datetime but not an end datetime. For example, the Sentinel 2 L2A collection STAC has

"temporal": {
    "interval": [
        [
            "2015-06-27T10:25:31.456000Z",
            null
        ]
    ]
}

However when the underlying items are known, it's possible to put a bounds on both ends, which can be useful in situations like Landsat where there may be a two-week lag before the newest scenes are available in the bucket. In that case it would be helpful to know when the most recent Item that's available in a bucket is. It's my guess that since there's an index on the datetime field in Postgres, a max(datetime) query should be very fast?

Would you be interested in a PR to optionally deduce the collection interval on the fly from the underlying items?

[duckontheweb]

@kylebarron I think there is some interest in this as an optional capability. Are you still interested in putting in a PR for this?

@m-mohr Does using the temporal extent in this way seem reasonable to you?

[m-mohr]

Sure, this was actually the expected behavior in the spec before we relaxed this a bit to make implementations eaiser.

[m-mohr]

In the meantime, we also found out that some users actually have an implicit meaning assigned to null vs. non-null.

Some users think that if the end time is null the collection/mission is still active and new items are added and that if a fixed end time is given, that the collecction/mission is "finished"/not active anymore and as such they can't expect new items to be added.

Just want to put this out here as an additional data point. This is probably something that can be clarified with an additional field or in the description. (cc @gadomski )

[gadomski]

if a fixed end time is given, that the collecction/mission is "finished"/not active anymore and as such they can't expect new items to be added.

Interesting -- I don't think about the end time this way at all, but if other people do then we have to consider that.

This is probably something that can be clarified with an additional field or in the description.

Yeah, an is_active flag or something?

[m-mohr]

I'm not sure how common it is, but I heard some people mention it.

Yeah, not sure about the naming. is_active is a bit generic to me (what is active?). I'd like something that more directly expresses no_new_items_expected, but less verbose/long ;-) Anyway, that's probably a discussion to have somewhere else.