The PROJ implementation of S2 supports cutting cell boundaries using a lat/lon -> XYZ mapping that accounts for the difference between geodetic and geocentric lat/lon coordinates on general ellipsoids. While this is mostly irrelevant for storage of vector data (point clouds, polygons, etc), it is quite helpful in minimizing length-distortions when warping raster data into S2 coordinates to cleanly slice along S2 cell boundaries.
The existing implementation of S2Cell.js in CesiumGS/cesium can be made to emulate this behavior by replacing the two instances of Ellipsoid.UNIT_SPHERE with new Ellipsoid(1.0, 1.0, ellipsoid.minimumRadius / ellipsoid.maximumRadius).
Presumably a similar change can be made in CesiumGS/cesium-native, although I am less familiar with that codebase.
However a more desirable solution would be for this extension to define a setting to allow the aspect ratio of Cesium's planetary ellipsoid (typically WGS84) to be used in place of the unit sphere for calculating lat/lon -> XYZ conversions.
The PROJ implementation of S2 supports cutting cell boundaries using a lat/lon -> XYZ mapping that accounts for the difference between geodetic and geocentric lat/lon coordinates on general ellipsoids. While this is mostly irrelevant for storage of vector data (point clouds, polygons, etc), it is quite helpful in minimizing length-distortions when warping raster data into S2 coordinates to cleanly slice along S2 cell boundaries.
The existing implementation of S2Cell.js in CesiumGS/cesium can be made to emulate this behavior by replacing the two instances of
Ellipsoid.UNIT_SPHEREwithnew Ellipsoid(1.0, 1.0, ellipsoid.minimumRadius / ellipsoid.maximumRadius).Presumably a similar change can be made in CesiumGS/cesium-native, although I am less familiar with that codebase.
However a more desirable solution would be for this extension to define a setting to allow the aspect ratio of Cesium's planetary ellipsoid (typically WGS84) to be used in place of the unit sphere for calculating lat/lon -> XYZ conversions.