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

Storing Project QGZ in to geopackage does not store relative paths #32689

Open
bellanz80 opened this issue Nov 6, 2019 · 8 comments
Open

Storing Project QGZ in to geopackage does not store relative paths #32689

bellanz80 opened this issue Nov 6, 2019 · 8 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Project

Comments

@bellanz80
Copy link

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:

  1. 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.

  2. 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

  1. 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 ..)

  2. 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

@bellanz80 bellanz80 added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Nov 6, 2019
@pigreco
Copy link
Sponsor Contributor

pigreco commented Nov 6, 2019

I confirm,
the above problems.

  • in the geopackage: data and project

testDataPlotly.zip

@Korto19
Copy link

Korto19 commented Nov 7, 2019

I also confirm

@elpaso
Copy link
Contributor

elpaso commented Nov 7, 2019

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?

@gioman gioman added the Feedback Waiting on the submitter for answers label Nov 7, 2019
@bellanz80
Copy link
Author

bellanz80 commented Nov 7, 2019

  1. I create a new clean project. Annex 3 vector layers of some folders on my hard drive.
    The first layer is contained in a Geopack (Naural Earth), the other 2 from shape files of 2 different folders

  2. I save the QGZ project in a folder on my computer. And I continue working, modifying and simulating the use of the project.

  3. Once the project is finished, I use the geoprocess "Package layers", and create a new Geopack that saves the vectors and their styles. The process ends with success.

  4. Now I need to share this entire project with another user on another computer. I keep the QGZ project in the same Geopack that contains the vector layers (point 2). Do not get any message that says the process is finished, but if I enter the geopack you see the QGZ file

  5. Now I have 2 situations, but both are wrong.

a) I only move the geopack in a different folder on the same pc,
I open QGIS, and through the data source manager, I look for the Geopack. I unfold the content, and double click on the QGZ file
The project opens, but the layers are reading them with the old paths, NOT the geopack.

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.
Thank you very much

Annex link with images
https://docs.google.com/presentation/d/1AvdIelCtewhIT7cDmfcbr06wqZjrNz2nzhCZX5QI9Ek/edit?usp=sharing

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.

@elpaso
Copy link
Contributor

elpaso commented Nov 8, 2019

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:

  • create a blank project
  • create a new geopackage
  • drag and drop your vector layers (shapefile, PG etc.) into the newly created gopackage
  • store the project into the geopackage
  • save the project
  • exit QGIS
  • move the geopackage to another directory
  • open QGIS
  • from the browser open the geopackage and load the project stored inside it

How does it work?

@elpaso elpaso changed the title Project QGZ in to geopack does not work as it should Storing Project QGZ in to geopackage does not store relative paths Nov 8, 2019
@pigreco
Copy link
Sponsor Contributor

pigreco commented Nov 8, 2019

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:

image

after moving the db sqlite and reloading the project from the geopackage

image

gpkg:

TEST_QGZ.zip

EDIT:
Sorry @elpaso
my mistake.
I redid the flow you suggested more carefully, it works!

@elpaso
Copy link
Contributor

elpaso commented Nov 8, 2019

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

@bellanz80
Copy link
Author

bellanz80 commented Nov 8, 2019

Everything is always becoming more complex. My perception is that there are several situations that do not work well, and that came together.

  1. The Package layer works. Nothing changes, really, if the shape layers are inserted with drag-drop or with the "package layers" process. The problem is in the QGZ file, which keeps looking for the layers in the absolute paths.

  2. I have followed the steps mentioned, and what was already waiting for me happened.

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
Anotación 2019-11-07 152353

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 :)
error_disco

  1. At this moment I would like to make some considerations, because I cannot understand what the original idea behind the process that keeps the QGS project in a geopack was.

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:
-I create a new project
-I create an empty geopack
I import layers to the geopack (drag / drop or package layers, it's the same)

  • close QGIS
    -opens QGIS a new project
  • I load all layers from the geopack created before
    -save the project in geopack

Right now, everything works! You can move if problem, as mentioned by @elpaso in your previous message. But it has many limitations:
-No project in progress or already completed can be "converted" to the geopack
-any layer that is attached later is not later located by the project.

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.
-new project
-I create a geopack
-except the QGZ inside the new geopack, without any layer.
-rock and open QGIS
-open the empty project of the geopack, as if it were a template
-I import layers and work.
-pack the layers in the initial geopack
-move the folder
It does not work. Although the layers are imported into the project's geopack, the paths do not change.

thanks for the patience

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Project
Projects
None yet
Development

No branches or pull requests

5 participants