Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Robert Whittaker (OSM lists)
On Wed, 19 Aug 2020 at 15:36, 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.

Perhaps this is what's causing the following problem for me then. I
GPS-surveyed a lot of the roads on my estate a few years ago when
aerial imagery wasn't so good. I've got GPS traces in OSM that
consistently follow the pavements on each side of the road and will
line up nicely with the aerial imagery if you put in the right
off-set. However, the required off-set for these traces is around 3m
out from the offset you need to make the OS OpenMap Local Functional
sites (as suggested above) line up, when I load the shapefile directly
in JOSM. This ~3m is very noticable when you have mapped buildings and
pavements sticking out into roads.

Perhaps it would be useful if someone could to do a correct
transformation of (e.g.) the OS OpenMap Local Functional Sites data to
a format and CRS that can be unambiguously read by JOSM, in order to
help our imagery alignment.

Robert.

-- 
Robert Whittaker

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Simon Poole
There is even a (never merged and now likely really stale) PR:
https://github.com/openstreetmap/iD/pull/4166

SImon

PS: and an issue too

Am 19.08.2020 um 11:20 schrieb Mateusz Konieczny via Talk-GB:
> Have you checked whatever
> there is an open issue proposing to
> support imagery offset database in iD?
>
>
> 19 Aug 2020, 11:11 by scolebou...@joda.org:
>
> So, I followed the links below and added an offset. But this simply
> isn't a viable solution to the problem because it only works for JOSM
> and not iD.
>
> I managed to convince one mapper to type in the offset manually in iD
> every time, but that is a horrible thing to ask new mappers to do,
> very offputting. 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
> This is going to keep happening so long as OSM has multiple image
> sources and multiple editors. Frankly I'm amazed that this isn't a
> solved problem.
>
> Having done some mapping across the country recently, it seems like
> Bing is offset to the previous best imagery across the country, but by
> varying amounts. Is there really no solution that can be applied to
> the source Bing layer? Or should we all just accept Bing as golden?
>
> Having added thousands of buildings and fixed roads to align to the
> previous best imagery, I don't have a good solution to the problem,
> and it is demotivating to think that others are going to come along
> and move individual roads/buildings to align without considering the
> bigger picture.
>
> The only solution I can think of is to move all nodes in the area I've
> worked on to match the new Bing (ie a mass edit). Any other
> suggestions?
>
> Stephen
>
>
>
>
>
>
>
>
>
>
> On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
>  wrote:
>
>
> 
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
> (I think that nowadays it is built in - is plugin installation
> still necessary?)
>
>
> No idea about iD support -
> https://github.com/openstreetmap/iD/search?q=imagery+offset
>
> Jul 13, 2020, 00:21 by scolebou...@joda.org:
>
> Wow, the imagery is really good. But in my area the imagery is
> about
> 3-4m east west and 3-4m north south out of alignment with Esri
> World
> Imagery (Clarity) Beta, which is what I've been using up until now
> (for thousands of buildings).
> https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>
> Is there any way to unify the alignments?
>
> Stephen
>
>
> On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>
>
> I’ve noticed patches of vastly improved bing imagery since
> December, but it is really patchy.
> Gareth
>
> > On 6 Jul 2020, at 23:21, Cj Malone
>  wrote:
> >
> > I was splitting houses in Portsmouth/Southsea this morning.
> The imagery
> > is great, I don't know if it was part of this update, or if
> it's been
> > like this for a while.
> >
> >
> > ___
> > 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
>
>
> ___
> 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
>
>
> ___
> 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


signature.asc
Description: OpenPGP digital signature
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Silent Spike
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 
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  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  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 

Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Colin Smale
On 2020-08-19 17:21, Russ Garrett wrote:

> On Wed, 19 Aug 2020 at 16:00, Colin Smale  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."
> 
> Well, that assumes that OS's locations are perfect, and that their
> data isn't subject to orthorectification errors and the like. It's
> still likely to be better than any other source, but I'd be surprised
> if there weren't similar errors in some of the OS data, especially in
> more rural & hilly areas.

Agree with this. 

Here's a thought: I doubt the OS use equipment that reads out directly
in OSGB36. I would think it it more likely that their equipment provides
(e.g.) WGS84 data which is then converted to OSGB36 before storing it in
the MasterMap database? I wonder what transformation errors are
introduced at that stage. If we reverse that transformation exactly, we
should arrive at the data as originally captured. 

> In my experience, once you start trying to go below 5m accuracy you
> swiftly learn not to trust anyone.

I can understand that, but it is not helping us forward... We need to
trust someone/something unless we think we can do better ourselves. I
tend to regard the OS as "sufficiently trustworthy" from my perspective
as a reasonably technically, mathematically competent person without any
specific inside knowledge of the OS. So if the OS say it's at {x,y} and
some other source says {x',y'} then I would presume that the OS is more
likely to be correct, and the other source would have to show me a damn
good provenance if it wants me to consider it better than the OS (and
thereby prompt me to move some feature in OSM).___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread David Woolley

On 19/08/2020 16:21, Russ Garrett wrote:

5m accuracy


You'll accumulate that error in a couple of centuries, just from 
continental drift: 
, 
given that OSM is referenced to WGS-84, not the British mainland.


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Stephen Colebourne
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  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  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
___
Talk-GB mailing 

Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Russ Garrett
On Wed, 19 Aug 2020 at 16:00, Colin Smale  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."

Well, that assumes that OS's locations are perfect, and that their
data isn't subject to orthorectification errors and the like. It's
still likely to be better than any other source, but I'd be surprised
if there weren't similar errors in some of the OS data, especially in
more rural & hilly areas.

In my experience, once you start trying to go below 5m accuracy you
swiftly learn not to trust anyone.

Cheers,

-- 
Russ Garrett
r...@garrett.co.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Colin Smale
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  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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Alan Mackie
On Wed, 19 Aug 2020 at 14:52, Jass Kurn  wrote:

>
> On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:
>
>> 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).
>>
> I've been coincidently wrestling with this issue of offsets for the last
> two days. New Bing imagery is resulting in very detailed and useful mapping
> (e.g. solar panels) but imagery is nearly always out by a problematic
> amount. I also feel the best source for offsets is not Streetview, but the
> vector data from OS OpenData. I've done some experimenting over the last
> two days, and my favourite source for alignment is "OS OpenData Local -
> Vector". Within those downloaded files is a data set called
> "FunctionalSite" which is primarily the boundaries of educational sites.
> They're excellent for alignment because the file is not too big, school
> sites are common, and the boundaries are commonly thin fences which are
> easy to align with Bing imagery, bringing errors to a trivial amount.
>
> I think the secondary useful task is to make offsets available using the
> "The Imagery Offset Database". It's been around for a long time, but is now
> way more useful due to the issues being discussed.
>
>  I think in an ideal world it would be good for the offset to be based on
a record of features detected within the imagery itself. If we were able to
generate these repeatably, then it may be possible to use the same control
points across different imagery and have a chance of self-correcting after
updates. In the real world this is probably too computationally expensive
for OSM editing software, even for the relatively "simple" features used in
panorama stitching software. I also have no idea if the license on the
imagery we have access to would allow this.


> With imagery likely to become more detailed, with more high quality
> tracing of the high quality but misaligned imagery, I think we'll need a
> more formal approach to "Align imagery before tracing guidelines"
>
> Jass
>
>
> ___
> 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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread SK53
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  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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Jass Kurn
On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:

> 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).
>
I've been coincidently wrestling with this issue of offsets for the last
two days. New Bing imagery is resulting in very detailed and useful mapping
(e.g. solar panels) but imagery is nearly always out by a problematic
amount. I also feel the best source for offsets is not Streetview, but the
vector data from OS OpenData. I've done some experimenting over the last
two days, and my favourite source for alignment is "OS OpenData Local -
Vector". Within those downloaded files is a data set called
"FunctionalSite" which is primarily the boundaries of educational sites.
They're excellent for alignment because the file is not too big, school
sites are common, and the boundaries are commonly thin fences which are
easy to align with Bing imagery, bringing errors to a trivial amount.

