Compare Mode Tool - Include Support for Custom Layers

[jamesdoyle21]

User should have the option to see their custom layers with the slider

[ndellicarpini]

This is easy to do, but I really think we need to combine the layer settings & layer details into only a few objects before doing this. Currently in the compare tool (and many others), support for traffic light layers is hardcoded into the tool with basically no other way to do it because of the way we handle our layer settings. To add support for custom layers, all I would have to do is hardcode it in, which is easy.

This is going to bite us at some point if we don't figure this out soon, as the more layer types we support the more hardcoding we are going to have to do.

[mpiannucci]

Yeah, when you get a chance do you want to work up an example of what the proposed rafactor would look like?

[ndellicarpini]

I think we want to have 2 objects, an extended mapLayers and layerSettings, which would combine all of the wmsSettings, trafficLightLayers, scenarioLayers, etc. We get rid of all of the selectedCatalogItems and selectedTrafficLightLayers and just use the mapLayers to determine what is selected. I'm not really sure we should do with extents, maybe we make that a 3rd object?

For mapLayers I think we should add the following fields:

• name - just the name of the layer, this should really not be in the different settings objects anyhow
  • this would super simplify things like notifications, as nothing outside of mapLayers will be required to access
• time - the time the map layer is requested at
  • this would simplify things like the legend so that the nearest time extent doesn't need to be recalculated all of the time
• type - this will be good for layer sorting / compare tool / Permalinks, as we can filter layers by type a lot easier
  • these types wouldn't be things like "raster" or "line", it would be things like "WMS", "EDS", "Traffic", "Scenario", etc. (basically the source kinda)
  • one thing where this would be really useful is separating different types of raster layers. Right now an oil scenario is no different to the layer sorter than a regular waves layers.
• category - for layers from the catalog, it would be things like "Wave Predictions", otherwise it would basically be the type of layer
  • this would be most obvious in the legend, as it would be the rounded label on top of the legend item
  • this field would/should only be used for labels, type would be used for specific functionalities
• toUpdate - flag that should be set when something in the layer has changed that would required MapTwo to re-render the layer. Once Map has sent the refreshedLayers to MapTwo, this flag should be set to false
• updateOnChange - list of context variables that will be listened to and if change -> set toUpdate to true
  • I haven't figured out how exactly we'd do this, but it seems possible
  • this would handle things like updating on time change / updating on elevation change

Those are the main fields to add that would probably alone cut the requests to the different layer settings objects in half, as a lot of the time we are accessing those objects just to get like the name of the layer.

Here is my proposed layerSettings:

• layerID - layer that is related to the following settings
• update - the actual function that would update the maplayer (basically what each of the layer managers do)
  • there would be 1 layer manager rather than a bunch, with the update function calling setMapLayer
  • setMapLayer would update the mapLayers[layerID] toUpdate flag to true
• settings - this would be the settings object that we currently have, except it would support all of the different kinds (wmsSettings, trafficLightLayers, etc)
• defaultSettings? - might be too much stuff

Also, to avoid infinite render loops maybe we have another object called mapLayerKeys that works like selectedLayers? Or maybe you can call Object.keys(mapLayers) as a useEffect dependency idk

These are just preliminary thoughts on how we would simplify all of our different objects. I would love to bounce these ideas with everyone so that we can make sure all of our bases are covered

Some sort of abstracting of legend? (like title being default on there or something)

[mpiannucci]

This is a good start and lines up with how im thinking we need to move to start being able to rapidly add new types of letters without making the state bloat to be 10 gb or whatever