Consider migration of Document and Layer instances into single Resource model

[mradamcox]

Background

Currently, the loc_insurancemaps app has a ResourceBase model that is inherited by the Layer and Document proxy models. Conceptually, this is still something of a holdover from the GeoNode CMS; even though GeoNode's Document and Layer models were replaced with my own here, to ease that transition I mimicked that CMS more closely than is really necessary going forward. In reality, the Layer model offers very little extra functionality over the Document model, so the functional need for these two different proxy models is dubious.

Further, the need to store a separate database instance for a Document alongside a Layer instance (which results directly from the process of georeferencing it, e.g. holds the GeoTIFF) doesn't really hold up under scrutiny. There is no functional reason these two instances can't be combined and reference the original map scan through one field and the resulting GeoTIFF in another field. Thus, each Document/Layer pair can and should ultimately be combined into a single new Resource instance.

Potential approach

• Create a new Resource model in the content app
• Add all necessary methods to support the current needs for Documents and Layers
• Reevaluate all attributes on the existing ResourceBase model
• Add field hold the original image file and a separate one for the GeoTIFF
• Take stock of where in the app existing Layer/Document functionality will need to be updated
  • For example, Volume().layer_lookup and Volume().document_lookup would now obviously be merged into something like resource_lookup and the Volume summary will need to handle this new lookup.
  • For the purposes of this ticket, just a research summary will suffice to complete this step

Additional context
Started this as an issue, but quickly decided to turn it into a Discussion. Although there is no question that this change will ultimately happen, I think there are still some unknowns that are worth more deliberation before jumping straight into this model's creation.

[mradamcox]

Another reconfiguration, currently better in my mind, is to have Resource and WarpedResource (inspired by rasterio's WarpedVRT). A Resource is the original image (an "unprepared" Document), and WarpedResource would combine pieces that are now stored separately in sessions... A division extent (or "mask", the area of the original image to be georeferenced) plus the GCPs to apply to that area. This implementation would also more closely reflect the structure of the IIIF spec's new Georeference Extension.

The preparation and georeference workflows would have to be altered a bit to implement this, and existing session data would need to be interrogated to create new WarpedResources to reflect all existing content, especially the association of divisions from prep sessions with the appropriate set of GCPs.

The big advantage this approach has is to begin incrementally moving away from the need to have individual files for each split piece of the original documents.

[mradamcox]

• Item: catalog record, analogous to current Volume
• Resource: scanned document, analogous to current Sheet
• PreparedResource: piece or whole of resource, analogous to current Document
  • relates to one Resource
  • holds division boundaries
  • provides for the fact that some divisions of a sheet will never be georeferenced, but should be given categories and be easy to access
• WarpedResource: analogous to current Layer
  • relates to one PreparedResource
  • holds GCPs, also could hold trim boundary, attributes include geotiff file?
• Perhaps better: VirtualResource to unify the PreparedResource and WarpedResource models described above.

[mradamcox]

Though the details had evolved beyond what is described above, the whole discussion was ultimately implemented through #212 and #217, now merged into main and fully deployed.