purge doesn't delete the info about downloaded areas

[dieterdreist]

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

[skyper]

This also effects "update data".

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

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

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

[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?

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

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

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

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

[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 !

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

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