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

Chat about single collection architecture #7

Open
aaime opened this issue Nov 4, 2024 · 1 comment
Open

Chat about single collection architecture #7

aaime opened this issue Nov 4, 2024 · 1 comment

Comments

@aaime
Copy link
Member

aaime commented Nov 4, 2024

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

  • https://how2map.geocat.live/geoserver/ogc/features/v1

    • Conformance how this service can be used.
    • Items cross link to companion ogcapi services.
  • https://how2map.geocat.live/geoserver/ogc/features/v2

    When this is added does it cross link to others?

@aaime aaime converted this from a draft issue Nov 4, 2024
@aaime aaime changed the title Consider single tree architecture Chat about single collection architecture Nov 4, 2024
@jodygarnett
Copy link
Member

Q: OGCAPI is assuming moncollection architecture.

The longer we hold out the more challenges we are going to have.

Q: How to version v1 and v2 the distinct collection end points?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants