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

Thu Dec 13 11:55:40 UTC 2018

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, <talk-gb-request at openstreetmap.org> wrote:

> Send Talk-GB mailing list submissions to
>         talk-gb at 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-request at openstreetmap.org
>
> You can reach the person managing the list at
>         talk-gb-owner at 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 <rmb at libarch.co.uk>
> To: talk-gb at openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 18:10:24 +0000
> 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 <https://www.openstreetmap.org/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
> <https://www.openstreetmap.org/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 <colin.smale at xs4all.nl>
> To: talk-gb at 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 slightly different results (it's a complex subject).
>
> If you look at the two almost-parallel ways
> https://www.openstreetmap.org/way/99620586 and
> https://www.openstreetmap.org/way/651749133 your (political) boundary
> coincides exactly with my OSBL data for the boundary of Trafford District.
> So to my mind it is clear that the Trafford/Manchester boundary here should
> be updated to follow your line. The existing T/M boundary way is 8 years
> old and many nodes appear to have been "tweaked" manually. This may have
> been an attempt to achieve a certain alignment with other objects or aerial
> imagery. Personally I trust the data imported from OSBL more than imagery,
> as the OS data has been surveyed/maintained to centimetre accuracy whereas
> the imagery is known to suffer from distortions and positional errors of
> (in some cases) tens of metres.
>
> As to boundaries following the line of a river, this is more difficult.
> The legal definition of most boundaries is (these days) "the line on the
> map" held by some government. When a boundary change order is made normally
> the definition of the boundary is included as a map with some lines drawn
> on it. If a line follows a river today, and the river subsequently changes
> course, then the legal boundary doesn't move with the river. Similarly when
> it appears to follow the centre line of a road. If a junction gets
> realigned or a roundabout built, the boundary doesn't move. The definitive
> maps are held at such a large scale that you can see if a boundary is on
> the left or the right of a paving stone in the pavement..
>
> I would be tempted to update all the local boundaries to the latest OSBL
> data, not linking the ways to any other object like roads or rivers, in
> order to get consistent coverage.
>
>
> Regards,
>
> Colin
>
> On 2018-12-12 19:10, Rick Bowlby wrote:
>
> Hello, I quite recently imported Ordnance Survey Boundary-Line data
> (October 2018, OGL v3) for recently changed electoral wards in Manchester (changeset
> 65101926 <https://www.openstreetmap.org/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
> <https://www.openstreetmap.org/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
>
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
>
>
> ---------- Forwarded message ----------
> From: ael <law_ence.dev at ntlworld.com>
> To: talk-gb at openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 23:11:52 +0000
> Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
> On Wed, Dec 12, 2018 at 06:10:24PM +0000, Rick Bowlby wrote:
> > Hello, I quite recently imported Ordnance Survey Boundary-Line data
> > (October 2018, OGL v3) for recently changed electoral wards in
> > Manchester (changeset
> > 65101926 <https://www.openstreetmap.org/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 <https://www.openstreetmap.org/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.
>
> This is perhaps slightly off topic, but this habit of some of sharing
> nodes causes me many problems. When I am updating roads and other
> features from fairly accurate gps surveys, I often find the I have all
> these tangled boundaries about which I know little. It is a huge pain
> to duplicate nodes to separate ways before I can adjust just the feature
> that I have surveyed. I confess that my patience often runs out, and I
> just drag the other stuff along with my updates, thinking that the
> mappers who shared the nodes in the first place get what they deserve
> :-).
>
> So I may be responsible indirectly for some minor inaccuracies of
> certain boundaries, although nowhere near Manchester.
>
> I am normally extremely respectful of other mappers' work, but this is
> one area where I find that it is just too difficult to avoid possible
> minor damage. Maybe I just haven't found the right tools.
>
> ael
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Mark Goodge <mark at good-stuff.co.uk>
> To: talk-gb at openstreetmap.org
> Cc:
> Bcc:
> Date: Thu, 13 Dec 2018 11:22:58 +0000
> Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
>
>
> On 12/12/2018 23:11, ael wrote:
>
> > This is perhaps slightly off topic, but this habit of some of sharing
> > nodes causes me many problems. When I am updating roads and other
> > features from fairly accurate gps surveys, I often find the I have all
> > these tangled boundaries about which I know little. It is a huge pain
> > to duplicate nodes to separate ways before I can adjust just the feature
> > that I have surveyed. I confess that my patience often runs out, and I
> > just drag the other stuff along with my updates, thinking that the
> > mappers who shared the nodes in the first place get what they deserve
> > :-).
>
> I agree. I tried to fix the outline of a park that's just down the road
> from me. It's clearly incorrect when viewed on the satellite view in the
> editor, and I thought it would be a relatively simple task of dragging
> the nodes to match reality. But it turns out that the nodes down one
> side are shared with a river that's adjacent to the park, and down
> another side with a road that is almost, but not quite, directly
> adjacent to the park. Sharing nodes with that road makes the park look
> bigger than it actually is, and, more importantly, makes a building
> that, in reality, is on the boundary of the park appear to be wholly
> within it. I thought I could simply drag the nodes to the correct
> position, but I can't without also moving the road, which would be
> equally incorrect.
>
> It would make far more sense if the boundaries of the park were a single
> set of nodes and ways not shared with any other object. When I've got
> considerably more tuits to spare I may just do that - delete the park
> completely and then recreate it from scratch as a new object with its
> own nodes and ways. But, at the moment, I don't really have the time. So
> I've left it, and it continues to irritate me every time I look at it on
> the map :-)
>
> Mark
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andy G Wood <agw at bas.ac.uk>
> To: talk-gb at openstreetmap.org
> Cc:
> Bcc:
> Date: Thu, 13 Dec 2018 11:38:54 +0000
> Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
> On Thursday, 13 December 2018 11:22:58 GMT Mark Goodge wrote:
> > On 12/12/2018 23:11, ael wrote:
> > > This is perhaps slightly off topic, but this habit of some of sharing
> > > nodes causes me many problems. When I am updating roads and other
> > > features from fairly accurate gps surveys, I often find the I have all
> > > these tangled boundaries about which I know little. It is a huge pain
> > > to duplicate nodes to separate ways before I can adjust just the
> feature
> > > that I have surveyed. I confess that my patience often runs out, and I
> > > just drag the other stuff along with my updates, thinking that the
> > > mappers who shared the nodes in the first place get what they deserve
> > >
> > > :-).
> >
> > I agree. [...]
>
> I also wholeheartedly agree.
> However I think this problem is not helped by the fact that the iD editor,
> by
> default, will snap to nearest points.  You may be able to change this (?),
> but
> I have kept with the defaults, so this will be a "feature" that many
> mappers
> just go with as the accepted norm.
>
> Andy.
>
>
>
>
>
> _______________________________________________
> 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/20181213/5754aebc/attachment-0001.html>