I think the secondary useful task is to make offsets available using the
"The Imagery Offset Database". It's been around for a long time, but is now
way more useful due to the issues being discussed.

With imagery likely to become more detailed, with more high quality tracing
of the high quality but misaligned imagery, I think we'll need a more
formal approach to "Align imagery before tracing guidelines"

Jass
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Oliver Simmons
“I would like it if the iD 'adjust imagery tool' button were more visible.”I agree on this, it needs to be more prominent and ideally iD would make it’s users align the imagery before letting them edit. Dose iD’s tutorial/guide teach about offsets?If not I think it should as they are very important  when editing from imagery and I imagine most iD mappers do this. (Sorry if I mess this email up I’m new to how mailing list emails work.)Sent from Mail for Windows 10 From: Alan MackieSent: 19 August 2020 10:53To: Stephen ColebourneCc: Talk-GBSubject: Re: [Talk-GB] New Bing Imagery  On Wed, 19 Aug 2020, 10:13 Stephen Colebourne, <scolebou...@joda.org> wrote:So, I followed the links below and added an offset. But this simplyisn't a viable solution to the problem because it only works for JOSMand not iD.I managed to convince one mapper to type in the offset manually in iDevery time, but that is a horrible thing to ask new mappers to do,very offputting. And now I can see Amazon mappers using an iD variantthat 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/89549551This is going to keep happening so long as OSM has multiple imagesources and multiple editors. Frankly I'm amazed that this isn't asolved problem.Imagery isn't one image. There are carefully blended seams that often include jumps if you look closely. There is also no guarantee that distortion to "flatten" hills etc. We also tend to receive no metadata about where the seams are, or how they were distorted. It is not an easy problem to solve. Having done some mapping across the country recently, it seems likeBing is offset to the previous best imagery across the country, but byvarying amounts. Is there really no solution that can be applied tothe source Bing layer? Or should we all just accept Bing as golden?I think we tend to accept OS's StreetView as the best source for position. Having added thousands of buildings and fixed roads to align to theprevious best imagery, I don't have a good solution to the problem,and it is demotivating to think that others are going to come alongand move individual roads/buildings to align without considering thebigger picture.Poorly considered hit and run mapping will happen regardless of the imagery.  At least talk-gb doesn't have to deal with those with "humanitarian" inspiration. These can be prolific and sometime give the impression they are too busy "helping people" to read even basic instructions. (Especially the ones who go off piste)The only solution I can think of is to move all nodes in the area I'veworked on to match the new Bing (ie a mass edit). Any othersuggestions?Readjusting every time a source updates is not a good solution. It assumes there is one "authoritative" source and would become and endless task. I would like it if the iD 'adjust imagery tool' button were more visible.StephenOn Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB<talk-gb@openstreetmap.org> wrote:>> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database> (I think that nowadays it is built in - is plugin installation still necessary?)>>> No idea about iD support - https://github.com/openstreetmap/iD/search?q=imagery+offset>> Jul 13, 2020, 00:21 by scolebou...@joda.org:>> Wow, the imagery is really good. But in my area the imagery is about> 3-4m east west and 3-4m north south out of alignment with Esri World> Imagery (Clarity) Beta, which is what I've been using up until now> (for thousands of buildings).> https://www.openstreetmap.org/#map=18/51.39886/-0.24940>> Is there any way to unify the alignments?>> Stephen>>> On Thu, 9 Jul 2020 at 06:41, Gareth L <o...@live.co.uk> wrote:>>> I’ve noticed patches of vastly improved bing imagery since December, but it is really patchy.> Gareth>> > On 6 Jul 2020, at 23:21, Cj Malone <me-osm-talk...@keepawayfromfire.co.uk> wrote:> >> > I was splitting houses in Portsmouth/Southsea this morning. The imagery> > is great, I don't know if it was part of this update, or if it's been> > like this for a while.> >> >> > ___> > 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>>> ___> Talk-GB mailing list> Talk-GB@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-gb>>> 

Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Colin Smale
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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Mateusz Konieczny via Talk-GB



19 Aug 2020, 12:17 by ajt1...@gmail.com:
> To be honest, I'd never trust any imagery anywhere until I've seen how it 
> compares with other available sources in that area (GPS traces, OS OpenData 
> StreetView, etc.).
>
Not sure is there such dataset in UK,
but Polish government releases
aerial images with alignment better than
GPS traces from smartphones and
comparable with GPS traces from 
dedicated receivers (such as Garmin
etrex)___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Andy Townsend

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.


If, after being told about the problem, people are ignoring the advice 
and just banging in roads with incorrect alignments then please email 
the DWG at d...@osmfoundation.org about it.  However if people haven't 
ever been told what the best practice for a country (especially if they 
edit in lots of countries) is it's not really fair to criticise.


One other thing that I have noticed is that the imagery behind the "AI" 
detection that they have been using in some places in the UK is among 
the worst available, and I've suggested where I've seen stuff added on 
that alignment that it's wrong and needs fixing.



This is going to keep happening so long as OSM has multiple image
sources and multiple editors. Frankly I'm amazed that this isn't a
solved problem.
I don't think that it ever will be a solved problem, because the level 
of accuracy that we're worrying about in OSM has changed over the 
years.  About 12 years people were adding features from out of copyright 
maps such as NPE that sometimes might have been 200m out, or adding 
stuff with a bit of guesswork from Yahoo imagery that might be similarly 
inaccurate.  Now we're worried about 2m here or there, in 10 years time 
it'll be blades of grass(!).


Having done some mapping across the country recently, it seems like
Bing is offset to the previous best imagery across the country, but by
varying amounts. Is there really no solution that can be applied to
the source Bing layer?


If there is, it'll be Bing that does it rather than us.  When Bing was 
"new" to OSM in 2012 or so there were lots of odd offset issues in Bing 
imagery and these were sorted out over time.  I suspect that that will 
happen again.


To be honest, I'd never trust any imagery anywhere until I've seen how 
it compares with other available sources in that area (GPS traces, OS 
OpenData StreetView, etc.).


Best Regards,

Andy



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Russ Garrett
For what it's worth, I feel like Bing has less offset overall. A lot
of south London has been aligned to the previous Bing imagery which is
almost certainly worse than the current Bing imagery. My impression is
that Bing is "more correct" than most other imagery sources.

Unfortunately the levels of error we're looking at are approaching the
margin of error of most GPS receivers, so GPS tracks, while sometimes
helpful, are not the solution to this either. As Alan says, OS
StreetView is probably the best reference in most cases.

The new Bing imagery seems to have less offset from StreetView in most
cases, but it does still have offset (and often in the opposite
direction from the old Bing imagery...).

Cheers,

Russ

On Wed, 19 Aug 2020 at 10:20, Mateusz Konieczny via Talk-GB
 wrote:
