Schema overrides for geometry in read_vector/aggregate_spatial

[soxofaan]

Moving the technical discussion from https://discuss.eodc.eu/t/server-error-413-request-entity-too-large/451/ to here:

@m-mohr : In aggregate_spatial you need to allow vector cubes and strings as input geometries
@soxofaan : We follow the official aggregate_spatial spec, so that depends on Open-EO/openeo-processes#323 and related vector-cube (loading) api/processes
@m-mohr : Yes, but you don’t implement the official specification, but you actually implement more than the official spec. So you’d need to add two additional schemas. One for strings and one for vector-cubes. Once we have an understanding of vector-cubes that will also land in the official spec, but we are not there yet (while VITO somewhat is).

To be clear: the geometry as URL (string) is a pure client-side feature in the python client: a read_vector node is automatically added. A string geometry is not supported by the VITO back-end directly.

Also, back-end side "vector-cube support" is a bit of a stretch, we only support GeoJSON-style feature collections (so GeoJSON inlined directly as process arg, or from a file/URL through additional read_vector process). So that makes me wonder if it wouldn't be better to change the output of read_vector to {"type": "object", "subtype": "geojson"}.

[m-mohr]

Ah, I did not realize the string is a client-side thing. Having that in mind, it sounds like a good idea to change the return type to geojson, indeed.

[soxofaan]

With 5ad0c5e there is not much to be done here anymore I think,
the remaining vector cube will be done elsewhere