rHEALPixDGGS-py implements code to both define an rHEALPix DGGS Reference System and to perform topological queries on its Identfiers. Our roadmap is for v1.0 to be fully compliant with OGC Topic 21 v2.0 / ISO 19170-1:2020.
Occasionally a computed cell vertex would be up to 1e15 outside the cell. This was allowed for by expanding the rhealpix/healpix boundary vertices by (eps = 1e15) in the in_rhealpix_image test. But the test for applying combine_triangles in rhealpix didnt accomodate a +-eps dither in coordinate values. combine_triangles() cannot know the origin of the coordinate it is testing, but cell.vertices() & cell.boundary() already know the region of the cell that owns the coordinates. So adding cell.region() as an optional argument to the rheal[ix transformation functions, allows vertices() & boundaries() to force the combine_triangles() behaviour to follow the cell, not the individual coordinates. This has been tested for cells with all 0s, 1s, 2s, 6s, 7s, or 8s on faces OPQR. ie equatorial cells with a northern or southern border on the edge of the equatorial region.
Occasionally a computed cell vertex would be up to 1e15 outside the cell. This was allowed for by expanding the rhealpix/healpix boundary vertices by (eps = 1e15) in the in_rhealpix_image test. But the test for applying combine_triangles in rhealpix didnt accomodate a +-eps dither in coordinate values. combine_triangles() cannot know the origin of the coordinate it is testing, but cell.vertices() & cell.boundary() already know the region of the cell that owns the coordinates. So adding cell.region() as an optional argument to the rheal[ix transformation functions, allows vertices() & boundaries() to force the combine_triangles() behaviour to follow the cell, not the individual coordinates. This has been tested for cells with all 0s, 1s, 2s, 6s, 7s, or 8s on faces OPQR. ie equatorial cells with a northern or southern border on the edge of the equatorial region.