>
> Have you checked whatever
> there is an open issue proposing to
> support imagery offset database in iD?
>
>
> 19 Aug 2020, 11:11 by scolebou...@joda.org:
>
> So, I followed the links below and added an offset. But this simply
> isn't a viable solution to the problem because it only works for JOSM
> and not iD.
>
> I managed to convince one mapper to type in the offset manually in iD
> every time, but that is a horrible thing to ask new mappers to do,
> very offputting. 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
> This is going to keep happening so long as OSM has multiple image
> sources and multiple editors. Frankly I'm amazed that this isn't a
> solved problem.
>
> Having done some mapping across the country recently, it seems like
> Bing is offset to the previous best imagery across the country, but by
> varying amounts. Is there really no solution that can be applied to
> the source Bing layer? Or should we all just accept Bing as golden?
>
> Having added thousands of buildings and fixed roads to align to the
> previous best imagery, I don't have a good solution to the problem,
> and it is demotivating to think that others are going to come along
> and move individual roads/buildings to align without considering the
> bigger picture.
>
> The only solution I can think of is to move all nodes in the area I've
> worked on to match the new Bing (ie a mass edit). Any other
> suggestions?
>
> Stephen
>
>
>
>
>
>
>
>
>
>
> On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
>  wrote:
>
>
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
> (I think that nowadays it is built in - is plugin installation still 
> necessary?)
>
>
> No idea about iD support - 
> https://github.com/openstreetmap/iD/search?q=imagery+offset
>
> Jul 13, 2020, 00:21 by scolebou...@joda.org:
>
> Wow, the imagery is really good. But in my area the imagery is about
> 3-4m east west and 3-4m north south out of alignment with Esri World
> Imagery (Clarity) Beta, which is what I've been using up until now
> (for thousands of buildings).
> https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>
> Is there any way to unify the alignments?
>
> Stephen
>
>
> On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>
>
> I’ve noticed patches of vastly improved bing imagery since December, but it 
> is really patchy.
> Gareth
>
> > On 6 Jul 2020, at 23:21, Cj Malone  
> > wrote:
> >
> > I was splitting houses in Portsmouth/Southsea this morning. The imagery
> > is great, I don't know if it was part of this update, or if it's been
> > like this for a while.
> >
> >
> > ___
> > 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
>
>
> ___
> 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
>
>
> ___
> 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



-- 
Russ Garrett
r...@garrett.co.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Alan Mackie
On Wed, 19 Aug 2020 at 10:51, Alan Mackie  wrote:

>
>
> On Wed, 19 Aug 2020, 10:13 Stephen Colebourne, 
> wrote:
>
>> So, I followed the links below and added an offset. But this simply
>> isn't a viable solution to the problem because it only works for JOSM
>> and not iD.
>>
>> I managed to convince one mapper to type in the offset manually in iD
>> every time, but that is a horrible thing to ask new mappers to do,
>> very offputting. 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
>> This is going to keep happening so long as OSM has multiple image
>> sources and multiple editors. Frankly I'm amazed that this isn't a
>> solved problem.
>>
> Imagery isn't one image. There are carefully blended seams that often
> include jumps if you look closely. There is also no guarantee that
> distortion to "flatten" hills etc. We also tend to receive no metadata
> about where the seams are, or how they were distorted. It is not an easy
> problem to solve.
>
Sorry the above should have read:
  Imagery isn't one image. There are carefully blended seams that often
include jumps if you look closely. There is also no guarantee that
distortion to "flatten" hills etc. *has resulted in a consistent offset*.
We also tend to receive no metadata about where the seams are, or how they
were distorted. It is not an easy problem to solve.

>
>

