`load_url` with GeoJSON: alignation with `load_geojson`

[soxofaan]

This is follow-up of multiple earlier discussions (e.g. #322 #415 #427 #346).

Current openeo-processes draft has:

• load_geojson to load inline GeoJSON object, supports a properties parameter to let user select feature properties to load as cube data
• load_url to (among others) load GeoJSON from a URL, supports a generic options parameter

The properties parameter of load_geojson is not that trivial (e.g. see #448), but it is quite an important feature.

How to get this feature in load_url+GeoJSON?
I guess currently the only way is that the "GeoJSON" input format (GET /file_formats) defines a properties parameter that aligns with the properties parameter of load_geojson.

This has a couple of disadvantages for users, backends and documentation:

• duplication between a process spec and a file format option.
• For load_url+GeoJSON it's a lot harder for regular users to discover the properties feature and it's documentation.
• Also for clients environments (e.g. Python client) it's a lot harder to suggest the properties option for the load_url process, while this is trivial for load_geojson

Possible alternative: add support in load_geojson for loading from URL in addition to inline GeoJSON. I would guess that the additional implementation work for a back-end implementer is very minimal to add this.

This has been discussed before, but I can not completely reconstruct if this idea was intentionally dropped or forgotten.

[SerRichard]

This would also be good for the openeo-processes-dask. Currently we're using a custom "load_vector_cube" process for loading the remote geometries and it would be better to replace it with the load_geojson process in the implementations ( for the obvious benefit of alignment ).

In order to realise this change we would currently need to support the additional process of load_url in the dask processes, but, as already mentioned the code to support loading from URLs direclty in the geojson implementation is minimal, and would be less work than implementing load_url and ensuring correct behaviour on our side.

Whenever the discussion is held, also a thumbs up from eodc for this!

[m-mohr]

A properties parameter would need to be added to the import file format GeoJSON,. which can be exposed and described in GET /file_formats with the same schema that is used in load_geojson. That's the cleanest way of doing it. All other ways would add a parameter that only exists for specific file formats to a generic process.
In the end, load_geojson is a convenience process for the approach described above.

Adding URI as an input for load_geojson could be an option, but the question is where to stop. Then would we also add it for loading from the user workspace (i.e. a path?). load_geojson was meant as a way to embed geojson into the process graph, because we deprecated it in all the processes that supported geojson before (and migrate to vector cubes). That was it's primary purpose, otherwise we wouldn't have added it in the first place and we'd only have load_url.

[m-mohr]

I think my comment from January is still valid and I don't see an urgent need to solve this for v2.0.0-rc.2.
If we'd want to add additional input schemas (url, file-path), we can also do this in a later version as it's purely additive.