[WIP PATCH] Allow SelectionManager to work on non-OsmDataLayer layers

[taylor.smock]

The attached patch begins the process of modifying the SelectionManager for non-OsmPrimitive types (for example, images/sequences).

This is a pre-requisite for #18434.

[taylor.smock]

Initial WIP patch (very broken, its a work in progress)

[taylor.smock]

Making everything generic (still broken, but much further along)

[GerdP]

The new code in the patch looks rather ugly.
Sorry for my ignorance. I've never "edited geotagged images localization". Why is that done with JOSM when it requires a complete change in so many interfaces?

[taylor.smock]

Replying to GerdP:

The new code in the patch looks rather ugly.

I agree. Unfortunately.

Sorry for my ignorance. I've never "edited geotagged images localization". Why is that done with JOSM when it requires a complete change in so many interfaces?

Neither have I -- I almost never modify my images after I take them (possibly due to poor tools, etc.). I only wanted to allow the SelectionManager to be used to do selection actions (Lasso/Box selection, specifically), but that took me down a rabbit hole. I was thinking about it last night, and I was going to do a pass were I essentially reverted all of my current work.
For example, instead of modifying WaySegment to be generic, I should have implemented an IWaySegment<N, W> interface, and had WaySegment implement that.

That being said, use cases for more "generic" commands would be useful, if you take a bunch of images, and then want to do some kind of corrections afterward (maybe the first few images taken are ~100m off, and you want to correct that).

Like the title of the ticket says, this is a WIP patch. Very much a Work In Progress.

Anyway, here is what I intended to do:
1) Modify SelectionManager so that it could select items from any AbstractOsmDataLayer that is the current dataLayer
2) Modify various plugins (MapWithAI specifically) so that it extends AbstractOsmDataLayer instead of OsmDataLayer (to avoid auto-saves -- I have a patch somewhere for that specifically, but this is probably a slightly better approach)
3) Modify the GeoImageLayer to extend AbstractOsmDataLayer, and create an OsmData<GeoImagePrimitive, Image, Sequence, ImageRelation> class for geoimages. This would allow me to do basic image manipulation in JOSM. I could also make some modifications such that when a user loads geoimages, it assumes that each directory is a single image, and make a sequence out of it (its a bit easier to go through images quickly when they are pointed in a uniform direction).
4) Modify Mapillary to use the new GeoImageLayer, and also (possibly) OpenStreetCam/Microsoft StreetSide. Since each one of those implements their own sequence/imagery layer, I think this would be a deduplication win.

I would also have to do something to indicate a current data layer in the gui though (maybe a translucent green checkmark?).