Here’s the story from the beginning. I wanted to map a temporary road closure in my area, so I started drafting the change in JOSM. Then I noticed an incorrect turn restriction nearby. Discussion of whether the first change should be uploaded at all was unfinished and I wanted to fix the turn restriction right away, so I opened a second instance of JOSM and deleted the turn restriction. (A separate data layer in the same instance of JOSM would probably also have worked.) Back in the first instance of JOSM, I did an “Update data”, expecting that the turn restriction I had just deleted from the server would disappear, but it didn’t. I investigated and found an apparent JOSM bug: because my data layer was assembled from two overlapping bounding box downloads, the area subtraction code in UpdateDataAction tricks the stale object checker into thinking the update is a partial download, so the stale object checker uses a less effective algorithm that doesn’t detect deleted ways and relations if none of the nodes they contain has been deleted.
I ultimately did upload the first changeset. Now I’d like to report the JOSM bug, which means writing up steps to reproduce it. Ideally, the procedure shouldn’t require actually deleting a relation from the main server as part of the test. It might be possible to use the dev server, but instead I pursued the approach of making a data layer containing what an area download from the main server would have returned before Changeset: 173151604 | OpenStreetMap was uploaded, so I can then “Update data” on that layer. I still have a copy of the OSM file from my actual work on the first changeset before I ran the “Update data” command that originally exhibited the bug, but that file is large and has pending edits in it. I think it would be preferable to generate a minimal OSM file that triggers the bug from scratch, to prove that no other factors are complicating the scenario. So I wanted a way to generate an OSM file simulating an area download from the main server at some previous time.
The easiest way I know to get such “attic data” is using Overpass with the [date] setting, and JOSM can download from Overpass, so I thought I was in good shape. Before specifying an old [date], I wanted to get a query that I could confirm matched the behavior of the main OSM API at the present date. First, I ran JOSM’s Overpass query wizard with an empty JOSM search string, which should match everything, and it generated the following query:
[out:xml][timeout:90][bbox:{{bbox}}];
(
nwr/*org.openstreetmap.josm.data.osm.search.SearchCompiler$Always@4a5129f9*/;
);
(._;>;);
out meta;
But this downloaded more data than a download of the same area from the OSM API. Specifically, if a relation overlaps the bounding box, the Overpass query would return all members of the relation, while the OSM API would return only the members in the bounding box and leave the other members as “incomplete”. Since I’m trying to demonstrate a subtle bug in JOSM’s handling of the data layer, I wanted it to be exactly the same. After trying a few simple changes to the query that still didn’t exactly replicate the data from the OSM API, I figured I had to translate the rules from the OSM API documentation into Overpass code, step by step. That led me to the first query in my previous post, which didn’t work because of my misunderstanding of the union semantics, and then my corrected query, which generated an OSM file identical to the one from the OSM API except for the <bounds> element itself. It appears JOSM doesn’t generate a <bounds> element when downloading from Overpass; I’m guessing the rationale is that it would be misleading because in general (though not in my use case), the query might be filtered and the data layer might not contain everything in the bounding box.
Given that my Overpass query exactly replicated the OSM API data at the current time, if I add the past [date] setting and then manually add the correct <bounds> element to the output, I’m fairly confident that I’ve accurately recreated the scenario where a user downloaded from the OSM API at that past date. Indeed, the only difference in the past data for my bounding box compared to the present data is that the turn restriction I deleted in Changeset: 173151604 | OpenStreetMap is still there (which is the focus of the scenario), so I could have gotten to the same result much more quickly by manually editing the turn restriction back into the OSM file. But getting an identical result by another means gives me additional confidence in the correctness, and I thought the ability to simulate OSM API area downloads at past times might be useful for other purposes in the future. Now, in order to actually demonstrate the JOSM bug, which is triggered by having two overlapping bounding boxes, all I need to do is go through the JOSM download dialog twice to download both bounding boxes rather than only the one that I’ve been using as an example so far.
DaveF, you may disagree with some of the decisions I made about how to approach my problem, but I hope I’ve convinced you that I have some understanding of what I’m doing and why. With this background, I hope we can evaluate the likelihood that other users will run into the same problem/misunderstanding and what change (if any) to the documentation is justified.
I’m sorry for the hassle I’ve caused by not giving the full background at the beginning of the thread. I didn’t foresee that the subject might be so controversial.