>> Having done some mapping across the country recently, it seems like
>> Bing is offset to the previous best imagery across the country, but by
>> varying amounts. Is there really no solution that can be applied to
>> the source Bing layer? Or should we all just accept Bing as golden?
>>
> I think we tend to accept OS's StreetView as the best source for position.
>
>>
>> Having added thousands of buildings and fixed roads to align to the
>> previous best imagery, I don't have a good solution to the problem,
>> and it is demotivating to think that others are going to come along
>> and move individual roads/buildings to align without considering the
>> bigger picture.
>>
> Poorly considered hit and run mapping will happen regardless of the
> imagery.
>
> At least talk-gb doesn't have to deal with those with "humanitarian"
> inspiration. These can be prolific and sometime give the impression they
> are too busy "helping people" to read even basic instructions. (Especially
> the ones who go off piste)
>
>>
>> The only solution I can think of is to move all nodes in the area I've
>> worked on to match the new Bing (ie a mass edit). Any other
>> suggestions?
>>
> Readjusting every time a source updates is not a good solution. It assumes
> there is one "authoritative" source and would become and endless task.
>
> I would like it if the iD 'adjust imagery tool' button were more visible.
>
>>
>> Stephen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
>>  wrote:
>> >
>> >
>> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
>> > https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
>> > (I think that nowadays it is built in - is plugin installation still
>> necessary?)
>> >
>> >
>> > No idea about iD support -
>> https://github.com/openstreetmap/iD/search?q=imagery+offset
>> >
>> > Jul 13, 2020, 00:21 by scolebou...@joda.org:
>> >
>> > Wow, the imagery is really good. But in my area the imagery is about
>> > 3-4m east west and 3-4m north south out of alignment with Esri World
>> > Imagery (Clarity) Beta, which is what I've been using up until now
>> > (for thousands of buildings).
>> > https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>> >
>> > Is there any way to unify the alignments?
>> >
>> > Stephen
>> >
>> >
>> > On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>> >
>> >
>> > I’ve noticed patches of vastly improved bing imagery since December,
>> but it is really patchy.
>> > Gareth
>> >
>> > > On 6 Jul 2020, at 23:21, Cj Malone <
>> me-osm-talk...@keepawayfromfire.co.uk> wrote:
>> > >
>> > > I was splitting houses in Portsmouth/Southsea this morning. The
>> imagery
>> > > is great, I don't know if it was part of this update, or if it's been
>> > > like this for a while.
>> > >
>> > >
>> > > ___
>> > > 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
>> >
>> >
>> > ___
>> > Talk-GB mailing list
>> > Talk-GB@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-gb
>> >
>> >
>> > ___
>> > Talk-GB mailing list
>> > 

Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Alan Mackie
On Wed, 19 Aug 2020, 10:13 Stephen Colebourne,  wrote:

> So, I followed the links below and added an offset. But this simply
> isn't a viable solution to the problem because it only works for JOSM
> and not iD.
>
> I managed to convince one mapper to type in the offset manually in iD
> every time, but that is a horrible thing to ask new mappers to do,
> very offputting. 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
> This is going to keep happening so long as OSM has multiple image
> sources and multiple editors. Frankly I'm amazed that this isn't a
> solved problem.
>
Imagery isn't one image. There are carefully blended seams that often
include jumps if you look closely. There is also no guarantee that
distortion to "flatten" hills etc. We also tend to receive no metadata
about where the seams are, or how they were distorted. It is not an easy
problem to solve.


> Having done some mapping across the country recently, it seems like
> Bing is offset to the previous best imagery across the country, but by
> varying amounts. Is there really no solution that can be applied to
> the source Bing layer? Or should we all just accept Bing as golden?
>
I think we tend to accept OS's StreetView as the best source for position.

>
> Having added thousands of buildings and fixed roads to align to the
> previous best imagery, I don't have a good solution to the problem,
> and it is demotivating to think that others are going to come along
> and move individual roads/buildings to align without considering the
> bigger picture.
>
Poorly considered hit and run mapping will happen regardless of the
imagery.

At least talk-gb doesn't have to deal with those with "humanitarian"
inspiration. These can be prolific and sometime give the impression they
are too busy "helping people" to read even basic instructions. (Especially
the ones who go off piste)

>
> The only solution I can think of is to move all nodes in the area I've
> worked on to match the new Bing (ie a mass edit). Any other
> suggestions?
>
Readjusting every time a source updates is not a good solution. It assumes
there is one "authoritative" source and would become and endless task.

I would like it if the iD 'adjust imagery tool' button were more visible.

