1 shot discovery (and then access) to cutouts was possible in SIA1 but no more in SIA2

[Bonnarel]

SIAP1 had « cut out » and « mosaic » modes besides « archive » mode
→ 1 shot before access but only spatial
We now have :
SIAP2.0 or ObsTAP which deal with all axes

• SODA : for cutouts only (all axes)
  +DataLink (Service descriptor and/or {links} table)
  → 2 shots before access (instead of 1)

Although it is pretty useful to have the 2 shots sometimes (allow the user to choose the actual limits according to ObsCore content and general context) there have been some complains (SkyView people for example also others) that the one-shot functionality disappeared.
It would be perfectly possible to provide it by replacing the full retrieval or datalink url in access_url by a SODA url. SODA URL parameters are common with SIA. Where SIA Parameters values constrain the discovery, SODA parameters force the cutout dimensions.

A capability "virtual data generation" would have to be added to the service.
If it exists how do we choose to provide these cutouts
by a new "VIRTUAL" boolean parameter?
Or by providing two lines in the response with the same obs_id ?
The obscore values will be different, encluding publisher_did, but the observation will be the same

[molinaro-m]

Is the "overlap" condition considered here?

I mean, if the discovery returns full overlaps and partial overlaps between query and datasets coverage, what would be the correct response?

(in a custom service we manage, we return an overlap indicator in the discovery response)

[pdowler]

One of the primary use cases for TAP|SIA -> DataLink -> SODA is that one "result" may have a 1..n relation to files (hence DataLink) and cutouts are very much an operation on a file (rather than a result). Still, if a specific service has a 1..1 relationship between result and file, it could proceed directly to cutout without the need for a DataLink call (links endpoint).

This can be done now and still give the caller the choice after they inspect the query results: in such as case, the access_url would be a URL to the whole file and a service descriptor could tell the caller how to invoke a SODA service for each record in the results. The caller would construct the SODA URL instead of the service, but all the info to do that can be there in the votable so it is really just a matter of who spends some cycles generating the URLs. The number of http requests would be the same in both cases.

So, in my opinion we can already do this and we just need to document how this should work for providers and clients. Also, even in the case of a 1..n relation between result and files, I see no problem with a provider adding a SODA service descriptor to enable cutouts "in the primary science data" (aka #this in the links output) even if access_url points to a links endpoint.