Draft revised SWG charter for review

[maxrjones]

Following up on past discussions on GitHub and at SWG meetings, this PR proposes a re-charter of the GeoZarr SWG, reflecting the strategic reset initiated in #101.

I view this as documentation of the direction we embarked on in December 2025 and have refined since, not anything substantially new. The charter should serve as a shared statement of the vision for both SWG members and observers. The feedback I'd most appreciate is on how well this text writes that direction down.

The substantive changes from the 2023 charter (OGC 23-046):

• Scope: GeoZarr is framed as a profile over composable Zarr conventions (spatial, proj, multiscales for Version 1), with proposed groupings for subsequent versions and the assessment criteria for incorporating conventions. This is the section that captures the reset. Please focus reviews here.
• Deliverables: the candidate Standard becomes an integration/profile document with conformance classes that normatively reference the conventions at pinned versions, plus an abstract test suite with executable scripts.
• Change control: convention repos remain the source of truth; the SWG owns selection, integration rules, and conformance classes, and proposes convention changes upstream rather than editing the OGC document.
• IP and licensing: repository content stays permissively licensed; the compiled OGC standard carries the OGC license, with referenced content acknowledged on the cover.
• Alignment updates: "SWG voting members" terminology and re-chartering boilerplate.

Known placeholders, to be resolved before the charter goes to a vote (no need to flag them in review):

• OGC document number and submission date (requested from OGC staff)
• Home DWG identification and endorsement (Section 7)
• First-meeting eligibility boilerplate, pending confirmation of the current Agora-era process
• Section 8.5 supporters. If you support this re-charter, please add your name and organization to the table in this PR

The next steps for this PR:

• Discussion at July 7 SWG meeting
• Solicitation of feedback from the OGC Technical Committee Chair
• Open discussion via both GitHub and Agora (1 week window for questions/comments, then approval vote with the 2-week objection window)

[christophenoel]

Nice work @maxrjones . Some feedback below.

Scope

One key role of GeoZarr is illustrated in the figure below. The potential EO related conventions include both format-agnostic and format-related conventions. GeoZarr should provide the governance needed to reach community consensus on which of these conventions, or combinations of conventions, constitute the official GeoZarr specification (or a defined set of GeoZarr profiles). I think this is reflected in your update.

In addition, GeoZarr should define recommendations or requirements needed to ensure interoperability. For example, it could specify whether groups should be independently usable (with consolidated metadata), or a store should contain a single root hierarchy, and other implementation rules that promote consistent, interoperable GeoZarr datasets across the community.

[christophenoel]

The proposed Version 1 focuses on spatial, PROJ, and multiscales conventions, but it does not address one of the most common interoperability patterns: the representation of coordinate variables. In practice, these are fundamental elements of many EO datasets (and the benefit beyond COG).

For that reason, I am concerned that a first GeoZarr specification without an agreed coordinate convention may leave an important interoperability gap. I believe this aspect should be considered part of the core discussion before finalising Version 1.

[pvanlaake]

Following up in writing on the points I raised in today's GeoZarr SWG meeting, having now read the draft charter document.

What a charter is for

A charter's job is to define how the SWG evaluates and admits conventions: the process, the evidence bar, the conformance model. It shouldn't itself contain a snapshot of which conventions currently exist or are currently favoured. Those are different documents: one is governance, the other is a roadmap. As drafted, this charter does the second thing and calls it the first.

Why that's a problem in practice, not just in principle

Section 3 names spatial, proj, and multiscales as V1 scope, and lists several others as future work. That list (who's in V1, who's "future") is contentious (it presumes a certain development direction and style of the conventions) and it is likely to become outdated within months of adoption of the charter. Writing it into the founding document implies that a decision is made, just without going through any community evaluation and vetting process. Whatever conformance class gets called "GeoZarr V1" becomes the de facto standard the moment this is adopted, regardless of whether the harder principal convention (coordinate representation) is settled. That's how I read @christophenoel 's objection about the coordinate convention gap, and I agree, even if I'd resolve it differently than he's proposing.

I would propose to replace the named convention list in the charter document with two independent, generic categories, defined without naming any specific convention, existing, proposed, or prospective:

1. Status: Consisting of (1) Conventions adopted in the GeoZarr standard, and (2) Proposed conventions. This latter group would include conventions that developers propose as a potential GeoZarr standard.
2. Nature: Different kinds of conventions can be identified. Principal conventions define the coordinate system in some application domain (the "minimal GeoZarr" baseline), with current examples being spatial, coords and cs. Additional classes for everything layered on top of "principal" conventions (like proj, multiscales) should be defined, either as a single class or a few specialised classes (e.g. a domain-like class like "CF" or a generic class like "description"). (None of these specifics would be included in the charter document.)

