Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: fill the remaining `xarray-edr` query types (radius, area, instances, trajectory, corridor) — volunteer effort

Aperta
  • Qualcosa non va?
#2,435 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
api, backend, databases

Direzione di ricerca

Start with RFC4, pygeoapi/provider/xarray_edr.py, the BaseEDRProvider methods, and get_collection_edr_instances; compare the provider matrix and EDR 1.0.1 requirements. The proposal spans a base API bug, shared parsing and sampling, and five query types, so agree the design and split the work into small PRs. Done means each accepted query type has tests, its docs matrix cell, and the matching conformance declaration.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Is your feature request related to a problem? Please describe.

The xarray-edr provider serves position and cube only. The provider matrix says so and pygeoapi/provider/xarray_edr.py at master 0b38380 matches it. Radius, area, instances, trajectory and corridor — all defined in EDR 1.0.1 — are not available over gridded NetCDF/Zarr data, so a client needing conditions along a route or within a corridor has no stock pygeoapi it can point at. I've searched open issues and PRs for the five types and found none; please point me at anything I've missed.

I have a maritime use for trajectory and corridor queries over gridded fields and would rather build them upstream than in a fork. This is volunteered effort on my own time; I'm opening the issue first, per RFC4, to confirm the direction suits the project and agree a few design points before writing code.

There is also a bug in the path these would use. BaseEDRProvider.instances() and instance(id) both return NotImplementedError() rather than raise. get_collection_edr_instances tests instance(id) for truthiness, so a provider inheriting the default accepts any id, including nonsense; and it iterates instances(), which on the default is an exception object and surfaces as a 500. A False from instance() leaves instances unassigned.

Describe the solution you'd like

A sequence of small PRs, one query type each, with tests, the docs matrix cell and the conformance declaration in the same change:

  1. Instances bug fix — small and separate, before anything else: base methods raising ProviderItemNotFoundError (the only exception that path catches) and the API handling the not-found branch.
  2. Foundations — shared WKT parsing for LINESTRING Z/M/ZM and POLYGON, z/datetime resolution against the dataset's own axes, a CoverageJSON helper for trajectory-shaped output. No new query type.
  3. Radius — within, within-units, great-circle buffer.
  4. Area — polygon mask, with a dateline test.
  5. Instances — the xarray-edr implementation of the existing contract.
  6. Trajectory — 2D/3D/4D. Each vertex is sampled at its own time when M is present (seconds since the Unix epoch), or at the datetime parameter otherwise. For M and datetime both present, clause 8.2.5 of EDR 1.2 says an error shall be thrown, though that clause is marked informative — I'd return 400 either way rather than silently prefer one; the normative wording is in A.5.9 (/req/edr/linestring-coords-response).
  7. Corridor — corridor-width/-height, width-units/height-units, resolution-x/-z.

Trajectory depends only on step 1, so it needn't wait on instances. Query-type registration moved to BaseEDRProvider.__init_subclass__ in #2049, so each added type registers itself by method name without touching the API layer.

Design points I'd like a steer on:

  • Sampling. Nearest-neighbour throughout, matching current position behaviour. EDR defines no interpolation parameter, so anything else would be an invention; I'd leave it for a later discussion if there's appetite.
  • Instances contract. With the bug fixed, the API layer already routes /collections/{id}/instances/{instanceId}/... and the two base methods are the whole provider contract; my question is how xarray-edr should implement them — a configured dimension name (e.g. forecast reference time) seems the obvious shape.
  • Corridor. Cross-section orientation at a bend is left open by the spec; I'd document the choice in the provider docs and take direction if the project has a preferred reading.
  • Target version. pygeoapi declares ogcapi-edr-1/1.0/conf/core and is a certified reference implementation at 1.0.1. Every query type here exists in 1.0.1, so I'd stay on that declaration and not touch conformance URIs. EDR 1.2 landed on 2026-09-08; whether and when to move is a separate discussion I'm not proposing to open here.
  • Process. This issue plus PRs, or would the PSC prefer an RFC?

What I'll bring:

  • Tests before implementation.
  • 4xx responses that say which parameter or option isn't supported, rather than a silent empty result.
  • CITE run against each added conformance class where a suite exists for the target version; where it doesn't yet, the abstract test suite in Annex B as a checklist.
  • An independent client with known ground truth to exercise the branch beyond what unit tests catch.
  • I intend to stand up a public deployment of the result for the live-deployments page.
  • I'll stay on as point of contact for these code paths after they merge.

Describe alternatives you've considered

  • Port the NWS fork. The NWS EDR-API demonstrated the full set against xarray from an early pygeoapi fork; it hasn't been upstreamed yet. It has diverged too far to merge, so I'd read it for lessons rather than port it.
  • A community provider plugin out of tree. Workable, and my fallback if this isn't wanted in core — but it would leave the matrix as it is for everyone else, and upstream is my preference.
  • Another server with broader EDR coverage (FMI SmartMet, KNMI ADAGUC). Both are whole product servers over their own engines rather than something to add to an existing pygeoapi deployment.

Additional context

The hash above is accurate as of posting and will drift with the next merge. Happy to split this into one issue per PR if that suits triage better.

Lingua principale
Python
Stelle
626
Fork
334
Merge medio
20h 31m
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di geopython/pygeoapi

Tutte le issue di geopython/pygeoapi

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.