Create Map Layer Groups to better organize the overlays (and basemaps)

[mradamcox]

Is your feature request related to a problem? Please describe.

Currently, all overlays are placed in the same menu. This means that if I have loaded a bunch of historical map overlays, they are in amongst the Resource geometry overlays, and they can easily get stacked up on top of them:

Resource feature overlays are at the bottom here.

While adding the ability to set the order of these layers is already in progress: https://github.com/archesproject/arches/issues/8928, there was also talk on the forum of making it possible to group layers: https://community.archesproject.org/t/default-order-of-map-layers/1680/7?u=adamcox. This ticket is much more to address the latter, but they are both related.

Describe the solution you'd like

I think a nice way to handle this would be a slight refactor of how the layers are stored and presented. This would keep default Arches looking and functioning exactly the same, but add a lot more flexibility. (Note: Nothing would change about the Filter and Legend buttons.)

Backend:

1. Create a new model, MapLayerGroup, and use a foreign key on each MapLayer object to connect it to a group instance.
2. MapLayerGroup should have at least sortorder (int) and active (boolean) attributes, radio (boolean, True for Basemaps, for example), and perhaps others (displayname, icon, etc)
3. Three MapLayerGroups should be created by default
   • Basemaps -- the default streets and satellite layers would be assigned to this group
   • "Resource Layers" (or something to that effect) -- the auto-generated resource geom layers assigned to this group
   • Overlays -- By default this should be set active = False and be empty. Essentially, this would be a placeholder to provide an easy target for custom layers that people want to upload.
4. A developer could also create as many new groups as desired.
5. Presumably, permissions could be attached per-group as well.

Front-end:

The display wouldn't need to change significantly, but layers would be provided to the front end by group (if group.active == True), and new each group would get its own button, like Basemaps and Overlays currently have. If a developer created a new MapLayerGroup instance "Historic Maps", a new button would appear with that name in the side bar, and any MapLayers assigned to that group would appear in the menu list when opened.

---

This is just a draft idea, but I wanted to provide enough details to make what I have in mind as clear as possible.

Describe alternatives you've considered

Altering the MapLayer model to just have a category field that is a "dropdown" and not a reference to an entirely new model (MapLayerGroup) could accomplish some of what this ticket is after, but would quickly hit more walls when it comes to extensibility. Also, it would be more difficult to show/hide an entire group from the display.

Also, more complex grouping within the Overlays tab could be achieved as well with more complex iterations in the knockout component. Again, this would lead to a longer and longer list of layers in a single menu, while empty real estate remains in the map widget right toolbar (see all the space under the legend button above.

Additional context

The underlying goal here is to increase modularity and extensibiity. Currently, forcing all overlays into the same scroll menu can quickly become cumbersome, and while there are plenty of workarounds possible for this, I think the