feat: add NDVI process endpoint and OpenAPI documentation#4
feat: add NDVI process endpoint and OpenAPI documentation#4ChristianBeilschmidt wants to merge 40 commits intomainfrom
Conversation
Added a proprietary license to the repository outlining permitted and prohibited actions regarding the software.
- Removed geoengine-datatypes and geoengine-operators dependencies from Cargo.toml. - Updated NDVI process in ndvi.rs to use new VectorOperator and RasterOperator structures. - Refactored source functions to return RasterOperator directly instead of boxed trait objects. - Modified to_api_workflow function to accept VectorOperator and adjusted workflow type handling. - Updated unit tests to reflect changes in operator structure and ensure correct serialization.
ChristianBeilschmidt
force-pushed
the
openapi
branch
3 times, most recently
from
824c232 to
17254a8
Compare
ChristianBeilschmidt
force-pushed
the
openapi
branch
10 times, most recently
from
be5b2c4 to
438e3d6
Compare
ChristianBeilschmidt
force-pushed
the
openapi
branch
from
438e3d6 to
20fae4a
Compare
|
supersedes #3 |
|
|
||
| ### | ||
|
|
||
| POST http://localhost:4040/processes/ndvi/execution |
There was a problem hiding this comment.
if I delete the ndvi dataset on the server I still get a weird error:
{
"type": "500",
"detail": "error in response: status code 400 Bad Request"
}
| @@ -0,0 +1,22 @@ | |||
| # Copilot Instructions | |||
There was a problem hiding this comment.
do we also need a AGENTS.md in the root of the project?
like homeassistant does https://github.com/home-assistant/core/blob/dev/AGENTS.md
There was a problem hiding this comment.
No, for Copilot, this is the recommended way. This gives a general instruction for everything and scoped instructions for parts. This works in VSCode like a charm.
backend/src/bin/openapi.rs
Outdated
| let mut openapi_spec = None; | ||
| for _ in 0..10 { | ||
| info!("Trying to fetch OpenAPI spec from server…"); | ||
| if let Ok(spec) = server.try_fetch_openapi_spec().await { |
There was a problem hiding this comment.
why load the openapi spec from our own server instead of just generating it? is it because of the ogcapi crate?
| #[allow(unused, reason = "Placeholder for spec only")] | ||
| #[utoipa::path( | ||
| post, | ||
| path = "/processes/ndvi/execution", |
There was a problem hiding this comment.
is it "in the spirit of" ogcapi processes that the jobs are hardcoded as paths in the openapi schema? would be a bit like offering individual workflows in the openapi spec of Geo Engine as paths
There was a problem hiding this comment.
Under "15. Additional API Building Blocks", it says
This standard uses the OpenAPI specification to define the JSON schemas and OpenAPI MAY also be used to describe the concrete API (see Clause 7.3). […] To cope with this and thus make the implementation of clients / servers easier for those that are not familiar with OGC (API) standards, additional alternatives to the process description and the paths to processes and jobs are permitted.
Moreover, this allows us to statically type it in our UI.
backend/src/bin/openapi.rs
Outdated
| } | ||
|
|
||
| // const OPEN_API_PATH: &str = "api"; | ||
| const OPEN_API_PATH: &str = "api_v3.1"; |
There was a problem hiding this comment.
why does the openapi version matter? would we ever host multiple versions of openapi schema simultaneously?
There was a problem hiding this comment.
The current schema is version 3.1, which extends JSON-schema.
However, the current OGC cite validadation software fails on OpenAPI 3.1, but requires the old one. Thus, ogcapi offers under /api the one that gets eaten by CITE and under /api_v3.1 the better one.
2 participants
path_info.rs.justfilefor managing API client generation and backend tasks.openapi.json.