how to handle data sources that are updated/overwritten on disk

[Andreas Janz]

Let's assume we have a raster named "classification.bsq" opened in the Box and visualized in a MapView.

If an HUB Workflow algorithm overwrites the "classification.bsq" raster, the data source is correctly re-opened in the Box (I guess because of the signal emitted by HUB Workflow).

Problem is: the MapView still displays the old "classification.bsq" raster.

Solution: when re-opening a data source, the old data source should be removed from all MapViews.

The same should happen for Spectral Libraries that are overwritten on disk.

[Benjamin Jakimow]

Datasets which are in use by other processes which expect they are still there, e.g. for visualization, processing, etc., should not get overwritten at all.

I thinks it's better (and much easier) to implement a signal that signalizes updates of known datasource by comparing file creation dates. Doing so for spatial datasources could then trigger QgsMapLayer.reload() to make data changes visible but keeping existing render styles etc. This works for QgsVectorLayer, but not QgsRasterLayer. At least not in Python API, where QgsRasterLayer::update() is not accessible.

[Benjamin Jakimow]

closes Issue #175 adding DataSources with newer modififcation date will remove older ones before refactoring

→ <<cset 1f93ab13547e>>