Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show user-friendly explanation if las/laz files cannot be used on their QGIS install #41927

Merged
merged 4 commits into from Mar 1, 2021

Conversation

nyalldawson
Copy link
Collaborator

Add API to QgsProviderRegistry to obtain user friendly warning messages
for when a URI cannot be opened in a QGIS install, but the URI
matches a format which could potentially be opened in a different QGIS
install.

This can be used to show user-friendly warning messages advising user why
a particular uri cannot be opened on their QGIS install. For example, if
a QGIS install is built without the PDAL library then las/laz files are
unusable, and this method can be used to retrieve a user-friendly warning
as to why the las/laz files cannot be used on their QGIS build.

Instead of just showing the user a generic "not a valid or recognized data
source" error, we can use this api to show more helpful URIs about the
specific uri.

Initially implemented to help advise users why LAS/LAZ files cannot be
opened on their QGIS install, but also could be used e.g. by mdal
to advise users about missing third party libraries preventing
them from opening certain mesh files, etc.... (cc @PeterPetrik @vcloarec @wonder-sk )

for when a URI cannot be opened in a QGIS install, but the URI
matches a format which could potentially be opened in a different QGIS
install.

This can be used to show user-friendly warning messages advising user why
a particular uri cannot be opened on their QGIS install. For example, if
a QGIS install is built without the PDAL library then las/laz files are
unusable, and this method can be used to retrieve a user-friendly warning
as to why the las/laz files cannot be used on their QGIS build.

Instead of just showing the user a generic "not a valid or recognized data
source" error, we can use this api to show more helpful URIs about the
specific uri.

Initially intended to help advise users why LAS/LAZ files cannot be
opened on their QGIS install, but also could be used e.g. by mdal
to advise users about missing third party libraries preventing
them from opening certain mesh files, etc....
@github-actions github-actions bot added this to the 3.20.0 milestone Mar 1, 2021
Copy link
Contributor

@PeterPetrik PeterPetrik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@nyalldawson nyalldawson merged commit 96fd952 into qgis:master Mar 1, 2021
@nyalldawson nyalldawson deleted the pdal_warn branch March 1, 2021 08:14
github-actions bot pushed a commit that referenced this pull request Mar 1, 2021
Show user-friendly explanation if las/laz files cannot be used on their QGIS install
@wonder-sk
Copy link
Member

Thanks a lot Nyall!

nyalldawson added a commit that referenced this pull request Mar 2, 2021
Show user-friendly explanation if las/laz files cannot be used on their QGIS install
@Houska1
Copy link
Contributor

Houska1 commented Mar 2, 2021

@nyalldawson I realize this has been created with the pdal issue in mind and las/laz files. But can this also be used when providers fail to load files due to their own missing dependencies upstream?

I just tried using the new OSGeo4W "testing" installer, and QGIS choked on a number of .tifs in my existing projects. Turns out its gdal 3.2 is complied without internal libtiff and so is missing the LERC (de)compression codec which is present in the old build's gdal 3.1.4. I've opened an OSGeo4W ticket for this specific build issue (https://trac.osgeo.org/osgeo4w/ticket/663) but it's made me realize QGIS' error messages are much less informative in the "Keep unavailable layers" dialog at startup, and when asking for layer properties in the Browser, than when adding a new layer to the layer tree (when it at least passed on the gdal "missing CODEC" error message).

Seeing this made me wonder whether this API could be used in such instances too, when it's not the file type per se which is unsupported due to not being compiled in to QGIS itself, but something about a specific file which makes the provider choke?

@nyalldawson
Copy link
Collaborator Author

@Houska1

But can this also be used when providers fail to load files due to their own missing dependencies upstream?

Yes, totally! (That's why I kept the API as generic as possible)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants