drag to adjust imagery offset

[ian29]

if the imagery is really off, clicking the arrows can be really tedious. i understand if this is intended though to prevent people getting totally wild with the offsets though, could go either way.

[Gnonthgol]

+1

[Vanuan]

Entering values would also be fine.

[bhousel]

@kepta Do you think you could build something like this?

Dragging anywhere in the grey <div> would adjust the offset by maybe by 0.25 offset pixels per mouse pixel. The inner box would just be a <input> where people can type a value or delete to clear the offset back to [0, 0]. Buttons around it in case people still want to do fine adjustments.

[kepta]

Yes, this one is interesting.
I had these doubts regarding the design.

• When a user drags the inner rectangle what will happen when we he reaches the boundary of outer rectangle.
• Is dragging the rectangle like a joystick in which it stores the value of offset and on mouse up, the inner rectangle returns back to the centre?

[kepta]

Conversation from IRC regarding the issue.

22:04 bhousel: My thought was that the control can have a handler on mousedown to start watching for events and mouseup to stop watching.. and on mousemove, you just record the events and update the text in the input field, and also update the background offset… the code wouldn't actually drag the box anywhere, just watch for mousemoves..
22:07 kepta: oh
22:08 kepta: so the inner rectangle would show that it recorded mouse move by updating the number inside, and not actually moving the inner rectangle.
22:10 bhousel: yes exactly.. it can show the input field where people can type a number, or they can just drag around inside that div and the numbers will update that way also
22:11 bhousel: they'll get feedback about what they are doing because as those offset numbers change, the map background imagery will update too

[Vanuan]

A GIF might be more explaining.

[kepta]

@Vanuan
This is what the current implementation looks like.

Updated after @bhousel 's suggestion

I am trying to demo 2 features.

1. Manually enter offset inside the rectangle.
2. Drag the grey area to fine tune.

[bhousel]

Hey that looks pretty good start!!

Some ideas to try:

• Bind the the mouseup and mousemove handlers on document, not the div, so that the user isn't constrained to the rectangular div...
• Call d3.event.preventDefault in all the event handlers, this should prevent the default browser behaviors like the highlighting on the input box.

[bhousel]

@Vanuan

How do people usually talk about offset values? This is something I'm still a little confused about.
In JOSM it looks like you can manually set an offset like "easting; northing" in meters..

Is this how people refer to offsets?
Put another way, in HOT task instructions would somebody say something like:

Choose Bing imagery and apply offset of "-5.75; 3.5"

[Vanuan]

@kepta "Grey area" works for me but wouldn't some "tool" button be more intuitive? Or some checkbox? So that dragging the map wouldn't drag all objects, but only the image layer.

It looks awesome in either case!

@bhousel I think it doesn't matter as long as a particular editor uses consistent units. In addition, there's an offset database: http://wiki.openstreetmap.org/wiki/Imagery_Offset_Database which is #1124. So use whatever units you like, because we'll share them either through database (you'd need to recalculate to degrees) or just mention the editor name. If you want same units as in JOSM, you'd need to read its source code to figure out an algorithm.

[bhousel]

So that dragging the map wouldn't drag all objects, but only the image layer.

Yes, I think this is what @kepta built.. It looks like only the imagery layer is moving.

So use whatever units you like, because we'll share them either through database (you'd need to recalculate to degrees) or just mention the editor name. If you want same units as in JOSM, you'd need to read its source code to figure out an algorithm.

Ok, I was looking here: http://learnosm.org/en/josm/correcting-imagery-offset/
It seems that offsets in JOSM are specified in UTM coordinates.. Is that right?
That seems, um.. weird?

[Vanuan]

I think you should only care about what's stored in the database. Those units doesn't mean anything important. That could be pixel offset, recalculated each time you zoom. Or it can be meters. Whatever. And they can vary greatly, depending on the projection. iD only supports Web Mercator, so that's irrelevant.

There are two kinds of objects in the offset database: imagery offsets and calibration objects.

Imagery offsets are specific to imagery layer. So if you'd just store "city part", it'd mean anything. You must specify imagery layer too, like "New York Downtown, Bing". Additionally, there's a date, because offsets can change over time (new imagery available).

Calibration objects are more interesting: it's basically known GPS coordinate of a specific feature. Like "GPS coordinates of the center of torch of the Statue of Liberty". Or "The center crossing of Wall Street". They don't require imagery specification, because those are objects easily identifiable visually. So it's the same as GPX traces: calibration objects are used to infer offsets for different imagery layers and store new imagery offset values.

P.S. Statue of Liberty might not be a good example, because there's image perspective involved.

[bhousel]

Ok, if the units don't matter, we'll probably just go with something sane, like meters.

[pnorman]

It seems that offsets in JOSM are specified in UTM coordinates.. Is that right?
That seems, um.. weird?

Ok, if the units don't matter, we'll probably just go with something sane, like meters.

I see you're doing the same ;)

UTM coordinates are meters.

[bhousel]

I see you're doing the same ;)
UTM coordinates are meters.

😆 Last night I almost asked you, and instead decided to look it up on Wikipedia and got totally confused.

I just searched again and found this guide to UTM coordinates that describes them much better!