Map compilation architecture

[davenquinn]

A major "sleeper" need of the CriticalMAAS program is to manage arbitrary compilations of mapping data. Right now we manage each map separately, and have only the "carto" seamless compilation. Instead, we should be able to manage arbitrary compilations, for multiple purposes. These might include

• "Special" maps like surficial, tectonic, or soils maps
• Organizational compilations (e.g., all maps from the Utah survey)
• All maps from each TA1 team
• Maps with different levels of QC applied

Actually in this conception, each "level" of the Carto dataset would actually be a separate compilation.

The steps here, I think, would be something along these lines:

• Create a topology of map boundaries to generalize the solving of priority across all compilations (the algorithm would only need to traverse a graph rather than do spatial intersection queries)
• Soft deprecate the scale "large/medium/small/tiny" enumeration and replace it with the actual intended scale of the map
• Create carto compilations in this new system
• Create some sort of generalized table for caches, plus (optionally) a way to shard that table. This would replace the carto map tables

A few other considerations:

• Compilations could have scale and (if we were to allow multiple projections eventually) projection limitations. For example, a polar compilation could be stored in its native projection or Utah mapping could be stored in its state plane.
• Caching might have to be significantly revised

[davenquinn]

One increment along these lines:
Separate the rgeom field from the maps.sources. This would allow multiple sources to come from a single topological product.