Modify

Opened 7 years ago

Last modified 17 months ago

#5466 new defect

purge doesn't delete the info about downloaded areas

Reported by: dieterdreist Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: purge hatch Cc:

Description

When you do a purge the area will still remain marked as "downloaded" i.e. without the diagonal hatch. IMHO as soon as you purge the respective area should be marked as uncomplete (by drawing the hatch in the area).

Attachments (0)

Change History (11)

comment:1 Changed 6 years ago by skyper

This also effects "update data".

I purge almost everything and ran "update data", only to get the whole bounding box back again.

comment:2 Changed 6 years ago by xeen

What could be done, would be to mark areas that are now empty as “not downloaded”. While marking a small region around purged objects as incomplete/not downloaded would be the correct thing to do, it kind of defeats the purpose of purge in some cases. For example, when drawing buildings one might want to remove the landuse areas. This would likely mark everything as not downloaded, which is clearly not what was expected.

While my suggestions would fix skyper’s issue, it only solves part of what dieterdreist proposed.

comment:3 Changed 6 years ago by bastiK

Purging certain features, like landuse or power line, is nothing we should promote. It is dangerous, cause something could still be glued to a node when you move it.

The filter can be used for that.

comment:4 in reply to:  1 ; Changed 6 years ago by bastiK

Replying to skyper:

This also effects "update data".

I purge almost everything and ran "update data", only to get the whole bounding box back again.

"Update data" relies on the /map API call to redownloaded all downloaded bounding boxes. The idea is, that you also get new objects in that region. So what is the difference between new objects (created in the meantime by another user) and objects that have been purged at some time? Shall we rely on the timestamp and drop all objects that are not in the current data set, but are older than the original download of that bbox?

comment:5 Changed 6 years ago by xeen

Why is purge then implemented that way in the first place? It works on what is currently selected (and does some magic to purge related primitives as well) and not, say, by purging entire rectangles.

comment:6 Changed 6 years ago by bastiK

Well, honestly, I didn't think of "update data" when implementing it. "Purge selection" is more powerful than "purge rectangle". Just because it is usually a bad idea to purge landuses and continue editing, this doesn't mean there aren't other use cases, where something like this is perfectly reasonable.

Purging related primitives is technically necessary in some cases. In addition it purges untagged way nodes because this is probably the expected behaviour.

comment:7 in reply to:  4 ; Changed 6 years ago by stoecker

Replying to bastiK:

"Update data" relies on the /map API call to redownloaded all downloaded bounding boxes. The idea is, that you also get new objects in that region. So what is the difference between new objects (created in the meantime by another user) and objects that have been purged at some time? Shall we rely on the timestamp and drop all objects that are not in the current data set, but are older than the original download of that bbox?

We can drop downloaded boxes, where nothing remains after purging. And when download area is partially dropped (e.g. an left side) we could reduce the download boundary to the remaining part. We shouldn't go further.

comment:8 in reply to:  7 ; Changed 6 years ago by bastiK

Replying to stoecker:

Replying to bastiK:

"Update data" relies on the /map API call to redownloaded all downloaded bounding boxes. The idea is, that you also get new objects in that region. So what is the difference between new objects (created in the meantime by another user) and objects that have been purged at some time? Shall we rely on the timestamp and drop all objects that are not in the current data set, but are older than the original download of that bbox?

We can drop downloaded boxes, where nothing remains after purging. And when download area is partially dropped (e.g. an left side) we could reduce the download boundary to the remaining part. We shouldn't go further.

You could move / delete some objects and then purge that region. So at least we need to remember the original state of modified objects. This requires major extensions to the *.osm file format.

comment:9 in reply to:  8 Changed 6 years ago by skyper

Replying to bastiK:

Replying to stoecker:

Replying to bastiK:

"Update data" relies on the /map API call to redownloaded all downloaded bounding boxes. The idea is, that you also get new objects in that region. So what is the difference between new objects (created in the meantime by another user) and objects that have been purged at some time? Shall we rely on the timestamp and drop all objects that are not in the current data set, but are older than the original download of that bbox?

We can drop downloaded boxes, where nothing remains after purging. And when download area is partially dropped (e.g. an left side) we could reduce the download boundary to the remaining part. We shouldn't go further.

You could move / delete some objects and then purge that region. So at least we need to remember the original state of modified objects. This requires major extensions to the *.osm file format.

Why not just ask for upload/save changes and then purge (if not uploaded/saved discard changes).

Purge is not the right tool to filter data !

comment:10 Changed 5 years ago by AndrewBuck

On the issue of purging a landuse that may be "glued" to other objects that might get edited: purge could warn the user that it is about to purge nodes that are shared by other objects in the editing space and then prompt the user for action, similar to how the delete action warns about deleting nodes out of the area as they might be connected (although in the case of purge the engine can actually determine if any actually are connected and ask what to do).

Possible options for the user to select from the popup could be:

  • Purge _exactly_ the stuff selected for purge, no more no less.
  • Purge any connected ways as well.
  • Do not purge the selected ways that are connected to other objects.
  • Cancel the purge entirely.

comment:11 Changed 17 months ago by skyper

I wonder how it works for incomplete data like downloading objects by id or an incomplete relation.

We need to mark it somehow after the first purge as this information is lost once I delete the layer and it is not included in saved files. Purging only some relations might be a really tricky case.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to dieterdreist
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.