[processing] Handle case of folder of shapefiles in build vrt alg #10083
Conversation
| #might be a shapefile loaded as a directory of shapefiles. We try to resolve the uri to a filepath | ||
| sourceParts = QgsProviderRegistry.instance().decodeUri('ogr', inFile) | ||
| if sourceParts.get("layerName"): | ||
| inFile = os.path.join(sourceParts.get("path"), sourceParts.get("layerName") + ".shp") |
There was a problem hiding this comment.
Won't this break if a geopackage layer (or similar) was loaded? In that case the layerName parameter will be present, but the file name generated here will be broken.
This is really quite tricky to handle -- I think we'd need a check in here to first see if sourceParts['path'] is actually a directory (and if not, there's nothing required). Then, if it IS a directory, we'd need to check inside that path for files which start with the layername and have known vector data format extensions (because the same situation may arise for say KML files), and use that to determine the actual name of the file. Or alternatively, maybe we could use OGR api to try to load the file using just the path and layername, and let it run whatever internal logic it has to resolve the layername to a file, and then retrieve this actual file name from the OGR layer...
There was a problem hiding this comment.
It wont actually break anything, since gpkgs dont work now. Any layer with a source that is not an actual filepath cannot be used with that algorithm at the moment. However, I agree that the trick i added is not very general and only fixes the case of shapefiles.
I improved it a bit and put it in a separate function in the processing.tools.vector module. From there, it can be moved to C++ if someone takes care of that.
Still, some cases are not handled. It works now for gpkgs, but as long as the layer is the only one in the gpkg file.
In short, it's an improvement over the previous status of the algorithm, but it wont work with all input layers, like other Processing algorithms do. Other algorithms might be affected of this issue, so it's worth checking and maybe adding a similar mechanism.
Agreed - we need a central method for handling this. Maybe in QgsOgrUtils.cpp? |
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
stale
bot
added
the
stale
nyalldawson
removed
the
stale
|
@volaya I've asked here https://lists.osgeo.org/pipermail/gdal-dev/2019-June/050380.html to see if there's a cleaner way we can approach this |
|
cool. Good idea. Let's wait to see what they say |
|
Feedback @rouault
|
| if os.path.exists(folder): | ||
| if os.path.isdir(folder): | ||
| for ext in QgsVectorFileWriter.supportedFormatExtensions(): | ||
| f = os.path.join(folder, "%s.%s" % (layerName, ext)) |
There was a problem hiding this comment.
| f = os.path.join(folder, "%s.%s" % (layerName, ext)) | |
| f = os.path.join(folder, "{basename}.{extension}".format(basename=layerName, extension=ext)) |
Just because ;)
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
stale
bot
added
the
stale
|
While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist. |
#fixes 21519
Description
If a shapefile (i.e /my/data/points.shp) was loaded by loading a directory of shapefiles, its source wont be the filepath, but instead a uri-like thing such as /my/data|layername=points.
Although that file can be read by the external tool that creates the virtual vector, that source string won't work. I added a patch to try to resolve the uri-like source to a regular filepath.
It's just a patch for this tool, but this might affect other tools as well (basically, all the ones with external apps, like SAGA, etc), which wont work with shpafiles loaded as part of a folder.
Ideally, there should be a method to resolve the source to a valid filepath if possible, but I couldnt find it. I am making the PR in any case, to get some discussion about this.
I will be happy to improve this if someone points me in the direction of such method of workflow, in case it exists.
Checklist
fixes #11111in the commit message next to the description[FEATURE]in the commit message[needs-docs]in the commit message and contain sufficient information in the commit message to be documentedscripts/prepare-commit.shscript before each commit