You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Which objects and data structures the model server delivers (GeoJSON, images, kml, gml, ...),
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.
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:
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)
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 ?
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).
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](https://private-user-images.githubusercontent.com/61881523/345785328-aa426ef7-dc1e-4a7c-ac41-9828a24af5c8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxOTMxODQsIm5iZiI6MTczOTE5Mjg4NCwicGF0aCI6Ii82MTg4MTUyMy8zNDU3ODUzMjgtYWE0MjZlZjctZGMxZS00YTdjLWFjNDEtOTgyOGEyNGFmNWM4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjEwVDEzMDgwNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWRiNWQ1ZTI3ZGQ2NGI2NWYwN2Y0N2NhZmI3YzZlYjIzZGMxMTYxZWQ3MTFiNWIyNWMyZjE0ZWUyYjg2YzAxNjgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.ZttGLlgPp2KE4LGZzTINXirJsWXvI4y9sNhHe3snl4Y)
The text was updated successfully, but these errors were encountered: