-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Storing Project QGZ in to geopackage does not store relative paths #32689
Comments
I confirm,
|
I also confirm |
There is some code in place to rewrite the (relative) paths when the project is stored in GPKG, so I guess this is a bug. Can you give us a step-by-step procedure to reproduce the issue starting from the creation of a new geopackage? |
a) I only move the geopack in a different folder on the same pc, b) If I move the geopack on another PC, and try to open the QGZ project inside the geopack, the error comes out, it does not locate the layers, because the previous absolute path is still registered, in the original carpets before the Geopack packaging. Annex link with images PS: I think I found another detail: if I open a geopack that also contains the QGZ project file, from a USB memory, the datat source browser does NOT show the QGZ file. |
Thank you for the detailed explanation, I would say the issue is with the package layer algorithm, but I'd like you to test another workflow:
How does it work? |
Ciao @elpaso I followed the whole workflow indicated, it seems to work, but if I move the database from which I took the two vectors also does not work. before moving the database (sqlite) from which I took the two vectors and put in the new gpkg: after moving the db sqlite and reloading the project from the geopackage gpkg:EDIT: |
@pigreco if the layer storage is filesystem-based and it's not in the same GPKG and you move (like your sqlite example) it, how is the project supposed to know the new location? Of course you get a broken layer. The issue we are (probably) facing here is different: what I suspect is that the "package layers" algorithm does not rewrite the layer paths to a relative location, because if you import the layers into the GPKG and the project is stored into the same GPKG, the layer relative path will be "./path_to_your.gpkg" and if you move it to another directory everything should be fine. |
Everything is always becoming more complex. My perception is that there are several situations that do not work well, and that came together.
2.1) If I move the geopack in another folder on the same PC, on the same hard drive (C :), the project opens, it works. But this is NOT because the code is correct, but the original shapes folders were not moved either. The QGZ project continues to register the absolute path of the hard disk, NOT the geopack. 2.2) If I move the geopack to another computer, on the main disk (C :), the project does NOT work. But I already expected it, because it is still looking for absolute paths as point 2.1 2.3) PS: if I move the geopack in a folder on another hard disk (D :) of the original PC (point 2.1) the browser panel does not display a QGZ file inside the geopack! It's like it's invisible! That happens with any hard drive / usb that doesn't have the letter (C :)
3.1) The only way I have found for a whole project to work within a geopack and move it, is that the layers have been imported from a geopack in to the project. That is, the layers must already be in a geopack, and then I import the project layers from there. But this presupposes a workflow not always possible. Any operation that is after, is not registered in the QGZ with the appropriate path. example:
Right now, everything works! You can move if problem, as mentioned by @elpaso in your previous message. But it has many limitations: 3.2) and raster layers, which are not included in the geopack to avoid blocking or lowering performance? I tried to leave them in the same geopack folder, but when moving the total project folder to another PC, it doesn't locate the raster (this raster path error does not occur when the QGZ has been saved as common in the main project folder I think it is an important detail to understand where the error may be generating) 3.3) I have tested a different logic, such as GeoDB. thanks for the patience |
Describe the bug
If I ask QGIS to save the project file in a Geopack (to create a portable package and share the entire project), the command is going to end, it works. But, it has no use, since this project file still points to the absolute locations of the project layers.
How to Reproduce
I present 2 situations, and none allows obtaining a complete geopack to share the project:
New clean project. I load several layers (from several carpets), then pack them in a new Geopack, save the project in the Geopack. When you move the Geopack, the project does NOT open. And it seems logical, because "nobody" told QGIS that the QGZ project must change the path of the layers.
Project "old" or already finished. The same applies to point 1. We can package the layers and the project in a new Geopack, but the QGZ project does not update the paths of the packaged layers.
The only ways I've found to get a Geopack Project to share or move, has been
pack layers in a new Geopack; open a clean project; load the layers of the Geopack, save the project inside the Geopack.
This works in terms of layers, but loses all the information of the general project (layout, views etc ..)
Manually change the "data source" of each layer, so that the QGZ project points to the path of the layers in the Geopack. It works, but it is not viable, being manual.
This happens with any type of layer, it is not a problem of specific layers. My Doubt is; is it a bug? Or is it a wrong idea of how the QGIS function "saves project in Geopack" works?
Thanks for the support
QGIS and OS versions
QGIS 3.10 Windows 10 64 bit
The text was updated successfully, but these errors were encountered: