[HOT] How bad is mapping from offset imagery?

Andrew Buck andrew.r.buck at gmail.com
Tue Apr 4 17:54:37 UTC 2017


For almost everything HOT does, and really OSM in general alignment is
really not that big of a deal.  Today, almost any imagery we get access
to is aligned to within at most 10 meters (and lots of it is within 2 or
3 meters) of reality and in sparsely populated areas a few meters offset
is not a big deal at all (especially considering the accuracy of a gps
is only a few meters anyway).

For most of what we do, building counts are the main thing humanitarian
groups are interested in.  The second most important thing is the size
of the buildings (for example not counting really small buildings in
population estimates, or marking really large buildings as likely
candidates for visits by aid workers since they are likely schools,
etc).  Neither of these are affected at all by offsets which are
measured in meters.

The only place offsets really become important is in urban areas, or
where different "layers" of data were mapped at different times (for
example roads done a few years ago and buildings done today).  In these
cases large offsets can mean that a building on the east side of a road,
gets mapped on the west side of the road due to the offset.  In these
situations consistency is the main concern so that is why we have
instructions to try to align the imagery.

Regarding the accuracy of Bing, we don't know that it is good
everywhere, however just about anywhere we compare it to gps data it
lines up nearly perfect (like to within a meter).  So given that they
have a great track record so far, we tend to defer to them as a baseline
if no other information is available.  Also, since bing is in all the
editors and is nearly worldwide it just makes for a consistent baseline.
 I.E. it is not necessarily perfect, but since consistency is more
important than absolute accuracy, bing wins just by being the most
consistent over large areas.

So the short answer is, we always try to be as accurate as possible, but
small offsets are not worth losing sleep over.  Don't spend a lot of
time trying to match up trees in two sets of imagery so that you can
correct the 5 m offset on the only road for miles.

-AndrewBuck

On 04/04/2017 11:07 AM, Florian Niel wrote:
> I often see that other mappers don't align the background imagery. I am
> wondering how a big deal this is.
> 
> Aligning the imagery in tasks like the malaria elimination projects is
> difficult, if the square does not contain any data (and no gps traces).
> I do it (in JOSM) by clicking some points of a road or path or something
> other visible in both Bing and the recommended imagery, and check if
> there is an offset and then align it to Bing. Then I delete the path I
> just mapped and start mapping the buildings.
> 
> With this method I need more time for the alignment than for mapping the
> two or three buildings to finish the task.
> 
> So I have questions:
> 1) Is there a faster way to align the imagery on empty squares?
> 2) Is it really necessary to align it for just a few buildings and a lot
> of nothing (mapped) around? As I dont know what the data is used for so
> I cannot tell. The size and the shape of buildings are correct anyways
> and my intention would say it is no big deal if it is a bit offset.
> 3) Is it possible to align the imagery in advance before opening the
> task for HOT so mappers do not have to care about it?
> 4) Is Bing really always better aligned or are we doing just a shift
> from one unknown offset to another?
> 
> Another comment on alignment: I just looked at the video from Blake
> (https://www.youtube.com/watch?v=1Pcj_wFTHeE) about how to align imagery
> in iD. I think we need a better one. One thing is that it is not
> comparable to empty squares (like in many malaria-project squares) and
> the other thing is that he comes to the conclusion that he should not
> align the imagery at all (because it is a messed up square with objects
> mapped from different imageries).
> 
> Best,
> Florian
> 
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20170404/238b40d3/attachment.sig>


More information about the HOT mailing list