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
The original thread also mentions re-architecting the modules to be single-collection centric, rather than being service centric (one resource tree exposing all services at the same time), but if going down this road, we'd also have to ensure the various services can be deployed in different micro-services in a setup like GeoServer Cloud. (I'm guessing, with the gateway in charge of redirecting requests to service specific resources to a different process).
OGC API - Common - Part 1: Core:
7.2. Modular APIs
...
Modularization is not just about a single “service”. OGC APIs provide building blocks that can be reused in APIs in general. In other words, a server that implements the OGC API – Features Standard should not be seen as a standalone service. Rather, this server should be viewed as a collection of API building blocks that together implement the capabilities that are specified in OGC API — Features. A corollary of this is that it should be possible to implement an API that simultaneously conforms to conformance classes from multiple current or future OGC API Standards.
To discuss:
The moncollection approach (single collection with mixed items) can we have it alongside distinct services?
How to links work between things? Do we just duplicate ...
For duplication how does it work with v1 and v2 ...
powerset: Does features/v1 need to cross link to tiles/v1 and tiles/v2 etc...
moncollection/v1` would need to check conformance to see how all the items cross link
single ogcapi service / monocollection
https://how2map.geocat.live/geoserver/ogc/v1
Conformance describes how this service can be used. All items cross link consistently with each other.
https://how2map.geocat.live/geoserver/ogc/v2
When added these items consistently link to other items in v2 only.
distinct ogcapi services / each with their own colleciton
The original thread also mentions re-architecting the modules to be single-collection centric, rather than being service centric (one resource tree exposing all services at the same time), but if going down this road, we'd also have to ensure the various services can be deployed in different micro-services in a setup like GeoServer Cloud. (I'm guessing, with the gateway in charge of redirecting requests to service specific resources to a different process).
OGC API - Common - Part 1: Core:
To discuss:
v1
andv2
...features/v1
need to cross link totiles/v1
andtiles/v2
etc...single ogcapi service / monocollection
https://how2map.geocat.live/geoserver/ogc/v1
https://how2map.geocat.live/geoserver/ogc/v2
When added these items consistently link to other items in v2 only.
distinct ogcapi services / each with their own colleciton
https://how2map.geocat.live/geoserver/ogc/features/v1
https://how2map.geocat.live/geoserver/ogc/features/v2
When this is added does it cross link to others?
The text was updated successfully, but these errors were encountered: