new id when feature is added

[lhcorralo]

Describe the issue
Trying to insert a new feature with 'id' set, the item is inserted using another id.

First of all, clarifying that I am not sure if this is a bug or a misunderstood of the STAC specification by me (probably tle later).

Expected behavior
If an id is provided, it should be used for later data retrieval.

Additional context
Assuming that the collection is already created, a post request with URI http://{{STAC_SERVER}}:{{STAC_PORT}}/collections/sentinel-2-l1c/items and body:

{
	"type": "Feature",
	"stacVersion": "1.0.0",
	"stacExtensions": ["order"],
	"id": "d6376531-3ec5-35f2-8a07-4d1f7d3116c8",
	"collection": "sentinel-2-l1c",
	"geometry": {
		"type": "Polygon",
		"coordinates": [
			[
				[0.23093206, 49.61959688],
				[0.28537105, 48.63303182],
				[1.77513104, 48.65851892],
				[1.75053741, 49.64598097],
				[0.23093206, 49.61959688]
			]
		],
		"crs": {
			"type": "name",
			"properties": {
				"name": "EPSG:4326"
			}
		}
	},
	"bbox": null,
	"properties": {
		"datetime": null,
		"startDatetime": "2022-12-09T11:04:41.024Z",
		"endDatetime": null,
		"created": null,
		"updated": "2022-12-09T15:19:25.714988Z",
		"order:status": "ordered"
	},
	"links": [],
	"assets": {}
}

The server returns

{
    "status": "success",
    "message": "Inserted features",
    "inserted": 1,
    "inError": 0,
    "features": [
        {
            "featureId": "1c8338f8-a225-52cc-a018-f975f1996509",
            "productIdentifier": "d6376531-3ec5-35f2-8a07-4d1f7d3116c8",
            "facetsStored": true
        }
    ],
    "errors": []
}

The problem is due to the need of later updating the item (in particular the order:status property). I need the id for making a PUT request. Making the PUT request directly is not a solution (the item must not be overwritten in this case).

From the result, I see that the provided id is stored as productIdentifier. I could get it from there, but I am worried about if this would be an implementation-specific solution: I could not find any details about this particular use case in the STAC API specification, and I cannot run POST requests in other servers (I tried stac-fastapi but I could not start it up).

I have seen the code in

resto/app/resto/core/RestoModel.php

Line 804 in d249b8c

private function storeFeature($collection, $data, $params)

but I am not a php programmer, and I cannot guess why my test is not working.

[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