Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,435 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
api, backend, databases

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
626
Fork
339
Merge trung bình
2 ngày 2 giờ
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của geopython/pygeoapi

Tất cả issue của geopython/pygeoapi

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.