[Talk-GB] New Bing Imagery

Wed Aug 19 15:52:25 UTC 2020

I contribute a bit to the development of iD and have interacted with the
current lead developer (who's currently not funded to work on it full time
anymore) as well as the previous (who's moved on to RapiD) numerous times.
As it's open source software my suggestion would be to interface using the
development channels of Github (open an issue ticket concerning supporting
the offset DB, or comment on the existing one if there is one) rather than
approaching anyone in particular. This way there is a documented place for
continued/historic open discussion.

It is unlikely you will see quick movement on this though unless someone
takes on the challenge themselves (the benefit of open source - and how
I've made additions to the software in the past). The community itself has
a responsibility to contribute to and develop open source tools if they
don't meet our needs/wants.

On Wed, Aug 19, 2020 at 4:23 PM Stephen Colebourne <scolebourne at joda.org>
wrote:

> 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
> _______________________________________________
> 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/5ebbfe21/attachment.htm>