Standards conformance

rHEALPixDGGS implements code to both define an rHEALPix DGGS Reference System and to perform topological queries on its identifiers. The project’s roadmap is for version 1.0 to be fully compliant with OGC Abstract Specification Topic 21 version 2.0 (OGC 20-040r3) / ISO 19170-1:2020, Discrete Global Grid Systems — Part 1: Core Reference System and Operations, and Equal Area Earth Reference System.

The conformance target is the specification’s strongest conformance class, Equal-Area Earth DGGS, which comprises the Common Spatio-temporal Classes tests A.2, A.3 and A.5, all DGGS Core tests (A.6–A.19) and all Equal-Area Earth Reference System tests (A.20–A.29) of the specification’s Annex A. Every test in Annex A is of type Basic, assessed by inspection of the DGGS specification’s documentation — so this page is both the project’s self-assessment and, as the remaining rows are completed, the conformance documentation itself.

Scope notes:

• The purely temporal tests A.1 and A.4 belong to the separate Spatio-temporal DGGS Core conformance class and are not required for a spatial DGGS; rHEALPixDGGS does not claim them.

• The interoperation modules deliberately stop at the library boundary: rHEALPixDGGS provides query execution and standard-format serialization, while transport protocols (HTTP and friends, e.g. an OGC API — DGGS service) belong to software built on top of it.

Each row below records a status:

• Met — the substance is implemented and stated here or in the linked API documentation.

• Partial — implemented in substance, with named work remaining.

• Planned — not yet implemented; the release target is named.

Common Spatio-temporal Classes

Test	What it requires	Status	Evidence and plan
A.2 zone geometry	Zonal geometry and topology conforming to the common data model (zones with boundaries, neighborhoods and hierarchy).	Partial	boundary(), vertices(), neighbors(); the explicit mapping onto the model’s classes is to be written (v1.0).
A.3 spatial location	Locations identified by reference to zones (ISO 19112 style).	Partial	cell_from_point(), geo_to_rhp(); mapping documentation to be written (v1.0).
A.5 RS using zonal identifiers	A reference system whose zones carry unique identifiers, a parent/child hierarchy, an extent and a representative position.	Partial	Cell suids, rhp_to_parent(), subcells(), the extent from boundary(), and the representative position centroid() (A.27; the nucleus() is the indexing point); a formal identifier grammar (valid strings, canonical form) is to be published (v1.0).

DGGS Core — reference system

Test	What it requires	Status	Evidence and plan
A.6 harmonized model	The reference system’s definition conforms to the Core data model (grids, refinement strategy, globe geometry).	Partial	All defining parameters live on RHEALPixDGGS (ellipsoid, N_side, north_square, south_square, max_resolution); the formal declaration against the model’s classes is to be written (v1.0).
A.7 CRS	A defined coordinate reference system, with coordinate-epoch provisions.	Partial	Ellipsoid plus the rHEALPix projection define the CRS operationally; WKT2/PROJJSON definitions and a dynamic-datum epoch statement are to be published (v1.0).
A.8 global domain	A specified global domain and its dimensionality.	Met	The domain is the entire surface of the ellipsoid of revolution; spatial dimension 2, no temporal dimension.
A.9 domain completeness	The level 0 grid covers the entire global domain.	Met	The six resolution 0 cells (N, O, P, Q, R, S) partition the plane image of the projection, whose inverse covers the whole ellipsoid.
A.10 location uniqueness	Every location lies in exactly one level 0 cell.	Met	Cells own their upper and left boundaries; cell_from_point() is deterministic and regression-tested at cell edges.
A.11 simple cells	Cells at every level are geometrically simple.	Met	All cells are simple polygons; on the ellipsoid they take one of four shapes (quad, cap, dart, skew quad; see ellipsoidal_shape).
A.12 direct position	Every zone is assigned a direct position inside its boundary.	Met	The direct position is the centroid (A.27), centroid(), which lies inside its cell for every cell shape (tested in tests/test_cell.py); the indexing point nucleus() is interior by construction.
A.13 address	Every zone has a globally unique identifier, structured on a recognized indexing method.	Met	Suids are hierarchy-based (resolution 0 letter plus one base- N_side² digit per refinement); uniqueness is structural. A formal grammar is to be published with A.5 (v1.0).
A.14 discrete global grid	Grids defined as the aggregation of all cells at one level.	Met	grid() enumerates the cells of any resolution.
A.15 grid sequence	The grid hierarchy is ordered by increasing refinement.	Met	Resolutions are the integers 0 through max_resolution; every API is indexed by them.

DGGS Core — functions

