improve the Metadata Viewer app
As discussed with @Benjamin Jakimow .
Since the GDAL Metadata widget in the Layer Properties is not allowed to manipulate the raster source (see #1101), the current Metadata Viewer in the Tools menu should be improved:
- new name “GDAL Metadata Editor”
- don’t select a layer, but a source. Use the same logic as the Raster Source Band Properties app. Check if the source is already opened in the QGIS Project:
Comments (18)
-
-
The source could be opened by a none-QGIS process as well. Checking QGIS layers only is not enough.
-
reporter That is always true, but we don’t care. We only make sure, that the QGIS Project is not blocking the layer. That was the team decision on how to deal with it.
-
Long-time running QgsProcessingTasks might block the GDAL source layer as well.
-
reporter Long-time running QgsProcessingTasks might block the GDAL source layer as well.
I don’t understand what you mean. Please give an example.
-
FYI: The relevant lines from qgsgdaldataprovider.cpp ~QgsGdalProvider:
if ( mGdalDataset ) { // Check if already a PAM (persistent auxiliary metadata) file exists QString pamFile = dataSourceUri( true ) + QLatin1String( ".aux.xml" ); bool pamFileAlreadyExists = QFileInfo::exists( pamFile ); GDALClose( mGdalDataset ); // If GDAL created a PAM file right now by using estimated metadata, delete it right away if ( !mStatisticsAreReliable && !pamFileAlreadyExists && QFileInfo::exists( pamFile ) ) QFile( pamFile ).remove(); }
As far as I understand this, the PAM file is removed only if not existing before closing the GDAL data set handle.
-
@Andreas Janz do you have a python snippet that reproduces the problem why we don’t want to edit GDAL metadata if GDAL files are alreay opened in QGIS?
-
reporter Not sure why you are asking that question.
It was you who insisted on not editing a raster source, when it is already opened as a layer in the QGIS Project.
Your main argument was: “bad things will happen” .
I even changed my “Raster Source Band Properties” app, which was already capable of editing the raster source of a layer.
-
I think the major reasons for changing the app from “Editor” to “Viewer” were, that it was expected to edit ENVI hdr files and is was based on using gdal in mode (which fails if the file is locked by another process).
I’ll investigate these potential problems a bit more. A solution that allows to manipulate GDAL Metadata without closing all raster layers first should be generally the prefered one.
-
- changed status to open
-
reporter A solution that allows to manipulate GDAL Metadata without closing all raster layers first should be generally the prefered one.
As mentioned, I already had such a solution implemented. You insisted on removing it
In my previous implementation, I disconnected the source from all layers, edited the source, and reconnected the source. Worked fine, but you said, that this is behaviour that will confuse the user. The team agreed on that and I changed everything.
I would suggest to not make a “Rolle rückwärts” now.
-
How can you disconnect layers which you don’t get a handle on?
-
-
reporter How can you disconnect layers which you don’t get a handle on?
We only care about QGIS Project layer.
We don’t care about other stuff, eg. e.g. the VRT is edited in Notepad++, or the GTiff is overwritten by ENVI Classic. A user can always do stupid things. We only care about sources owned by QGIS Project.
That was what we agreed in the team. Let’s stick with it.
-
addresses
#1102→ <<cset 966a75ffbe90>>
-
- changed status to resolved
-
- changed status to open
-
- changed status to closed
- Log in to comment
resolves
#1096, closes#1088, addresses#1095, resolves#1101, addresses#1102→ <<cset 80696482d3e2>>