Use the upcoming imagery offset database

[Zverik]

Manually adjusting every layer is hard, non-obvoius and usually unneeded task which duplicates the efforts of previous mappers in an area. In a week or two I'm announcing the imagery offset server which allows users to determine an offset for each area once, and then just use the shared value.

See the description and API documentation. There is also a map and a list (refreshes every hour).

Also I'd like you to check the alpha-version of a JOSM plugin (it should be put into ~/.josm/plugins). It shows that the user interface mostly consists of informational messages and a dialog for choosing an offset. The latter is the most important part: its design should give users enough information to correctly choose an offset and rid them of doing the same work twice.

I plan to release beta on Monday or Tuesday, and before that I'm open to any suggestions, even those which could reqiuire structural changes to the database and the plugin.

[Zverik]

The description now includes JOSM plugin manual with an annotated screenshot.

[Zverik]

I'd like to remind you of this service. In past months it has been widely adopted in Russia, and by some mappers from other, mostly european, countries. There are 2.2k entries in the database now, growing by ~10 entries every day. I am sure imagery layers in USA and Western Europe are already precisely aligned, but in some countries they aren't, and users might skip aligning imagery layer altogether, because it is too hard (see also #1340). Supporting the offset service will result in fewer alignment errors by new users.

[RicoElectrico]

I second that. We need offsets DB badly. iD is an editor for beginners, they sure as hell are eager to "fix" offset buildings. Read-only access will suffice.

[tmcw]

The fastest way to get this into iD would be to implement it and submit a pull request; we've got quite a few other priorities which are a bit more crucial to making iD the default.

[Zverik]

iD is default now, and #227 doesn't seem as being worked on, so right now there is no way to align imagery correctly in the editor. That would lead to novices "fixing" object locations nearly everywhere except US and Western Europe. Offset Database currently has more than 3200 offsets, most of which come from Russia and HOT activities. Isn't it time for it to be supported in iD? The API is really simple.

[jfirebaugh]

@Zverik It's on the list of features we're considering -- but that's a long list, and there are many competing priorities and limited developer resources. Again, a pull request is the best way to make it happen faster.

[jfirebaugh]

The minimal viable implementation in my mind here is:

• Port the imagery identifier algorithm to JavaScript and validate against the editor-imagery-index URLs.
• Implement a read operation on the offset get API and, when a non-deprecated offset is available within some fixed radius, use it by default.
• UI consists of an additional button in the "Fix alignment" which acts like a toggle. When an available offset is found and in use, the button is in the active state. The user can switch the auto-alignment off by toggling the button off. When no offset is available, the button is disabled. The button should have a tooltip with copy something like "Use automatic imagery offset". Bonus points for displaying the offset's date, distance/direction, and OSM username.

This minimal implementation would not:

• Include the ability to create new offsets or deprecate existing ones.
• Include any calibration geometry functionality.

Estimate 2 days developer time for this, plus we need one new icon with enabled and disabled states.

[Zverik]

Example of the second item: https://github.com/Zverik/leaflet-bing-iodb/blob/gh-pages/Bing.IODB.js#L26

[lxbarth]

Are imagery offsets predictable enough to enable them by default? E. g. in hilly areas offsets vary between valleys and hilltops.

I imagined rather a system where iD:

• Reports offsets to the offset DB
• Warns that there appears to be an offset when the offset DB reports one
• Adjusting offsets is left up to the user

[jfirebaugh]

Since one of the primary use cases for this feature is "new user wants to edit/trace in an area, has no idea that imagery offsets are even a thing", I think this has to be automatic. We don't want to add "imagery offsets" to the list of concepts beginners have to understand and feel confident about to the level that they can make a decision whether or not to use the database suggestion before making their first edits.

[mikelmaron]

More and more people are using iD through the tasking manager, and offsets come up often. We don't have code to contribute right now, but just to say, for HOT, we're on board with finding a way to figure this out.

[jaakkoh]

No code from me either (sorry, I barely understand basics of reading simple scripts) -- but just want to say that I (too) think that it would be superb to get this to iD.

[jfirebaugh]

@simonpoole, could you briefly common on how you integrated the IODB in Vespucci? Are known adjustments applied automatically?

[simonpoole]

Currently we don't apply offsets automatically.. Obviously I've thought a bit about it, however (different from iD) one of the questions is how much should we make correct operation of vespucci dependent on being online (there is currently no on device offset store in vespucci, but that may be coming)..

IMHO there is no reason in the context of iD not to apply the offsets at least semi-automatically (ask for confirmation) more or less in line with jfirebaughs suggestion from 6 months ago.. Zverik has made the website/API code available so we could run a mirror if necessary if availability is a concern.

What does need some consideration is which offset to select. In vespucci I currently simply present a list of offsets in the vincinity ordered (nearest first) by distance from the current center of the map. That may be a bit too involved for iD, but at least an indication of how far away the correction was applied would be helpful to making the decision if the correction should be used or not.

[planemad]

The offset db has been super useful during the recent realignment of over 50,000km of roads in Taiwan by the data team at Mapbox. Both Bing and Mapbox imagery has varying offset throughout the country and we now run the risk of the data being moved back to the incorrect location by new users who are unaware of the concepts of offsets

Even a warning message in areas with known imagery misalignments like the one in JOSM could be a huge help for beginners.

It seems like a lot of southeast Asia is affected by this issue.

[Zverik]

Can I "up" this? It would be great to notify iD users that the imagery can be offset, especially outside US / Western Europe. Or at least have an option to download the nearest offset from the database — we can promote this option outside of iD, I guess.

[bhousel]

Can I "up" this? It would be great to notify iD users that the imagery can be offset, especially outside US / Western Europe

Sure, I'll label it as since it does affect a lot of users.

[bhousel]

wip at #4166

[jidanni]

In
https://wiki.openstreetmap.org/wiki/Talk:Using_Imagery#Results_of_years_of_.22Adjust_imagery_offset.22_use I propose a solution based on having a grey framework of official high contrast edge locations, which they naturally will want to pull the imagery to align with, before editing.

[jgscherber]

Can the WIP label be removed from this? This issue is marked as priority and appears like it's being worked on with the label, but the pull request is from 2017

[bhousel]

Can the WIP label be removed from this? This issue is marked as priority and appears like it's being worked on with the label, but the pull request is from 2017

Sure, I can remove it..

[rugk]

Is this implemented? If not it may be re-opened, does not it?