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