Under this structure, V1 can ship as: one candidate principal convention (spatial) and two supporting conventions (proj and multiscales) that have met the evidence bar; other principal and supporting conventions remain candidates under evaluation. That states the coordinate-representation gap explicitly in the charter's own structure, instead of settling it by omission or by forcing a premature pick under deadline pressure (which is what pulling coords into V1 right now would amount to).

This also protects the charter from needing amendment every time a new convention shows up, or every time a currently-unnamed candidate is proposed, which a document meant to govern the SWG for years should be built to withstand.

Process

The current one-week comment window is proportionate to adopting a convention update. It's not proportionate to adopting the rules that will govern how every future convention, including ones nobody's proposed yet, gets judged. I propose that the vote on this draft be scoped as provisional/interim pending a structural revision along these lines, rather than adopted as final SWG governance under the current OGC schedule pressure.

Happy to open a counter-proposal PR along these lines, if that's useful groundwork before the TC chair review.

[christophenoel]

I agree. In principle, the charter should be generic enough to define only the SWG's scope, objectives, governance, and intended deliverables, not prescribe a specific version or a fixed set of conventions. At most, it could include an informative list of the initial candidate conventions, clearly identified as non-normative.

The charter should also be stable over time and only require revision if the SWG's scope or mission fundamentally changes, rather than whenever the set of conventions evolves or the community reaches new technical consensus.

[maxrjones]

One key role of GeoZarr is illustrated in the figure below.

@christophenoel I'm confused by the definition of format in your figure. Shouldn't all GeoZarr components be related to the Zarr data fromat?

[christophenoel]

That was not my point. I wanted to stress out another challenge for geozarr: some conventions focus on features, some other are focused on encoding other format capabilities in zarr: in some case , this lead to collisions (multiple means to encode the same information).

[pvanlaake]

I wanted to stress out another challenge for geozarr: some conventions focus on features, some other are focused on encoding other format capabilities in zarr: in some case , this lead to collisions (multiple means to encode the same information).

I do not see that as something that needs to be avoided, but rather as something that needs to be managed.

Zarr conventions (in general) are intended to be community-driven, allowing diverse application domains to compile a set of conventions that jointly cover the needs of that community. The useful ones will float to the top, the marginal or niche ones sink to the bottom (however "top" and "bottom" are defined).

In GeoZarr that is no different, even though the selection process is more more controlled. While focused on the narrower scope of geospatial data, compared to the domain-agnostic Zarr, that narrow scope is still diverse enough to warrant a range of solutions. Having such flexibility allows for new paradigms and new applications to emerge as conventions, rather than having to straight-jacket into building on the conventions that are currently adopted by GeoZarr - assuming that GeoZarr and its conventions will be around for a few decades, you'd be making a final decision now for describing data that is produced in 2040; that is surely not what you have in mind but it could result in that. Such a high bar for new conventions also runs the risk of GeoZarr stalling after, say, V.2 or V.3 because convention developers will go for solutions that work for their application domain rather than having to tweak solutions to the existing set of conventions.

The maturity framework will effectively deal with this challenge because new conventions that turn omissions into commissions will not be implemented. The GeoZarr assessment criteria for conventions to be adopted forms another useful barrier to "frivolous" conventions. On the human side, managing this challenge should primarily be the responsibility of the data producers, i.e. the direct users of GeoZarr conventions. GeoZarr could support users in selecting a set of conventions by describing a number of application domains. As an example:

If you want to store a set of satellite images in a Zarr store using GeoZarr conventions there
are two recommended approaches for the description of the coordinate system, depending
on the type of imagery:

1. For imagery in a platform-based coordinate system, typically called level-1 data, you can
   use the `coords` or `cs` conventions.
2. For imagery that has been georeferenced and using a North-up coordinate convention, the
   `spatial` convention is most appropriate, in combination with the `proj` convention to
   describe the coordinate reference system.

[christophenoel]

Understood. That is not my opinion and the intend we had with ESA for GeoZarr.

[chris-little]

The charter should also be stable over time and only require revision if the SWG's scope or mission fundamentally changes, rather than whenever the set of conventions evolves or the community reaches new technical consensus.

The "traditional" structure of a SWG Charter is to be relatively generic but specific scope, with detailed content in a Work Plan Annex, and the latter could have a lighter weight process for updating.