Bug report #17824
Absolute paths still being used in Qgis 2.18 (Previously #16242)
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Project Loading/Saving | ||
| Affected QGIS version: | 2.18.15 | Regression?: | No |
| Operating System: | Debian 9 | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | end of life |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 25719 |
Description
This problem was previously raised as #16242, and was declare to be resolved some months ago.
I have investigated following some updates filed to the closed bug #16242 and others and have found absolute paths in my project file when the setting in project properties is for a relative path.
The attached file is not a new project and has been through many different versions of Qgis including 2.99. One suggestion is that the software may not be converting existing absolue paths to relative when they exist in a project file.
<layer-tree-layer expanded="0" providerKey="ogr" checked="Qt::Checked" id="OSLocations20170617033602248" source="/home/patrick/Maps/Google Drive/NZ Rail Maps/Projects/OtagoSouthland/Main/OSLocations.shp" name="OSLocations">
It seems only layer-tree-layer keys have absolute paths, datasource keys have relative paths
There is also a reasonable question as to why the layer data is duplicated in two sets of keys which basically refer to the same layers. When manually editing project files this means two separate sets of keys have to be searched and edited.
History
#1
Updated by Steve Lowman almost 7 years ago
I just tried 'save as' to a different file name in the same folder for an existing large file with no absolute paths. It created 220 'source=' attributes in the <layer-tree-layer> keys. So, the problem seems to be not just about existing absolute paths.
Can we make this a High priority Regression bug please; it seems to be one of those.
#2
Updated by Alessandro Pasotti almost 7 years ago
- Assignee set to Alessandro Pasotti
Looking ... but a step-by-step procedure to reproduce from a blank project would be helpful: a project file that shows the issue is not of much use.
#3
Updated by Steve Lowman almost 7 years ago
I think a step-by-step procedure might involve the following:
1. In an older QGIS version, e.g. 2.14, create a new project file with Project Properties set to 'Relative Paths'.
2. Add some locally sourced shapefile layers, and save the project file.
3. Observe that there should be no 'source' attributes in the <layer-tree-layer> keys.
4. Open the same file with QGIS 2.18.15 (or another version to test), ensuring that Project Properties is still set to 'Relative Paths'.
5. Add some more locally sourced shapefile layers.
6. Save As with a new name in the same folder.
7. Observe whether the layers added in step 2 &/or step 5 now have 'source' attributes in the <layer-tree-layer> keys with absolute paths.
The way 2.18.15 is behaving, I expect you will find the 'source' attributes there in step 7, indicating that the bug needs resolving.
#4
Updated by Alessandro Pasotti almost 7 years ago
- Status changed from Open to Rejected
- Resolution set to invalid
Did you try to move the project source tree to a different path?
AFAIK (and I've tested it) everything works as expected.
The connection between the source tree and the actual layer is the "id" attribute and the actual layer source is read from the "datasource" attribute of the "maplayer" with a matching "id".
AFAIK the source attribute in the layer tree is used to loosely retrieve the layer for print composer templates.
#5
Updated by Jürgen Fischer almost 7 years ago
- Description updated (diff)
- Subject changed from Absolute paths still being used in Qgis 2.18 (Previously 16242) to Absolute paths still being used in Qgis 2.18 (Previously #16242)
#6
Updated by Jürgen Fischer almost 7 years ago
- Assignee deleted (
Alessandro Pasotti) - Status changed from Rejected to Reopened
- Category changed from Unknown to Project Loading/Saving
#7
Updated by Patrick Dunford almost 7 years ago
I have a test system running, and it doesn't appear to have highlighted any issues so far.
#8
Updated by David Berlioz almost 7 years ago
Hi,
same issue here with 2.18.16
layers are handled correctly when you move or copy the project but the project qgs file stores absolute path
Steps to reproduce :- Create a project with shapefile layer with relative path activated
- Save and close
- Look at the absolute layer files path
- Copy all project in a different folder
- Reopen copied project
- Make a diff and see the absolute path that was changed
It's working but a bit annoying when you try to work with a team+git
#9
Updated by Patrick Dunford almost 7 years ago
I haven't seen anything so far that shows me the project will stop working because of the absolute paths.
Isn't that the key issue?
#10
Updated by Luigi Pirelli over 6 years ago
confirmed also on Master 7c3ab9f
in my case using gpkgs.
steps:
1) create a gpkg with a layer inside
2) add the layer to canvas
3) save the project saving it in the same folder of the gpkg (Note that project property is set to relative path!)
4) copy project and gpkg somewere
5) rename original folder
6) open copied project => will ask the location of gpkg source
<datasource> remain in absolute
while only <layer-tree-layer> tag is set to relative
#11
Updated by Luigi Pirelli over 6 years ago
in my case (qgis 30 on linux) the error is the uncorrect resolving of a linked path as I commented in #18337
#12
Updated by Giovanni Manghi over 6 years ago
- Status changed from Reopened to Feedback
Luigi Pirelli wrote:
in my case (qgis 30 on linux) the error is the uncorrect resolving of a linked path as I commented in #18337
should we close one ticket as duplicate?
#13
Updated by Jürgen Fischer almost 6 years ago
Please test with QGIS 3.4 - QGIS 2.18 reached it's end of life.
#14
Updated by Giovanni Manghi over 5 years ago
- Status changed from Feedback to Closed
- Resolution changed from invalid to end of life
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/
QGIS 3.4 has recently become our new Long Term Release (LTR) version. This is a major step in our history – a long term release version based on the massive updates, library upgrades and improvements that we carried out in the course of the 2.x to 3x upgrade cycle.
We strongly encourage all users who are currently using QGIS 2.18 LTR as their preferred QGIS release to migrate to QGIS 3.4. This new LTR version will receive regular bugfixes for at least one year. It also includes hundreds of new functions, usability improvements, bugfixes, and other goodies. See the relevant changelogs for a good sampling of all the new features that have gone into version 3.4
Most plugins have been either migrated or incorporated into the core QGIS code base.
We strongly discourage the continued use of QGIS 2.18 LTR as it is now officially unsupported, which means we’ll not provide any bug fix releases for it.
You should also note that we intend to close all bug tickets referring to the now obsolete LTR version. Original reporters will receive a notification of the ticket closure and are encouraged to check whether the issue persists in the new LTR, in which case they should reopen the ticket.
If you would like to better understand the QGIS release roadmap, check out our roadmap page! It outlines the schedule for upcoming releases and will help you plan your deployment of QGIS into an operational environment.
The development of QGIS 3.4 LTR has been made possible by the work of hundreds of volunteers, by the investments of companies, professionals, and administrations, and by continuous donations and financial support from many of you. We sincerely thank you all and encourage you to collaborate and support the project even more, for the long term improvement and sustainability of the QGIS project.