Describe the problem
I found an example last night as follows: A sheet had been split into four pieces, but two were undesirable artifacts from the process (due to a messy cut-line). To fix this I un-georeferenced the two good pieces that had been georeferenced, and then un-prepared the parent sheet. This all seemed to go as desired. When I re-prepared the sheet, now splitting into 2 different pieces, this also seemed to work, at first. However, viewing one of the detail pages for the new pieces, the preview was distorted, and, similarly, the left side of the georeferencing interface was distorted. The problem seemed to be that the old dimensions for the previously split piece were somehow cached and being applied to the newly created piece. Especially puzzling was the fact that the actual file on disk for this piece wasn't distorted, it was fine, so it was just the image size that was stored in document.image_size (a @cached_property attribute) was not properly updated. This was especially confusing because these new pieces were completely new database objects, and, seemingly, the files had been properly regenerated.
Ultimately, with a lot of mucking around, I think I figured out that the old file pieces were still around in the file system, and they were causing problems. Also, the entries for the georeferenced layers in the MultiMask and in the "sorted_layers" key on the volume had not been removed (causing other issues).
Expected behavior
Undoing a preparation or georeferencing session should properly clean up ALL remnants of the old files.
To Reproduce
Steps to reproduce the behavior:
Split a document into multiple pieces
Georeference one of them
Trim the layer in the MultiMask
Undo all steps
Re-split the document into a smaller number of pieces
The image preview for the new pieces should look wrong, they should be expecting a file of the wrong dimensions.
Additional context
It would be good, especially to help with debugging and corrective measures, to change document.image_size from a cached property to a normal attribute on the model (I was never able to tell why exactly the old size was being reported, but this would just be a good thing to do). image_size should be set every time the document is saved (I don't think this would impact performance, because they aren't modified/saved especially often).
Additionally, the following must be addressed:
Ensure that undoing a split session fully removes the files from the system
Ensure that undoing a georeferencing session fully removes the files from the system (including .vrt files)
Ensure that undoing a georeferencing session removes all entries in the sorted_layers property
Ensure that undoing a georeferencing session removes all entries from MultiMask
Describe the problem I found an example last night as follows: A sheet had been split into four pieces, but two were undesirable artifacts from the process (due to a messy cut-line). To fix this I un-georeferenced the two good pieces that had been georeferenced, and then un-prepared the parent sheet. This all seemed to go as desired. When I re-prepared the sheet, now splitting into 2 different pieces, this also seemed to work, at first. However, viewing one of the detail pages for the new pieces, the preview was distorted, and, similarly, the left side of the georeferencing interface was distorted. The problem seemed to be that the old dimensions for the previously split piece were somehow cached and being applied to the newly created piece. Especially puzzling was the fact that the actual file on disk for this piece wasn't distorted, it was fine, so it was just the image size that was stored in document.image_size (a
@cached_propertyattribute) was not properly updated. This was especially confusing because these new pieces were completely new database objects, and, seemingly, the files had been properly regenerated.Ultimately, with a lot of mucking around, I think I figured out that the old file pieces were still around in the file system, and they were causing problems. Also, the entries for the georeferenced layers in the MultiMask and in the "sorted_layers" key on the volume had not been removed (causing other issues).
Expected behavior Undoing a preparation or georeferencing session should properly clean up ALL remnants of the old files.
To Reproduce Steps to reproduce the behavior:
Additional context
It would be good, especially to help with debugging and corrective measures, to change
document.image_sizefrom a cached property to a normal attribute on the model (I was never able to tell why exactly the old size was being reported, but this would just be a good thing to do).image_sizeshould be set every time the document is saved (I don't think this would impact performance, because they aren't modified/saved especially often).Additionally, the following must be addressed:
sorted_layersproperty