Opened 12 years ago
Closed 12 years ago
#8843 closed defect (duplicate)
Merge layers when downloading after opening file
Reported by: | Owned by: | team | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | |
Keywords: | Cc: |
Description
When you open JOSM and the first step is opening a kml file, then when you download OSM data the file layer and OSM data layer get merged.
Attachments (0)
Change History (8)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → needinfo |
Please, describe your problem with more details and suggest what JOSM should do instead of merging. -Thanks
Note: You can always use the checkbox in the lower left corner of any download dialog to download into a new layer.
comment:3 by , 12 years ago
Thank you, I haven't noted the New layer checkbox. If you first download OSM data and then you open a file, the new file opens in a new layer. I will describe de steps:
- Open JOSM
- Open a KMZ file
- Download data
- OSM data and KMZ file get merged. It should download data in a differente layer.
It's very confusing, if you don't pay attention you can easily upload changes to OSM including the KMZ file you opened. In my case I open the KMZ file where I have administrative boundaries, that KMZ file also helps me to know which area I have to download OSM data, and then I translate those lines into JOSM data, add tags, correct them, etc.
comment:4 by , 12 years ago
Well, what is your suggestion ?
- treat KMZ as separate type and never merge automatically ?
- treat opened files separately and never merge automatically (could be a preference option) ?
comment:5 by , 12 years ago
Forgot: there is a hidden feature to prohibit JOSM to upload files (upload=false
). I am not sure if it only works with OSM data files though.
comment:7 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | needinfo → new |
comment:8 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Closed as duplicate of #8039.
Ticket #8842 has been marked as a duplicate of this ticket.