Add GeoJson as source for CesiumCartographicPolygon

[gojushin]

Description

This PR introduces efficient cutouts using .geoJson files.

It builds on the functionality introduced in this PR and primarily extends CesiumCartographicPolygon to support loading a Spline Component from a .geoJson file.

Using CesiumCartographicPolygon instead of CesiumGeoJsonDocumentRasterOverlay for hiding the tiles has a significant advantage: tiles that are fully contained within the polygon are not just visually hidden, but are never loaded in the first place, resulting in a net performance improvement in these scenarios.

While implementing this feature, I realized it would be beneficial for the workflow to support both directions ( .geoJson ↔ Spline)... So I also added the ability to export Splines as .geoJson files, allowing them to be further integrated into the Cesium ecosystem. This can however be easily taken out again, if the functionality is undesired.

Issue number or link

This implements the functionality discussed here:
https://community.cesium.com/t/introducing-efficient-geojson-cutouts/46510

Author checklist

• I have submitted a Contributor License Agreement (only needed once).
• I have done a full self-review of my code.
• I have updated CHANGES.md with a short summary of my change (for user-facing changes).
• I have added or updated unit tests to ensure consistent code coverage as necessary.
• I have updated the documentation as necessary.

Remaining Tasks

None

Testing plan

I tested my changes using .geoJson files created in QGIS for each of the 3 new modes (FromDocument, FromURL and FromIon).
The .geoJson Writing has been tested by opening it in QGIS.

[j9liu]

Thanks for the PR @gojushin! Confirmed that we have a CLA from you on hand, we'll take a look at this when we get the chance. 🙏

[j9liu]

Sorry for the delay on this @gojushin! Thanks for following our PR checklist thoroughly by updating the changelog/unit tests 🙌

I have a few things to discuss before we merge -- let me know your thoughts!

Hardcoded polygon access in GeoJSON

Currently there's assumptions made about the structure of the GeoJSON in order to extract a usable polygon ring. It basically defaults to the first one it can find -- which is not a bad solution, but I think it offers less flexibility as a result of being hardcoded.

            else if (objType == CesiumGeoJsonObjectType.FeatureCollection)
            {
                CesiumGeoJsonFeature[] features = obj.GetObjectAsFeatureCollection();
                if (features == null || features.Length == 0)
                    return null;
                geometry = features[0].GetGeometry();
            }


            if (geometry == null)
                return null;


            CesiumGeoJsonLineString[] rings = null;


            CesiumGeoJsonObjectType geometryType = geometry.GetObjectType();
            if (geometryType == CesiumGeoJsonObjectType.Polygon)
            {
                rings = geometry.GetObjectAsPolygon()?.rings;
            }
            else if (geometryType == CesiumGeoJsonObjectType.MultiPolygon)
            {
                CesiumGeoJsonPolygon[] polys = geometry.GetObjectAsMultiPolygon();
                rings = polys?[0]?.rings;
            }

I don't want this to be a deal breaker, just wondering if there's any way to improve this. Otherwise we'll have to be sure to note this assumption in the documentation.

Saving polygon assets

There are implications with streaming Cesium ion assets -- given that access can be dynamic due to creating/revoking new access tokens, I don't know if it's right for us to allow users to save assets that they stream in. GeoJSONs can be potentially loaded as Cesium ion assets using an ion asset ID and token.

With that in mind, let's remove the save-to-disk functionality for now. If it ends up being okay after all, then I'll leave a comment for it and we can do a follow-up PR. But I think it will be unlikely. Sorry about that!

[gojushin]

@j9liu

Regarding the assumption of the first ring:

That's defined as per RFC7946 spec:

For Polygons with more than one of these rings, the first MUST be
the exterior ring, and any others MUST be interior rings. The
exterior ring bounds the surface, and the interior rings (if
present) bound holes within the surface.

And the exterior ring is usually what we assume for cutouts.
I believe that is also how it is currently done in CesiumJS when we load a geojson as ClippingPolygon (please correct me if I am wrong!!) - although there the holes DO remain accessible as an array of arrays.

It would ofc be easy to expose an index.

OR do it the same way CesiumJS does! (exposing holes as extra field https://cesium.com/learn/ion-sdk/ref-doc/ClippingPolygon.html)
CesiumCartographicPolygon feels like the right place to add this.

Going into the future I would in any case attempt to go down the route of introducing ClippingPolygonCollection's. Which this should be a neat foundation for ^^.

As for saving geojsons to disk:

We can remove that ^^ Was only a suggestion :P.

Let me know what you can think! I can do the required refactoring around mid next week.