new id when feature is added about resto

[jjrom]

Hi @lhcorralo - thanks for raising this point.

resto existed well before the STAC specification. The original resto API was aligned with OGC OpenSearch Extension for Earth Observation specification with the objective to imagery from different producers. Each producer has his own naming convention for its product aka the "productIdentifier". In order to harmonize the naming convention, resto generates a unique uuid identifier from this original productIdentifier.

With the move to STAC, the product identifier is the item ID. However, the STAC specification stated that "The specification is quite flexible on ID's, primarily so that existing providers can easily use their same ID when they translate their data into STAC". So there is no requirement that the ID is an UUID and as a consequence (and by design), resto converts this identifier to produce its own UUID identifier.

I understand that this is a bit confusing specially if the input id is already a valid UUID. I should probably update the code to leave this untouched in this case

[lhcorralo]

Hi @jjrom

Uff, I think this is a delicated point. I understand the problem, but I cannot see an easy solution... Keeping the 'id' if it is an UUID would only fix my particular case. I guess that, in order to make Resto more STAC compatible, the solution would be changing the UUID by a string, but well... that kind of things leads to broken compatibility and pain... and nobody likes painful things.

I guess it is better to leave this as is by now, and leave this kind of changes for Resto 7.x branches. However, It would be nice to have documented this kind of "gotchas".

I am looking forward to hearing your opinion (as both resto developer and STAC/OGC veteran).

Thanks :)

Luis

[jjrom]

Corrected in #345