Bug report #2600
OSM plugin: layers in temp folders and qgis messages when opening a project that includes osm data
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | Martin Dobias | ||
Category: | Python plugins | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | All | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | fixed |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 12660 |
Description
When you add to a project OSM data, the osm files are placed in tmp/temp folders. If you save the project and reopen it (on both linux and windows), causes qgis to ask about the missing layers.
If the osm layers are placed in tmp/temp folders on purpose then they should not be saved into the project file. If not, then it should be asked where to save the osm data when downloading it.
I would obviously prefer the second option... :)
cheers
History
#1 Updated by Mayeul Kauffmann almost 14 years ago
Lutra,
I think now there is only the second part of the bug left.
In current dev version (qgis 1.7.0 1d66171f (SVN r14979)) the default is still a temp file, see:
http://trac.osgeo.org/qgis/browser/trunk/qgis/python/plugins/osm/OsmDownloadDlg.py?rev=14131#L312
However, a dialog offers you to change the path to save your osm data, and it works.
The problem still exist when you save the qgis project and want to reopen it. For instance, it will try to open the fowllowing file but does not know how to handle it:
/home/myaccount/maps/download.osm?type=line&tag=name&style=/usr/share/qgis/python/plugins/osm/styles/small_scale.style
For another pholosophy on OSM rendering, have a look at #3222
#2 Updated by Giovanni Manghi about 13 years ago
- Target version changed from Version 1.7.0 to Version 1.7.4
#3 Updated by Paolo Cavallini over 12 years ago
- Crashes QGIS or corrupts data set to No
- Affected QGIS version set to master
- Target version changed from Version 1.7.4 to Version 1.8.0
#4 Updated by Paolo Cavallini over 12 years ago
- Target version changed from Version 1.8.0 to Version 2.0.0
#5 Updated by Martin Dobias almost 12 years ago
- Status changed from Open to Closed
- Resolution set to fixed
- Pull Request or Patch supplied set to No
This will not be an issue in the new OpenStreetMap support in 2.0.