Plugin request: Universal street-level imagery

[stanton]

Currently every source of street-level imagery comes with its own implementation:

• Local geotagged photos
• GPX traces with photo attachments (as produced by e.g. OSMTracker for Android)
• OpenStreetCam
• Mapillary
• Bing Streetside

That leads to a multitude of different imagery layers, different UX for each plugin, different hotkeys etc.

Suggestion: Implement an abstraction layer for imagery access and a generic imagery plugin on top of it.

Such a plugin should allow the user a choice of which sources to use (i.e. select online services and/or local collections of images) and let them control when images from an online source get downloaded.

The former photomapping plugin (now part of core) and the Mapillary plugin have fairly good UX. Taking the Mapillary plugin and extending it to support OpenStreetCam (which currently has poor UX and is quite unstable) might be a good starting point. Also, Bing uses the Mapillary plugin code as a basis for its own code, so there might be some existing work relating to integration of other imagery sources.

Enriching it with some of the photomapping functionality and adding support for local imagery could be further steps down the road.

[taylor.smock]

I've thought about doing this.

The MS Streetside would be the easiest, since they have (almost literally) copied everything from the Mapillary plugin. The one exception is their 360 degree image viewer (uses JavaFX, and Mapillary didn't use JavaFX until recently -- I intend to remove the small usage of JavaFX as soon as I get the time to do so).

We would have to modify the class holding the Mapillary URL's to be a store, and all the methods would have a key passed to them (so it would look like getImages("mapillary", bbox) for example). This would take a fair amount of work though (everything would have to take a constructor of "key", and then store it somewhere to pass on).

I have also wanted to move the Mapillary plugin image view code into core/use the core image viewer code in Mapillary.

However, if I were to do this, I would want to avoid hardcoding URL's into the plugin. So I would like to have a json or xml document somewhere with the data needed for each service (so if Foo Bar decides create a new image service, we don't have to update the plugin and wait for everyone to update the plugin).

[stanton]

Sounds great!

+1 about not hardcoding URLs. Maybe it could be an option to ship a default config file with the known URLs and expose the settings through a Preferences UI—roughly the same thing the Imagery component does for aerial imagery.

About JavaFX, I am told it is not fully supported on OpenJRE, so I’d be happy to see the plugin work without it.

I don’t know the internals of the plugin, but basically all static references to the Mapillary service would have to be replaced with an explicit reference to whatever service the user has chosen. That likely means adding an extra argument to a bunch of method calls. Depending on how many methods are involved, that might mean touching many lines of code, but it’s likely to be (almost) the same change over and over again.