[RFC][Patch] Allow matching by object history in search function

[Woazboat]

​https://github.com/JOSM/josm/pull/80
​https://patch-diff.githubusercontent.com/raw/JOSM/josm/pull/80.patch

Added the was keyword to the search function to allow matching objects based on their previous states. I.e. was <expr> matches an object if <expr> matches any previous version of the object.

(For now) the history search only works for objects whose history is already in the cache/history data set and does not fetch history data automatically. (Not sure how feasible downloading the history of a massive amount of objects is in general with the OSM API)
A menu action to download and cache the version history for selected objects was added as well.
The history browser dialog currently clears the history cache/stored history data when it's closed, which isn't great when it's also used elsewhere. This will probably need to be changed https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/gui/history/HistoryBrowserDialogManager.java#L124

Example:

• was building=* to search for all objects that either currently have a building=* tag or have had this tag at any point in their history.
• was building=* -building=* to search for all objects that previously had a building=* tag which was removed at some point.
• was timestamp:2020/2021-11-10T18:35:24Z to search for objects which were changed in a particular time period (not only the latest change)

[skyper]

Nice feature, I like it, though, caching the objects' histories for the session is needed, I guess.

I wonder how much impact #21563 has and if it is possible to only search the last n versions or a time span like within the last month or the last year or two?

[gaben]

Why does the was keyword match an object's last state? It seems counterintuitive to me.

[Woazboat]

Replying to gaben:

Why does the was keyword match an object's last state? It seems counterintuitive to me.

Depends on your point of view, I'd argue the current state is still part of history and making it inclusive makes a lot of sense and avoids some pitfalls. For example, if you want to search for objects that were changed within a certain timespan (was timestamp:2020/2021-11-10T18:35:24Z), you'd probably expect it to be matched even if that's the last state of the object.

[Woazboat]

There's still a problem with a lot of the search match functions and the representation/implementation of historic data in josm which I just noticed.
HistoryOsmPrimitive only implements the Tagged interface and not the OsmPrimitive interface even though it represents more or less the same concept. A lot of the search functions (i.e. anything that's not a tag match) only work properly when given a proper OsmPrimitive and simply abort for HistoryOsmPrimitive/Tagged.

Coercing the historic data into proper primitive classes (e.g. the way it's done in the undelete plugin https://josm.openstreetmap.de/browser/osm/applications/editors/josm/plugins/undelete/src/org/openstreetmap/josm/plugins/undelete/UndeleteAction.java?rev=35848#L73) and matching those would be a possible workaround, but that's a bit suboptimal.

[gaben]

Replying to Woazboat:

Depends on your point of view, I'd argue the current state is still part of history and making it inclusive makes a lot of sense and avoids some pitfalls. For example, if you want to search for objects that were changed within a certain timespan (was timestamp:2020/2021-11-10T18:35:24Z), you'd probably expect it to be matched even if that's the last state of the object.

I think it depends on use case. The timestamp example better fits (simpler) than the building one in the description. Either way, it's a useful addition, wanted something similar a long ago.

One code remark because of the above conversation. The historic state of object hint is not clear. Something like historic state of object, including last version or a shorter any version of object may better reflect the actual function.

[Woazboat]

I updated the description in the search dialog