[OSM-talk] Announcement: Availability of True Offset web service
dermotm at gmail.com
Fri Feb 18 15:13:19 GMT 2011
On 18 February 2011 04:08, Steve Bennett <stevagewp at gmail.com> wrote:
> For imagery sources like NearMap*, which support a time dimension,
> maybe it's worth including some kind of date field? That would also be
> helpful for imagery that, even if you can't access older imagery, can
> at least tell you the date of the current stuff, so you'd know if the
> offset was out of date.
Not impossible to incorporate into the service, but where should the
date info come from? The solution doesn't know or care about imagery
tiles, which would be the obvious source.
> Relying on a "mapper to notice that the
> imagery doesn't seem to line up" seems to defeat the purpose of the
> whole thing a bit, in my eyes.
I respectfully disagree. Today's best solution to the problem requires
every mapper to:
* Realise that the default calibration may be incorrect
* Adjust for the error per mapping session, either manually or through
storing and subsequently reusing a bookmark
* Notice whether changes in the base imagery render the assumed
correction factor incorrect and to then recalibrate where that occurs.
True offset requires no more than one mapper to do those things. The
chances of any given mapping session producing offset data are thereby
The only dangerous situation I can foresee is where an offset in a
particular area is corrected once, subsequently corrected in the base
imagery _but_ not one single active mapper in the area notices the fix
and therefore the True Offset correction endures, _and_ where future
mappers blindly believe the imagery even though offset from other data
mapped in the area.
My assumption is that this is unlikely in real life. For a correction
to have been stored in the first place requires that an active mapper
of clue has been interested in the area and has traced from that same
imagery. It is unlikely that he will abandon the area, but if he does,
it will likely have reached a level of completeness sufficient to
cause a mapper of less clue to assume that the imagery is right and
the existing data wrong.
But again, even _if_ this were to happen, I think OSM will still
experience a net rise in the accuracy of imagery traced.
> And yes, it is worse, because mappers could end up applying a false
> offset. and not knowing.
They already do that several hundred times a day. It will happen less
if we have a solution like True Offset in the mix.
Igaühel on siin oma laul
ja ma oma ei leiagi üles
More information about the talk