On Fri, Feb 18, 2011 at 11:21 AM, Dermot McNally <[email protected]> wrote: > In exactly the same way as, say, the Offset bookmarks offered by JOSM > - it doesn't, and the mapper needs to notice that the imagery doesn't > seem to line up any more. As such, as a baseline, using True Offset is > at worst no worse than other options for managing your calibration.
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. 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. And yes, it is worse, because mappers could end up applying a false offset. and not knowing. Say Bing had some imagery which was out by 20m for a large rural area. Someone applies the offset, and starts mapping. Then Bing fixes its imagery. Someone else comes along and maps in an area with not much to reference against, and now their mapping is all offset... Is there a way for the service to check when changes are made to the imagery provider, and reset all offsets? Steve * (Not that NearMap in practice actually has any offset worth recording...) _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
