search

WorldWideTelescope / wwt-web-client

The WorldWide Telescope web client lets you explore the universe in your browser.
https://worldwidetelescope.org/webclient/
MIT License
104 stars 35 forks source link

Web client fails to find AVM #366

Open keflavich opened 2 months ago

keflavich commented 2 months ago

This file has embedded spatial AVM: https://www.dropbox.com/scl/fi/ak62bm1nrot6k6h4122yk/BrickJWST_1182p2221_466_444_405.png?rlkey=lzoye1j98v2z47wxeukrrm8xt&dl=0

but WWT doesn't recognize it. I also tried through the desktop client. What is missing? I embedded using pyavm.

pkgw commented 2 months ago

If you're trying to open an AVM image in the webclient, there's C# code on the server side that deals with parsing the AVM:

https://github.com/WorldWideTelescope/wwt-website/blob/master/src/WWT.Imaging/VampWCSImageReader.cs

(invoked from https://github.com/WorldWideTelescope/wwt-website/blob/master/src/WWT.Providers/OtherProviders/TileImageProvider.cs)

The implementation is pretty simplistic. Looking at your file, the problem seems to be that the AVM lists are encoded with rdf:Bag elements rather than rdf:Seq as expected by the C# code.

Looking at the standard, I think that this is incorrect output. Which would make semantic sense, since a "bag" is presumably an unordered collection while a "seq" is presumably ordered, and for these parameters, ordered would be correct.

Tracing into PyAVM, I think we have a bug! Filed as https://github.com/astrofrog/pyavm/pull/44

Hopefully it should all work if you apply the (three-letter) patch in that PR, or you could manually hack up your file. I would prefer not to patch the server-side to try to handle this mistake unless it turns out to be prevalent in the wild.

keflavich commented 2 months ago

Thanks! That should solve my issue; I'll test today.