[Talk-GB] New Bing Imagery

Stephen Colebourne scolebourne at joda.org
Wed Aug 19 15:22:44 UTC 2020


I'm glad I started a discussion, even if there aren't any real answers. It
is going to be an increasing problem I fear and one I think OSM needs
a solid answer to.

In SW London, I've just checked against "OS OpenData StreetView" and all my
edits (and thus Esri World Clarity Beta) all match pretty much exactly. The
imported boundary data is less clear, but again it favours the current data
where I can actually determine a difference. So. I do think Bing is out.

Does anyone have any contacts with iD developers? From reading their
threads it seems like they want to design a brand new perfect system from
scratch, rather than adopt the offset DB. Since JOSM is generally more
savvy users, it is iD I care more about.

I'll contact the Amazon mapper and see if I get anywhere...

Stephen



On Wed, 19 Aug 2020 at 16:00, Colin Smale <colin.smale at xs4all.nl> wrote:
>
> At least it sounds soluble. Given the right transform and corrections a
"definitive" OS point in Easting/Northing format can be translated
accurately to WGS84 lat/long. However you look at it, I would expect a
purely mathematical transformation should have less error than a
transformation involving "tracing" from imagery whose rectification has
probably also involved some of these transformations each with their own
error terms. But I suppose that it at least partly depends on your
definition of "perfection."
>
>
>
>
> On 2020-08-19 16:34, SK53 wrote:
>
> This isn't necessarily true. If you open any OS Open Data product in QGIS
one is now confronted by a bewildering array of ways of converting from the
OSGB national grid co-ordinates to WGS84.
>
> The optimum one currently uses the 2015 file of detailed offset
corrections to the basic projection transformation. There was an earlier
set of similar data released in 2002. If one doesn't download this
correction data then it falls back on the basic transform using OSGB36
which can be anywhere between 1 and 5 m off-true. In addition there has
always been the slightly obscure behaviour of OSGB projections specified in
proj4 or WKT formats with respect to the Helmert Transformation parameters
(in early days of Open Data Chris Hill & I found these were essential). At
least part of the problem is that EPSG:27700 appears to relate to several
very slightly diverging projections, whereas, for instance, Irish Grid
changes are handled by EPSG:29001 through EPSG:29003, and Swiss Grid CH1903
is EPSG:4149, CH1903+ is EPSG:4150 and the newest CH1903+/LV95 is EPSG:2096.
>
> I don't know what transformation JOSM uses when reading EPSG:27700 so
unless one is very cautious it is not possible to be certain that one is
anywhere near the RMS 25 cm accuracy of OS data (especially as products,
including Boundary Line, may be partially generalised.
>
> Like Jass I've been looking at various data sets which can be pulled into
editors to help with alignment. I initially used OS Open Roads, but this is
just too generalised to be usable in many areas. Larger buildings from OS
Open Local, although generalised, will often have corners in the right
place. Perhaps what we need is an equivalent of TIGER Line as a GB specific
overlay layer showing selected alignment friendly features from either OS
Local or Vector Map. If we could borrow styling from either TIGER Line or
the US Forest roads it might be feasible to make such a layer.
>
> Jerry
>
> On Wed, 19 Aug 2020 at 13:58, Colin Smale <colin.smale at xs4all.nl> wrote:
>>
>> On 2020-08-19 12:17, Andy Townsend wrote:
>>
>> On 19/08/2020 10:11, Stephen Colebourne wrote:And now I can see Amazon
mappers using an iD variant
>> that doesn't have the offset and moving all the roads as a result:
>>
https://osmcha.org/changesets/89549551?aoi=758c7f2b-faca-44e5-acd2-0cb8c33034bd
>>   https://www.openstreetmap.org/changeset/89549551
>> If that's happening at all, please comment on the changeset explaining
the problem.  In English urban areas OS OpenData StreetView is a pretty
good guide for alignment and if people (especially people doing a lot of
editing) are not taking into account different imagery offsets then that's
just wrong.
>>
>> Possibly even better that StreetView imagery is data that has been
imported directly from OS, such as OS Boundary-Line for the admin
boundaries. This is probably the closest we can get to cm-level accuracy -
even though they don't give us the full resolution, the base points such as
tripoints where boundaries meet are likely to be pretty damn accurate. I
would recommend using these as a kind of calibration point to sanity-check
imagery alignment and other data based on less accurate GPS positioning
(e.g. from any consumer-grade GPS kit).
>>
>> _______________________________________________
>> Talk-GB mailing list
>> Talk-GB at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20200819/0346e014/attachment.htm>


More information about the Talk-GB mailing list