>
> Stephen
>
>
>
>
>
>
>
>
>
>
> On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
>  wrote:
> >
> >
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
> > https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
> > (I think that nowadays it is built in - is plugin installation still
> necessary?)
> >
> >
> > No idea about iD support -
> https://github.com/openstreetmap/iD/search?q=imagery+offset
> >
> > Jul 13, 2020, 00:21 by scolebou...@joda.org:
> >
> > Wow, the imagery is really good. But in my area the imagery is about
> > 3-4m east west and 3-4m north south out of alignment with Esri World
> > Imagery (Clarity) Beta, which is what I've been using up until now
> > (for thousands of buildings).
> > https://www.openstreetmap.org/#map=18/51.39886/-0.24940
> >
> > Is there any way to unify the alignments?
> >
> > Stephen
> >
> >
> > On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
> >
> >
> > I’ve noticed patches of vastly improved bing imagery since December, but
> it is really patchy.
> > Gareth
> >
> > > On 6 Jul 2020, at 23:21, Cj Malone <
> me-osm-talk...@keepawayfromfire.co.uk> wrote:
> > >
> > > I was splitting houses in Portsmouth/Southsea this morning. The
> imagery
> > > is great, I don't know if it was part of this update, or if it's been
> > > like this for a while.
> > >
> > >
> > > ___
> > > 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
> >
> >
> > ___
> > 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
>
> ___
> 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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Mateusz Konieczny via Talk-GB
Have you checked whatever
there is an open issue proposing to
support imagery offset database in iD?

19 Aug 2020, 11:11 by scolebou...@joda.org:

> So, I followed the links below and added an offset. But this simply
> isn't a viable solution to the problem because it only works for JOSM
> and not iD.
>
> I managed to convince one mapper to type in the offset manually in iD
> every time, but that is a horrible thing to ask new mappers to do,
> very offputting. 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
> This is going to keep happening so long as OSM has multiple image
> sources and multiple editors. Frankly I'm amazed that this isn't a
> solved problem.
>
> Having done some mapping across the country recently, it seems like
> Bing is offset to the previous best imagery across the country, but by
> varying amounts. Is there really no solution that can be applied to
> the source Bing layer? Or should we all just accept Bing as golden?
>
> Having added thousands of buildings and fixed roads to align to the
> previous best imagery, I don't have a good solution to the problem,
> and it is demotivating to think that others are going to come along
> and move individual roads/buildings to align without considering the
> bigger picture.
>
> The only solution I can think of is to move all nodes in the area I've
> worked on to match the new Bing (ie a mass edit). Any other
> suggestions?
>
> Stephen
>
>
>
>
>
>
>
>
>
>
> On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
>  wrote:
>
>>
>> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
>> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
>> (I think that nowadays it is built in - is plugin installation still 
>> necessary?)
>>
>>
>> No idea about iD support - 
>> https://github.com/openstreetmap/iD/search?q=imagery+offset
>>
>> Jul 13, 2020, 00:21 by scolebou...@joda.org:
>>
>> Wow, the imagery is really good. But in my area the imagery is about
>> 3-4m east west and 3-4m north south out of alignment with Esri World
>> Imagery (Clarity) Beta, which is what I've been using up until now
>> (for thousands of buildings).
>> https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>>
>> Is there any way to unify the alignments?
>>
>> Stephen
>>
>>
>> On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>>
>>
>> I’ve noticed patches of vastly improved bing imagery since December, but it 
>> is really patchy.
>> Gareth
>>
>> > On 6 Jul 2020, at 23:21, Cj Malone  
>> > wrote:
>> >
>> > I was splitting houses in Portsmouth/Southsea this morning. The imagery
>> > is great, I don't know if it was part of this update, or if it's been
>> > like this for a while.
>> >
>> >
>> > ___
>> > 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
>>
>>
>> ___
>> 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
>>
>
> ___
> 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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Thread Stephen Colebourne
So, I followed the links below and added an offset. But this simply
isn't a viable solution to the problem because it only works for JOSM
and not iD.

I managed to convince one mapper to type in the offset manually in iD
every time, but that is a horrible thing to ask new mappers to do,
very offputting. 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
This is going to keep happening so long as OSM has multiple image
sources and multiple editors. Frankly I'm amazed that this isn't a
solved problem.

Having done some mapping across the country recently, it seems like
Bing is offset to the previous best imagery across the country, but by
varying amounts. Is there really no solution that can be applied to
the source Bing layer? Or should we all just accept Bing as golden?

Having added thousands of buildings and fixed roads to align to the
previous best imagery, I don't have a good solution to the problem,
and it is demotivating to think that others are going to come along
and move individual roads/buildings to align without considering the
bigger picture.

The only solution I can think of is to move all nodes in the area I've
worked on to match the new Bing (ie a mass edit). Any other
suggestions?

Stephen










On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
 wrote:
>
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
> (I think that nowadays it is built in - is plugin installation still 
> necessary?)
>
>
> No idea about iD support - 
> https://github.com/openstreetmap/iD/search?q=imagery+offset
>
> Jul 13, 2020, 00:21 by scolebou...@joda.org:
>
> Wow, the imagery is really good. But in my area the imagery is about
> 3-4m east west and 3-4m north south out of alignment with Esri World
> Imagery (Clarity) Beta, which is what I've been using up until now
> (for thousands of buildings).
> https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>
> Is there any way to unify the alignments?
>
> Stephen
>
>
> On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>
>
> I’ve noticed patches of vastly improved bing imagery since December, but it 
> is really patchy.
> Gareth
>
> > On 6 Jul 2020, at 23:21, Cj Malone  
> > wrote:
> >
> > I was splitting houses in Portsmouth/Southsea this morning. The imagery
> > is great, I don't know if it was part of this update, or if it's been
> > like this for a while.
> >
> >
> > ___
> > 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
>
>
> ___
> 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

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-07-12 Thread Mateusz Konieczny via Talk-GB
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
(I think that nowadays it is built in - is plugin installation still necessary?)


No idea about iD support - 
https://github.com/openstreetmap/iD/search?q=imagery+offset

Jul 13, 2020, 00:21 by scolebou...@joda.org:

> Wow, the imagery is really good. But in my area the imagery is about
> 3-4m east west and 3-4m north south out of alignment with Esri World
> Imagery (Clarity) Beta, which is what I've been using up until now
> (for thousands of buildings).
> https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>
> Is there any way to unify the alignments?
>
> Stephen
>
>
> On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>
>>
>> I’ve noticed patches of vastly improved bing imagery since December, but it 
>> is really patchy.
>> Gareth
>>
>> > On 6 Jul 2020, at 23:21, Cj Malone  
>> > wrote:
>> >
>> > I was splitting houses in Portsmouth/Southsea this morning. The imagery
>> > is great, I don't know if it was part of this update, or if it's been
>> > like this for a while.
>> >
>> >
>> > ___
>> > 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
>>
>
> ___
> 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


Re: [Talk-GB] New Bing Imagery

2020-07-12 Thread Stephen Colebourne
Wow, the imagery is really good. But in my area the imagery is about
3-4m east west and 3-4m north south out of alignment with Esri World
Imagery (Clarity) Beta, which is what I've been using up until now
(for thousands of buildings).
https://www.openstreetmap.org/#map=18/51.39886/-0.24940

Is there any way to unify the alignments?

Stephen


On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>
> I’ve noticed patches of vastly improved bing imagery since December, but it 
> is really patchy.
> Gareth
>
> > On 6 Jul 2020, at 23:21, Cj Malone  
> > wrote:
> >
> > I was splitting houses in Portsmouth/Southsea this morning. The imagery
> > is great, I don't know if it was part of this update, or if it's been
> > like this for a while.
> >
> >
> > ___
> > 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

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-07-08 Thread Gareth L
I’ve noticed patches of vastly improved bing imagery since December, but it is 
really patchy.
Gareth

> On 6 Jul 2020, at 23:21, Cj Malone  
> wrote:
> 
> I was splitting houses in Portsmouth/Southsea this morning. The imagery
> is great, I don't know if it was part of this update, or if it's been
> like this for a while.
> 
> 
> ___
> 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


Re: [Talk-GB] New Bing Imagery

2020-07-06 Thread Cj Malone
I was splitting houses in Portsmouth/Southsea this morning. The imagery
is great, I don't know if it was part of this update, or if it's been
like this for a while.


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb