Loading of HiPS layers

[Carifio24]

This PR is, in some sense, the companion to https://github.com/WorldWideTelescope/wwt-webgl-engine/pull/178. It attempts to solve two main problems:

• Currently, image sets with the Healpix projection aren't loaded correctly from XML due to a missing case in the switch statement here. This PR fixes this by adding the appropriate case check.
• In order to correctly load HiPS layers (defined as Healpix projection + file extension .tsv), this PR modifies the client to create the image set from the HiPS url, as is done when adding a HiPS survey via Explore > Open > HIPS Progressive Survey. I did a bit of code refactoring to help with this.

From what I can tell, the UWP version of the client doesn't have support for Healpix tiles. To get around this, in ImageSetHelper::FromXmlNode, I wrapped the logic for creating an ImageSetHelper using HiPS properties in preprocessor directives so that it's omitted in UWP.

[pkgw]

Cool, from my testing it looks like this PR improves things and makes it so that the Windows client can successfully load HiPS-catalog tours produced by the web client.

I think that there is still an issue, though. In my testing, the web client doesn't correctly load HiPS-catalog tours created by the Windows client. For instance, here's a tiny tour created with the Windows client:

Original Windows Tour.WTT.zip

The first slide is two seconds of still camera with no extra layers showing, and the second slide is five seconds of panning with a HiPS catalog layer added. This fails to play back properly on the web client: the HiPS catalog layer never appears.

The issue seems to be that the Windows client is not assigning UUIDs to the HiPS catalog layers using the special V5 scheme used by the web engine. In this example, the UUID of the catalog tour layer is 0963e8e5-3c41-4b6b-8f7b-76e17678d466, while in the web engine scheme it should be 5d1fb63d-150b-56f7-8ff5-7e69f4573d30. This is a problem because at some point the web engine changes the UUID of the catalog layer to match its scheme, which breaks subsequent routines that decide whether to show the layer based on a UUID search.

If I edit the tour file to manually force the catalog layer UUID to agree with what's expected by the web client, it plays back correctly:

Fixed Windows Tour.WTT.zip

So I think the Windows client needs to also adopt the UUIDv5 scheme used by the web client, so that the files it produces will remain compatible. Do you think that would be straightforward to implement? I could also imagine a fix on the web side to rewrite UUIDs when loaded from tour files, but that feels like an inferior solution to me.

[Carifio24]

I was actually thinking earlier today about whether I would need to make changes here to keep layer IDs the same between the web engine and the Windows client. I agree that we should make the Windows client have the same UUID scheme as the web engine. I have a piece of C# code that implements v3 and v5 UUIDs (they're the same up to the hashing algorithm used to hash the name and namespace), so I don't think this will be too hard to do. I'll work on making that update.

[Carifio24]

I've added functionality for creating v3 and v5 UUIDs to the Windows client, and modified ImageSetLayer to use the appropriate v5 ID when the layer represents a HiPS catalog.

Using this, I was able to create a tour using a HiPS catalog in the Windows client, and load it up in the web client, and the layer displayed. The only thing I noticed was that the layer was turned off in the layer manager as soon as the tour ended. I'm not sure whether that's an expected behavior, or something that needs to be ironed out here.

[pkgw]

Cool! Looks like the build failed here because I need to recreate the custom builder VM image, as documented here. I'll do that.

[pkgw]

Build agent regenerated, I think. Closing and reopening to test ...

[Carifio24]

I've added a comment explaining where the namespace is, as well as the fact that the web engine uses the same namespace so that their UUIDs will be compatible.