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

Formulate a joint strategy for eoAPI and Stacture #108

Closed
2 tasks done
Tracked by #113
j08lue opened this issue Oct 29, 2024 · 4 comments
Closed
2 tasks done
Tracked by #113

Formulate a joint strategy for eoAPI and Stacture #108

j08lue opened this issue Oct 29, 2024 · 4 comments

Comments

@j08lue
Copy link
Collaborator

j08lue commented Oct 29, 2024

eoAPI and Stacture are meant to be complementary in providing data access services.

What is our strategy for how they will continue to relate to each other and used together in the future?

Related tickets

Acceptance criteria

  • Discussed future needs and implementation pathways
  • Conducted technical deep dive and experiments to establish viability
@j08lue
Copy link
Collaborator Author

j08lue commented Nov 12, 2024

Preliminary diagram of services, not complete, just as basis for discussions

image

@j08lue
Copy link
Collaborator Author

j08lue commented Dec 13, 2024

Just a little update to the same kind of services diagram

image

We will complement this with architecture diagrams

@jankovicgd
Copy link
Collaborator

jankovicgd commented Dec 16, 2024

Hey, adding my thoughts so far on how titiler requests could be mapped to OGCAPI-maps requests. Coverages is a bit of a mystery and I will let it stay such for the time being, also seeing the standard is in its draft phase and project requirements around it are iffy. We are still researching and my initial thoughts led me to the following options:

  1. less likely option currently since the titiler feature is not there but writing it out as that was a first thought
    -query the stac api based on wms parameters
    -construct a dynamic mosaic json using queried information (if multiple items) and storing it temporarily with a presigned url
    -if single item
    /stac/bbox/{minx},{miny},{maxx},{maxy}/{width}x{height}.{format}
    -if multiple items hitting a similar endpoint to this one but for mosaic json as it is the closest to how maps works
    (/stac or /cog)/bbox/{minx},{miny},{maxx},{maxy}/{width}x{height}.{format}
    -forwards result

  2. after learning about more features in eoeapi eg. /raster/searches also seems interesting
    -wms query comes in (probably pygeoapi leveraging already existing ogc api logic, would have to see how to reuse internal api for extension)
    -the search is registered based on query params
    -the search is hit with /searches/{search_id}/bbox/{minx},{miny},{maxx},{maxy}/{width}x{height}.{format}
    -the data is returned
    Here it seems that if the endpoint is hit often with a wide array of bboxes, It may create a lot of searches that will be realistically hit once.

@j08lue
Copy link
Collaborator Author

j08lue commented Jan 10, 2025

We can consider this spike to be complete - we discussed software roadmaps and identified ways forward, creating a good basis for concrete technical prototyping, like currently going on in

@j08lue j08lue closed this as completed Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants