Use-cases for the healpix dimensions include creating HiPS images and healsparse property maps, which would at least ideally run via quantum with healpix dimensions and produce outputs with healpix dimensions.

Basic healpix support on DM-33946 won't be enough, because that just brings healpix to the level of support of our current HTM dimensions, and we can't really use those for anything other than prerequisite inputs, either.

We also have many more use cases where we are using tract or patch in contexts where we really want a tessellation with no overlaps, and any skypix dimension would be preferable if they were fully usable.

The fundamental problem here is that Registry data ID queries can't yield rows with skypix dimension columns (except, in special cases, the "common" htm7 dimension) because the database doesn't have any tables with those dimensions besides the ones that hold existing datasets.  As a result, we can query for existing datasets with skypix dimensions - inefficiently, by using sphgeom to project other-dimension regions to skypix IDs and then querying for those IDs, one at a time.  But the query system needs major upgrades to do anything else.

We have tables in the schema already that could solve this that are largely going unused, by storing explicitly-materialized overlaps between specific skypix dimensions and other spatial dimensions.  I'll be working on including those in the query system on DM-31725.