Be consistent about using Ellipsoid.WGS84 in CzmlDataSource

[malaretv]

The current recommended path by maintainers to support non-wgs84 ellipsoids is to modify the Ellipsoid.WGS84 (see #11185 (comment) and #3543 (comment))
For CzmlDataSource this approach wasn't working because of the existence of Cartesian3 functions that default to other hardcoded WGS84 values if no ellipsoid is provided.

This change makes sure Ellipsoid.WS84 is explicitly passed to those function calls in CzmlDataSource.

[cesium-concierge]

Thanks for the pull request @malaretv!

• ✔️ Signed CLA found.
• ❔ CHANGES.md was not updated.
  • If this change updates the public API in any way, please add a bullet point to CHANGES.md.
• ❔ Unit tests were not updated.
  • Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

• Cesium Viewer works.
• Works in 2D/CV.

[malaretv]

Added tests that run successfully locally.
Not sure about the Travis CI errors

They seem unrelated to the tests

[ggetz]

Not sure about the Travis CI errors

We've seen this in this repo as well as others. The spin failure is from travis CI itself, not our CI scripts. The failure shouldn't affect the build state.

The failure in CI was due to a separate configuration change on our part, which has since been fixed. This should be resolved if you merge in main.

[ggetz]

Thanks for the PR @malaretv!

While this does certainly work around the issue when setting Ellipsoid.WGS84 to another value, the fix itself stops a bit short of remedying the situation such that its obvious via the API how this works with custom ellipsoids.

Consider this comment from #3543:

It might actually be a decent real solution to have Ellipsoid.default in addition to Ellipsoid.WGS84 and just have the former equal the latter by default. Then we use Ellipsoid.default everywhere we currently use Ellipsoid.WGS84.

Would you have any interest in adding Ellipsoid.default such that it can be used throughout the API in this manner?

[malaretv]

Thanks for the PR @malaretv!

While this does certainly work around the issue when setting Ellipsoid.WGS84 to another value, the fix itself stops a bit short of remedying the situation such that its obvious via the API how this works with custom ellipsoids.

Consider this comment from #3543:

It might actually be a decent real solution to have Ellipsoid.default in addition to Ellipsoid.WGS84 and just have the former equal the latter by default. Then we use Ellipsoid.default everywhere we currently use Ellipsoid.WGS84.

Would you have any interest in adding Ellipsoid.default such that it can be used throughout the API in this manner?

Certainly happy to at least take a look later this week and see the scale of work involved in adding Ellipsoid.default! This would definitely be a very helpful change for our usage of Cesium. Two big questions I have off the top of my head with a Ellipsoid.default solution are:

1. Will it work with Workers? Would need to go through the worker code and make sure there is nothing that could fall back to using Ellipsoid.default -- since Workers bundle their own subsets of Cesium any overriding of Ellipsoid.default would not translate to that environment.

2. There are other locations where there may be hardcoded WGS84 defaults. One certain case is in Cartesian3 below:
   

   cesium/packages/engine/Source/Core/Cartesian3.js

   Lines 895 to 899 in 9295450

   	const wgs84RadiiSquared = new Cartesian3(
   	6378137.0 * 6378137.0,
   	6378137.0 * 6378137.0,
   	6356752.3142451793 * 6356752.3142451793
   	);

FWIW, this pull request would still be required even with an Ellipsoid.default implementation -- I would just need to replace Ellipsoid.WGS84 with Ellipsoid.default. The key thing about this pull request is being explicit about the Ellipsoid used when calling Cartesian3.fromRadians() such that it doesn't fall back to the hardcoded values in Cartesian3 for wgs84RadiiSquared

[ggetz]

Certainly happy to at least take a look later this week and see the scale of work involved in adding Ellipsoid.default! This would definitely be a very helpful change for our usage of Cesium.

Understood! We would appreciate the contribution if you have the bandwidth! This would go a long way to improve usability and function for all those using CesiumJS for non-Earth cases.

Will it work with Workers? Would need to go through the worker code and make sure there is nothing that could fall back to using Ellipsoid.default -- since Workers bundle their own subsets of Cesium any overriding of Ellipsoid.default would not translate to that environment.

Good point. One solution would be to pass in the ellipsoid as a parameter to the workers. For example, createVerticesFromQuantizedTerrainMesh is already structured this way.

There are other locations where there may be hardcoded WGS84 defaults. One certain case is in Cartesian3 below

Agreed. We could build in pre-computed optimizations like this into the Ellipsoid object itself and compute on construction.

FWIW, this pull request would still be required even with an Ellipsoid.default implementation

Yep!

[cesium-concierge]

Thanks again for your contribution @malaretv!

No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

[ggetz]

@malaretv What's the latest on this? If there's no bandwidth for the larger fix right now, would you be able to merge in main and ensure CI is passing to get this merged?

[malaretv]

@ggetz I've merged in main, still get test errors seemingly unrelated to my changes. The errors seem to be 1) the spin issue that showed up before and 2) errors related to some CesiumTerrain requests timing out

As for the larger fix, indeed it was more than I could handle. I got a bit stuck trying to figure out how to best handle the hardcoded wgs84 defaults in Cartesian3.

[ggetz]

Thanks @malaretv, understood, no worries.

I restarted your build to confirm the issues were transient. Looks good now.

The last step here would be to update CHANGES.md with a summary of the fix.

[ggetz]

Thanks @malaretv!