Inconsistent and non-standard CRS handling for geometry arguments in DataCube

[soxofaan]

stumbled on this while working on #104:

openeo-python-client/openeo/rest/datacube.py

Lines 1074 to 1087 in 5a3e6f4

	if crs:
	# TODO: don't warn when the crs is Lon-Lat like EPSG:4326?
	warnings.warn(f"Geometry with non-Lon-Lat CRS {crs!r} is only supported by specific back-ends.")
	# TODO #204 alternative for non-standard CRS in GeoJSON object?
	epsg_code = normalize_crs(crs)
	if epsg_code is not None:
	# proj did recognize the CRS
	crs_name = f"EPSG:{epsg_code}"
	else:
	# proj did not recognise this CRS
	warnings.warn(f"non-Lon-Lat CRS {crs!r} is not known to the proj library and might not be supported.")
	crs_name = crs
	geometry["crs"] = {"type": "name", "properties": {"name": crs_name}}
	return geometry

e.g. public facing from cube.aggregate_spatial(..., crs=...) and cube.mask_polygon(..., srs=...)

This CRS handling has some problems:

• it's an ad-hoc, non-standard feature not present in official processes
• it's inconsistent: sometimes it will apply (when geometry is client-side GeoJSON), sometimes it won't (e.g. back-end side vector cube)
• it will ignore crs info already present in GeoJSON and will blindly overwrite it

I think we should get rid of this

[soxofaan]

related discussions and threads:

• CRS for vector data openeo-processes#235
• (Experimental) CRS support for geojson objects #204
• e344c4c
• Remove non-standard srs argument from mask_polygon #202

[soxofaan]

As far as I understand the threads above, the "crs" support mentioned above was originally targeted to the use case where the geometry is provided as shapely object (which has no explicit CRS info), which has to be converted to GeoJSON to be embedded in the process graph. Over time, a lot more geometry value types for geometries were added (e.g UDP parameters, vector cubes, load_url, ...), where it's impossible to attach that CRS to, so we now have a very inconsistent CRS handling situation.

[soxofaan]

proposed solution:

• stop supporting crs/srs arguments directly in aggregate_spatial, ... (because it's impossible to do it consistently). Instead throw exception pointing to proper way to do it (e.g. docs).
• provide convenience function to support the conversion need from shapely to GeoJSON with custom CRS

So use cases that wanted to use shapely geometries with custom crs the old way:

cube = cube.aggregate_spatial(
    geometries=shapely_geometry,
    crs="EPSG:123456",
    ...
)

would have to change to something like

cube = cube.aggregate_spatial(
    geometries=shapely_to_geojson(shapely_geometry,  crs="EPSG:123456"),
    ...
)

[jdries]

I would:

• make sure that shapely geometry remains supported
• add shapely geometry support to load_collection as well, the absence there is the most annoying inconsistency for me
• improve documentation of crs keyword to state that it's actually deprecated.