Feature request #182
Deal properly with multiple raster drivers supporting the same format
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  Tim Sutton | ||
| Category: | Rasters | ||
| Pull Request or Patch supplied: | No | Resolution: | |
| Easy fix?: | No | Copied to github as #: | 10241 |
Description
The filelist is built by iterating over the driver list from the gdal driver manager. The following code in qgsrasterlayer.cpp is too simplistic:
// A number of drivers support JPEG 2000. Add it in for those.
if ( myGdalDriverDescription.startsWith("MrSID")
|| myGdalDriverDescription.startsWith("ECW")
|| myGdalDriverDescription.startsWith("JPEG2000")
|| myGdalDriverDescription.startsWith("JP2KAK") )
{
QString glob = "*.jp2 *.j2k";
theFileFiltersString += "JPEG 2000 (" + glob.lower() + " " + glob.upper() + ");;";
}
We also need a way for the user to specify which driver to use to open a jpeg 2000 file for instance.
From: William Kyngesburye To: [email protected] Date: Jul 7, 2006 11:49 AM Subject: [Qgis-developer] Problem with GDAL formats as plugins (This is a clarification on Greg's message in the qgis-user list) I have a few formats in my GDAL built as GDAL plugins, for various reasons. This includes GRASS (raster and vector), [[JasPer]] JP2, [[MrSID]], and a new Kakadu JP2 plugin. With all these enabled, when adding a raster, there are many JPEG2000 choices, and all except the first have the same menu text so I can't tell which is which. JPEG-2000 part 1 (*.jp2 *.JP2) JPEG 2000 (*.jp2 *.j2k *.JP2 *.J2K) JPEG 2000 (*.jp2 *.j2k *.JP2 *.J2K) [[MrSID]] [not the actual text, I just shortened it here] JPEG 2000 (*.jp2 *.j2k *.JP2 *.J2K) JPEG 2000 (*.jp2 *.j2k *.JP2 *.J2K) Disable [[MrSid]] and that drops to: JPEG-2000 part 1 (*.jp2 *.JP2) JPEG 2000 (*.jp2 *.j2k *.JP2 *.J2K) JPEG 2000 (*.jp2 *.j2k *.JP2 *.J2K) Disable Kakadu (just [[JasPer]] now), and the same 3 choices are available. Disable [[JasPer]] and enable just Kakadu, now there are no JP2 choices to load rasters. Enable just the [[MrSID]] plugin, and the [[MrSID]] and 2 JPEG 2000 items are available. Why is Qgis ignoring the Kakadu GDAL driver? I can't try this with Kakadu built into GDAL, only as plugin. The GDAL programs see and can use the Kakadu driver plugin just fine. Since only a few of the available GDAL formats are available in Qgis, it must be something programmed into Qgis? Why are all JP2 drivers shown (and with multiple menu items for each)? The only way I know of to choose an *input* format driver in GDAL is to set the GDAL_SKIP environment var to tell GDAL to ignore drivers. But maybe there is a way when using the libraries? This is with my Qgis Mac Universal build of 0.8 preview. Happens both on PPC and Intel Macs.
Associated revisions
[FEATURE] implement ability to skip specific drivers (fixes #182)
History
#1
Updated by Gavin Macaulay - about 18 years ago
As far as I can see, there is no easy way in the GDAL API to specify which driver to use to load a data source - it uses the first one in an internal list that fits, although drivers can possibly be removed from the list.
The qgsrasterlayer.cpp code has been modified since the problem reported above, and it no longer generates duplicated file filter lines for jpeg files in the 'open raster' dialog box.
Giving users the option of choosing which jpeg driver to use seems sensible, but is more of an enhancement in a future version of qgis.
#2
Updated by Tim Sutton over 17 years ago
- blocker - bugs that should block the release. Since we are going to release pretty much 'come what may' I would like no bugs
- allocated to this category without consultation with me and / or PSC
- critical - bugs that cause the application to crash or corrupt data
- major - application features that do not function at all
- minor - features that function but imerfectly e.g. labels placing incorrectly
- trivial - gui useability issues or small issues with the documentation, install notes etc.
#3
Updated by ersts - over 16 years ago
Tim
When multiple driver are available, GDAL uses the first successful driver. It is possible to deactivate drivers so I see a couple of options/enhancements
--When building the supported file list, put the names into a QMap<extension, description>, then only the first driver (which GDAL will use) will be displayed, this will also allow for the list to be sorted by extension so that it is more user friendly
--Add a raster driver tab to the "Settings->option" menu. This displays all possible drivers and the user can check which drivers to use (default to all on). Save these settings as QSettings
--QgsRasterLayer::registerGdalDrivers() will need to check the QSettings to see if the driver is listed for inclusion/exclusion, defaults to include
--Also means the supported file list will have to be generated each time the open dialog is open rather than once on initial load.
That should generally meet most of the needs/requests. Would be good to get Frank's opinion on this.
#4
Updated by Frank Warmerdam - over 16 years ago
It seems to me that the need to disable or otherwise mess with the list of registered drivers is fairly rare and esoteric. It can already be accomplished using the GDAL_SKIP environment variable. So I wonder if there is really a need to build dialogs for the user to control this.
I'm not too keen on the automatic population of the File Types list in the file selection dialog. The list is already so long and wide as to make the dialog quite unpleasant. I would instead suggest that it just be populated with a bunch of popular file types (dropping any out if that driver happens to be unavailable) rather than trying to comprehensively populate it.
However, the suggested approach with an options tab for disabling drivers would be quite plausible.
#5
Updated by Tim Sutton about 13 years ago
- Pull Request or Patch supplied set to No
- Status changed from Open to Closed
- Target version changed from Version 1.7.0 to Version 2.0.0
Closed with 9561c3d696d44b83b63e446d5701fc2ece2268e0
I have implemented a list widget in QGIS options dialog for (de)selecting which drivers to use. This is probably more pallatable for Windows / GUI inclined users who don't want to dig around with environment vars.
Regards
Tim