Make the Cesium Map models, views, & collections more modular

[robyngit]

As we plan to introduce numerous features to our Cesium map, it has become clear that our current structure could be improved so that it scales better with this complexity. This issue came up while working on the DrawTool feature, which requires a different action when the map is clicked.

The aim of this issue is to make some small improvements to the models, views, & collections that comprise the Cesium map to allow easier integration of new features and make the code more maintainable.

Some specific improvements could include:

1. Create a MapInteraction Model: Move attributes like currentScale, currentViewExtent, mousePosition, etc., into a new MapInteraction model to decouple these from the main map model. This will allow us to handle different kinds of interactions without bloating the main map model.

2. Introduce GeoPoint and GeoBoundingBox Models: Factor out redundant code into new models such as GeoPoint and GeoBoundingBox. These models can handle operations related to geographical points and bounding boxes, making the code more DRY.

3. Refactor CesiumWidget View Methods: The methods in the CesiumWidget view should be made smaller and more modular to increase readability and testability. Each method should have a single responsibility and should be easy to understand.

[robyngit]

The MapInteraction, GeoPoint, and GeoBoundingBox models have been created, and the CesiumWidgetView has been somewhat improved. Since the initial work on this originated during the development of DrawTool (#2180), ongoing work is being committed to the feature-2180-draw-on-map branch.

Remaining Tasks:

• Write tests for new models.
• Update tests for existing models & collections where attributes or functionality have moved.
• Address minor fixes related to feature selection.
• Resolve issues with rendering selected features.
• Thoroughly test changes in:
  • PDG production portal
  • ADC catalog
  • DRP catalog
  • DRP portal

Ideas for Further Improvement

While the current refactoring addresses immediate concerns, here are additional considerations that could either be implemented in this iteration, moved to separate issues, or passed on (to consider):

1. Refactor CesiumWidgetView into Sub-Views:

   • CesiumAssets view could manage rendering MapAssets on the Cesium globe (e.g., layers and terrain).
   • CesiumCamera or CesiumNavigation view could handle zoom functionalities.
   • CesiumDataSourceView could encapsulate logic related to displaying CesiumDataSource data.

2. Leverage GeoBoundingBox Model: Use this new model in the spatial filter to simplify logic around updating the spatial filter when the map position changes. (Also for the homePosition attribute on the Map model)

3. Introduce a BoundedGeohashes Model: This model could contain a bounds attribute and a geohashes attribute. Updating the GeoBoundingBox model on the bounds attribute could automatically trigger an update to the Geohashes collection.

[robyngit]

Other ideas for further improvement:

• use the GeoPoints collection as well as the Geopoints-Polygon connector in the Geohash model to handle creating entities (see Enable drawing arbitrary polygons on the Cesium map #2180)
• Create Geohashes in the coordinates provided by the ngeohash library. Let Cesium handle converting to ECEF, remove that library
• Move logic around creating CZML to it's own model