"Update data" sometimes does not detect potentially deleted primitives due to area optimization

[mattmccutchen]

While working on ​https://www.openstreetmap.org/changeset/173152440 in JOSM, I noticed a ​turn restriction on the map that no longer existed on the ground, and I decided to delete the turn restriction first in ​a separate changeset created using a separate instance of JOSM. When I resumed work on the original changeset and used the "Update data" command, I expected JOSM to delete the turn restriction from my data layer because it had been deleted from the server, but JOSM left the turn restriction in the layer.

I traced this behavior to the way that the "potentially deleted primitives" check determines whether a full update or a partial update was performed. ​This code in DownloadTaskList assumes that if the set of bounds rectangles downloaded exactly matches the set of bounds rectangles tracked by the layer, then the update is full, otherwise it is partial. However, the ​area optimization performed in UpdateDataAction can cause the sets of rectangles not to exactly match, even though they cover the same area (or at least I think that's the intent). As a result, DownloadTaskList uses an algorithm intended for partial updates, which appears to be less effective at detecting deleted relations than the algorithm for full updates. (I suspect there may be a similar problem with deleted ways, but I haven't tried to construct a test case.) I'm presuming this should be fixed by somehow ensuring that full updates always use the full-update algorithm. Alternatively, it might be possible to improve the partial-update algorithm to be more effective; I haven't looked into that.

What steps will reproduce the problem?

(I tested the steps today. It's possible that future changes to the map will cause the steps to no longer work as written even if the underlying bug remains.)

1. Start JOSM with a clean home directory.
2. Go to "Download data" -> "Bounding box" and enter: max lat 39.053768, min lon -77.1070987, max lon -77.1064711, min lat 39.0532265 . Download the data and save the layer as 1rect.osm .
3. Open 1rect.osm in a text editor. Copy the <relation> tag from ​https://www.openstreetmap.org/api/0.6/relation/14278849/3 and paste it just before the </osm> . Save as 1rect-trv3.osm . (This is intended to simulate a layer that was downloaded before I deleted the relation on the server. As a less hacky alternative, I considered downloading the map at a previous time from Overpass, but the intermittent unavailability of Overpass was frustrating, and it was difficult to replicate the semantics of an area download from the main API.)
4. Open 1rect-trv3.osm in JOSM. Perform "Update data". JOSM prompts, "There is 1 object in your local dataset which might be deleted on the server...". Choose "Check on the server". The "no left turn" restriction from northbound Parklawn Drive to westbound Randolph Road disappears, as expected.
5. Delete the current layer and open 1rect-trv3.osm again. Go to "Download data" -> "Bounding box" and enter: max lat 39.0539555, min lon -77.1072328, max lon -77.1063423, min lat 39.053643 . (To trigger the bug, this rectangle needs to cover one entire edge of the first rectangle; I chose the north edge.) Download the data and save the layer as 2rect-trv3.osm .
6. Perform "Update data". This will generate two calls to ​https://api.openstreetmap.org/api/0.6/map in the log output. On the first call, notice that the max latitude was changed to 39.053643 (from the originally specified 39.053768) by the area optimizer.

What is the expected result?

JOSM should prompt "There is 1 object in your local dataset which might be deleted on the server..." and offer to delete the turn restriction, as in step 4.

What happens instead?

There is no prompt, and the turn restriction remains in the layer.

Please provide any additional information below. Attach a screenshot if possible.

I'd be interested in working on a fix, though I'm not sure when or if I'd be able to do the work. I'd need to have some idea of what design would be accepted and what kind of tests (if any) should be added. I can think of a few potential designs; some are cleaner, while some work better for third-party users of the API. I'm not familiar with how much the JOSM project cares about supporting third-party users of the API.

1. Add a new method to DownloadTaskList for a "full update"; I'll call it fullUpdate for this discussion. DownloadTaskList.fullUpdate calculates the set of download rectangles itself (the area optimization code from UpdateDataAction would be moved to DownloadTaskList.fullUpdate) and sets a flag that the update is known to be full. Then PostDownloadProcessor checks the flag rather than comparing the sets of rectangles. UpdateDataAction calls DownloadTaskList.fullUpdate. Potential downside: Third-party code that currently calls DownloadTaskList.download with the original set of layer rectangles would then get the "partial update" algorithm instead of the "full update" algorithm.
2. Same as (1), but have PostDownloadProcessor use the "full update" algorithm if either the flag is set or the rectangle sets exactly match. Compared to (1), this is a little messier but at least doesn't regress the behavior for third-party callers, though callers that perform area optimization would still be affected by the original bug.
3. Change PostDownloadProcessor to do its own area calculation to check whether the union of the download rectangles covers the union of the layer rectangles. Could this fail due to floating point error? If not, it's attractive in the sense that third-party callers of DownloadTaskList.download that perform area optimization would get the bug fix without having to make any changes, but I don't know if there are any such callers.

There are probably other variations possible.

If I don't receive any guidance, I may eventually prototype (1) to try to help move the issue forward.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2026-04-22 13:36:11 +0200 (Wed, 22 Apr 2026)
Revision:19570
Build-Date:2026-04-26 01:30:46
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (19570 en) Linux Fedora Linux 43 (Forty Three)
Memory Usage: 414 MB / 4072 MB (110 MB allocated, but free)
Java version: 25.0.2+10, Red Hat, Inc., OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 2560x1440x[Multi depth]@35Hz (scaling 1.00×1.00)
Maximum Screen Size: 2560×1440
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.utf8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: X-QUBES
VM arguments: [--add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, -Djosm.home=<josm.pref>]
Dataset consistency test: No problems found

Last errors/warnings:
- 00274.138 W: Deleted or moved objects - <html>There is 1 object in your local dataset which might be deleted on the server.<br>If you later try to delete or update this the server is likely to report a conflict.<br>Click <strong>Check on the server</strong> to check the state of this object on the server.<br>Click <strong>Ignore</strong> to ignore.</html>