On 18 February 2011 04:08, Steve Bennett <[email protected]> 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 reduced. 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. Dermot -- -------------------------------------- Igaühel on siin oma laul ja ma oma ei leiagi üles _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
