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.sm...@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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
