Re: [Talk-GB] Talk-GB Digest, Vol 147, Issue 6

[Nick Allen]

Hi All,
When using iD you can stop it 'snapping' to a nearby feature by holding
down the 'Alt' key whilst drawing the feature. 
This wiki list may help with some of the other shortcuts - possibly D
will help with shared nodes (not sure on that one, I've never used it):
 https://wiki.openstreetmap.org/wiki/ID/Shortcuts
Regards
Nick (Tallguy)
On Thu, 2018-12-13 at 11:55 +, Edward Bainton wrote:
> As a new mapper around just long enough to know that I've made some
> crass newbie mistakes already, I agree with Andy. The iD editor is
> the the go-to editor for newbies, myself included, and the snap
> feature is so apparent in the UX that I have regularly taken its
> steer and made new objects follow old nodes.
> Presumably it would be possible to have some 'sticky' features that
> aren't so easily modified - these boundaries would seem to be a good
> candidate; so would roads when they've been rigorously established
> from multiple data sources.
> 
> And/or perhaps a warning in iD that flags the pros and cons of
> snapping to existing nodes, and/or gives the option of a bulk-
> undo/bulk-disconnect if you've done that and thought better of it.
> 
> On Thu, 13 Dec 2018 at 11:39, 
> wrote:
> > Send Talk-GB mailing list submissions to
> > 
> > talk-gb@openstreetmap.org
> > 
> > 
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 
> > https://lists.openstreetmap.org/listinfo/talk-gb
> > 
> > or, via email, send a message with subject or body 'help' to
> > 
> > talk-gb-requ...@openstreetmap.org
> > 
> > 
> > 
> > You can reach the person managing the list at
> > 
> > talk-gb-ow...@openstreetmap.org
> > 
> > 
> > 
> > When replying, please edit your Subject line so it is more specific
> > 
> > than "Re: Contents of Talk-GB digest..."
> > 
> > Today's Topics:
> > 
> > 
> > 
> >1. OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (Rick Bowlby)
> > 
> >2. Re: OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (Colin Smale)
> > 
> >3. Re: OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (ael)
> > 
> >4. Re: OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (Mark Goodge)
> > 
> >5. Re: OS Boundary-Line - Manchester political wards and   
> >  related
> > 
> >   boundaries, dealing with inconsistent data (Andy G Wood)
> > 
> > 
> > 
> > 
> > -- Forwarded message --
> > From: Rick Bowlby 
> > To: talk-gb@openstreetmap.org
> > Cc: 
> > Bcc: 
> > Date: Wed, 12 Dec 2018 18:10:24 +
> > Subject: [Talk-GB] OS Boundary-Line - Manchester political wards
> > and related boundaries, dealing with inconsistent data
> > Hello, I quite recently imported Ordnance Survey Boundary-Line data
> > (October 2018, OGL v3) for recently changed electoral wards in
> > Manchester (changeset 65101926). I hope this isn't controversial -
> > these boundaries are useful to me and potentially others as well,
> > and I understand that the OGL is compatible with OSM.
> > 
> > But I've now noticed that the 
> > outer boundary of the wards is not coincident with the current
> > administrative boundary for Manchester City Council in OSM
> > (relation 146656) - as far as I can see, the discrepancies are up
> > to about 5m or so. However it is consistent with the city boundary
> > in the same OS dataset. The sources for the existing OSM data seem
> > to be mixed - there are references to Ordnance Survey sources
> > (without dates), in some places the boundary ways are rivers, there
> > are also references to the "historic course" of a river and so on.
> > 
> > So I'm a bit out of my depth here. As things stand in the OSM data,
> > there are slivers of land all around the periphery which are in
> > Manchester but not in any ward in Manchester, or vice versa, which
> > can't be right. Plus there are data in OSM which are labeled as
> > sourced from OS Boundary-Line but which are not consistent with the
> > latest data from that source. The problem is that there are
> > numerous boundary relations sharing nodes (neighbouring
> > authorities, counties, "historic counties" etc) and cleaning all
> > this up - even if I was confident about where or whether the latest
> > OS data has priority - would be quite tricky, not to say time
> > consuming.
> > 
> > So would it be best to leave things as they are, inconsistencies
> > and all?
> > 
> > Thanks
> > 
> > 
> > 
> > 
> > -- Forwarded message --
> > From: Colin Smale 
> > To: talk-gb@openstreetmap.org
> > Cc: 
> > Bcc: 
> > Date: Wed, 12 Dec 2018 22:05:51 +0100
> > Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political
> > wards and related boundaries, dealing with inconsistent data
> > 
> > Hi Rick,
> > As you can probably guess the 

Re: [Talk-GB] Talk-GB Digest, Vol 147, Issue 6

[Edward Bainton]

As a new mapper around just long enough to know that I've made some crass
newbie mistakes already, I agree with Andy. The iD editor is the the go-to
editor for newbies, myself included, and the snap feature is so apparent in
the UX that I have regularly taken its steer and made new objects follow
old nodes.

Presumably it would be possible to have some 'sticky' features that aren't
so easily modified - these boundaries would seem to be a good candidate; so
would roads when they've been rigorously established from multiple data
sources.

And/or perhaps a warning in iD that flags the pros and cons of snapping to
existing nodes, and/or gives the option of a bulk-undo/bulk-disconnect if
you've done that and thought better of it.

On Thu, 13 Dec 2018 at 11:39,  wrote:

> Send Talk-GB mailing list submissions to
> talk-gb@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-gb
> or, via email, send a message with subject or body 'help' to
> talk-gb-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-gb-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-GB digest..."
> Today's Topics:
>
>1. OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Rick Bowlby)
>2. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Colin Smale)
>3. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (ael)
>4. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Mark Goodge)
>5. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Andy G Wood)
>
>
>
> -- Forwarded message --
> From: Rick Bowlby 
> To: talk-gb@openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 18:10:24 +
> Subject: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
> Hello, I quite recently imported Ordnance Survey Boundary-Line data
> (October 2018, OGL v3) for recently changed electoral wards in Manchester 
> (changeset
> 65101926 ). I hope this
> isn't controversial - these boundaries are useful to me and potentially
> others as well, and I understand that the OGL is compatible with OSM.
>
> But I've now noticed that the outer boundary of the wards is not
> coincident with the current administrative boundary for Manchester City
> Council in OSM (relation 146656
> ) - as far as I can see,
> the discrepancies are up to about 5m or so. However it is consistent with
> the city boundary in the same OS dataset. The sources for the existing OSM
> data seem to be mixed - there are references to Ordnance Survey sources
> (without dates), in some places the boundary ways are rivers, there are
> also references to the "historic course" of a river and so on.
>
> So I'm a bit out of my depth here. As things stand in the OSM data, there
> are slivers of land all around the periphery which are in Manchester but
> not in any ward in Manchester, or vice versa, which can't be right. Plus
> there are data in OSM which are labeled as sourced from OS Boundary-Line
> but which are not consistent with the latest data from that source. The
> problem is that there are numerous boundary relations sharing nodes
> (neighbouring authorities, counties, "historic counties" etc) and cleaning
> all this up - even if I was confident about where or whether the latest OS
> data has priority - would be quite tricky, not to say time consuming.
>
> So would it be best to leave things as they are, inconsistencies and all?
>
> Thanks
>
>
>
> -- Forwarded message --
> From: Colin Smale 
> To: talk-gb@openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 22:05:51 +0100
> Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
>
> Hi Rick,
>
> As you can probably guess the whole of the country is divided into wards,
> which are subdivisions of council areas for electoral (and not
> administrative) purposes. The slivers are not correct of course - they are
> artefacts of the fact that the different boundaries have been created from
> different data sets, or at different times, using different levels of
> generalisation, or using different transformations. The latter is important
> as the data published by the OS uses the National Grid as its datum, and
> has to be converted to the latitude/longitude format used by OSM. This
> conversion is actually rather complicated, and different implementations
> can give