Test	What it requires	Status	Evidence and plan
A.16 quantization	Defined operations assigning external data to cells, conforming to the quantization model.	Partial	Vector quantization exists: cell_from_point(), polyfill(), linetrace(), CellZoneFromPoly, compact_cells(). The mapping of these onto the model’s quantization roles is to be written (v1.0).
A.17 zone queries	The full DE-9IM query interface between zones: contains, within, touches, disjoint, equals, intersects, overlaps, crosses, plus distance and relative position.	Met	Every operation and attribute of Table 53 is implemented. The DE-9IM and one-dimensional operations are methods of Cell: equals(), contains_cell(), within(), touches(), disjoint(), intersects(), overlaps() and crosses() (the last two are always False between two cells of one hierarchy, which nest, touch or are disjoint; region_overlaps() is the cell-against-region form), the DE-9IM pattern test relate(), distance() (the infimum distance between the cells: 0 when they intersect, otherwise the least distance between their boundaries, Euclidean in the plane or geodesic on the ellipsoid) with within_distance(), and relative_position() returning the Table 54 enumeration RelativePosition with relate_position(). The projectTo vector of the spec selects a dimension; for this two-dimensional grid relative_position takes its spatial part as a planar direction. The hierarchy predicates are parent_of(), child_of() and sibling_of(), with the spec’s inheritID flag. The operations that return zone sets are methods of ZoneSet, with zone-to-zone delegates on Cell: union, intersection, difference and sym_difference by exact hierarchical algebra under the rangeRefine resolution filter, buffer from distance, and parent, child and sibling with levels and inheritID per clause 8.3.3, whose worked examples are the tests. The query attributes boundary, convexHull and boundaryType are ZoneSet.boundary, ZoneSet.convex_hull and ZoneSet.boundary_type, the last a value of the EA_BoundaryType code list (Table 76, BoundaryType); every rHEALPix edge is a projectedLine. Beyond the mandate, the DE-9IM predicates are also defined between two zone sets read as regions. See Zone Sets.
A.18 interoperation query	Operations to read, interpret and execute external data queries.	Partial	External geometries (Shapely/WKT) are accepted as queries by polyfill() and linetrace(); the documented mapping onto the model’s query interface is to be written (v1.0). Transport protocols are out of library scope (see Scope notes).
A.19 interoperation broadcast	Operations translating query results into standard data formats for delivery.	Met	rhealpixdggs.export translates cells and query results into the TranslationType codes toGeoJSON (to_geojson(), an RFC 7946 FeatureCollection: longitude-latitude order, counter-clockwise rings, antimeridian-straddling cells split into MultiPolygons, cap and pole-touching cells closed as section 3.1.9 recommends; every feature valid and the features of a resolution tiling the longitude-latitude rectangle, verified over whole resolutions in tests/test_export.py) and toASCII (to_csv(), delimited text with the same attributes), publishing the centroid of A.27 as each cell’s position; geometries() gives the shapely geometries for OGR-backed writers. toGML follows in v1.0 with the application schema (#103); toHDF, toJSON-LD, toNetCDF and toXML are not planned. The broadcastResult operation of Table 60 (transport) is outside the library’s scope, per the note above.

Equal-Area Earth Reference System

Test	What it requires	Status	Evidence and plan
A.20 harmonized model	The EAERS definition conforms to the Equal-Area data model.	Partial	Substance as per A.6; the formal declaration (including the grid-constraint list with cellEquiSized first) is to be written (v1.0).
A.21 global domain	The domain is the whole Earth-model surface and the equal-size cell constraint is declared.	Partial	The domain is the whole ellipsoid surface (A.8); the formal cellEquiSized declaration rides with A.20 (v1.0).
A.22 initial tessellation	An initial grid of equal-area cells produced by mapping the faces of a base polyhedron to the Earth model.	Met	The six cube faces map to the six resolution 0 cells through the rHEALPix projection; their areas are exactly equal by the projection’s equal-area property.
A.23 tessellation sequence	Tessellation operations generating progressively finer grids.	Met	Each cell subdivides into N_side² congruent planar children; subcells().
A.24 sequence maximum	A declared limit on refinement iterations tied to the cell-area error budget.	Partial	RHEALPixDGGS.max_resolution (default 15) and max_areal_resolution exist; the derivation tying the limit to the area error budget is to be documented (v1.0).
A.25 global area preservation	Domain completeness and position uniqueness preserved at every level (dynamic-datum form).	Met	WGS84 is a dynamic datum; completeness and uniqueness hold at every level by the subdivision construction (A.9, A.10 apply per level).
A.26 cells are simple 2D polygons	Every EAERS cell is a simple polygon.	Met	As A.11; the boundary-curve types per cell shape are to be described alongside the GML work (v1.0).
A.27 direct position is the centroid	Each cell’s direct position is its centroid, the geodesic center of surface area.	Met	Requirement 27: “the DirectPosition of an EA_Cell [is] the centroid of the EA_cell, computed as the geodesic centre of surface area”, and its test “requires verification that the attribute EA_Zone(centroid) returns a direct position on the surface of the cell”. centroid() is the published position: the area-weighted mean of longitude and latitude over the cell, integrated in the equal-area plane (where equal planar area is equal surface area) with a fixed Gauss-Legendre rule per cell shape, exact to about 1e-14 degrees; rhp_to_geo() and centroids() report it, the exports of A.19 publish it, and tests/test_cell.py verifies it lies inside its cell for every shape. The nucleus (the centre of the planar square) remains the indexing point and the point on the isolatitude rings.
A.28 area error budget	A declared cell-area error budget of at most 1% per grid.	Partial	area_error_budget() computes the budget; the per-resolution table is to be published on this page (v1.0).
A.29 equal-area cells	Cells in each grid are equal-area within the declared budget.	Met	Planar cell areas are exactly equal at each resolution, and the projection is equal-area onto the ellipsoid; verified by the area tests in the test suite (budgets published under A.28).

Planned work by release

• v0.9.0 — the zone-query interface is complete (intersects, crosses, distance, withinDistance, relativePosition, relatePosition, relate: #96; DE-9IM semantics for overlaps: #97) the centroid is the published representative position (#98), zones and query results export to GeoJSON and delimited text (#99), and the hierarchy predicates, zone-set operations and query attributes of Table 53 are in place (#161).

• v1.0 — finish this page’s remaining rows: CRS definitions (WKT2/PROJJSON) with epoch statement (#100), the zonal identifier grammar (#101), the published error-budget and maximum-resolution derivation (#102), GML export with its application schema (#103), and the formal reference-system declaration with the quantization and interoperation mapping documentation (#104).

Progress is tracked in the project’s GitHub milestones.