improve the Metadata Viewer app

[Andreas Rabe]

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:

‌

‌

‌

[Benjamin Jakimow]

resolves #1096, closes #1088, addresses #1095, resolves #1101, addresses #1102

→ <<cset 80696482d3e2>>

[Benjamin Jakimow]

The source could be opened by a none-QGIS process as well. Checking QGIS layers only is not enough.

[Andreas Rabe]

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.

[Benjamin Jakimow]

Long-time running QgsProcessingTasks might block the GDAL source layer as well.

[Andreas Rabe]

Long-time running QgsProcessingTasks might block the GDAL source layer as well.

I don’t understand what you mean. Please give an example.

‌

[Benjamin Jakimow]

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.

[Benjamin Jakimow]

@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?

[Andreas Rabe]

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.

[Benjamin Jakimow]

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.

[Andreas Rabe]

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.

[Benjamin Jakimow]

How can you disconnect layers which you don’t get a handle on?

[Benjamin Jakimow]

related issues: #243 #547

[Andreas Rabe]

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.

[Benjamin Jakimow]

addresses #1102

→ <<cset 966a75ffbe90>>

[Benjamin Jakimow]

follow up in https://github.com/EnMAP-Box/qgispluginsupport/issues/7