Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output/result scheme implementation #3

Open
herzogrh opened this issue Jul 4, 2024 · 3 comments
Open

Output/result scheme implementation #3

herzogrh opened this issue Jul 4, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request shouldhave "Should have" prioritization for the project

Comments

@herzogrh
Copy link
Member

herzogrh commented Jul 4, 2024

Problem: OGC API Processes does not define the data schema of job-results, but allows schemas to be freely defined. The geoserver/storage component of the UMP must interpret the job results and extract the relevant information.

depending on the output schema, a "value" key may be prescribed according to the api spec, under which the output can be found (qualified values)

Implementation on both sides: Model server should adequately describe the output schemas and UMP (geoserver/storage component) must read the output description and thus parse job results

The geoserver/storage component must read the output structure of the process description:

Example:
grafik

@herzogrh herzogrh added the enhancement New feature or request label Jul 4, 2024
@herzogrh herzogrh added the shouldhave "Should have" prioritization for the project label Aug 19, 2024
@hwbllmnn
Copy link
Collaborator

hwbllmnn commented Oct 1, 2024

The OGC API processes allows for a lot of freedom in the definition of the output. Wouldn't it be better if we'd define some kind of convention on how the output should look like? Looking for feature collections anywhere in the output tree might be overkill IMHO, especially in case of special output constructs containing several features/feature collections in different places.

@herzogrh
Copy link
Member Author

For us it would be best if we could have as much freedom as possible in the configuration. Maybe it's good to conceptually separate it into two parts:

  1. A modular architecture where the parsing of various output types and connection to the GeoServer happens (which could be flexibly extended in the future with additional formats)
  2. A configuration in which one would specify which parts of the output of a model would be handed over to the parsing part
    I also think it'd make sense that for each job/simulation run, there is only one single Layer in the Geoserver created. What do you think @hhmric @StefanSchuhart ?

@herzogrh
Copy link
Member Author

I think #62 works well, but it seems like I can only configure one path in the results that will be stored in the Geoserver. We should incorporate the graph section in the details page aswell and some way to specify if either multiple forms of geodata will be provided or which form (eg. GeoTIFF).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request shouldhave "Should have" prioritization for the project
Projects
None yet
Development

No branches or pull requests

2 participants