[Talk-GB] OS Boundary-Line - Manchester political wards and related boundaries, dealing with inconsistent data

Thu Dec 13 12:17:19 UTC 2018

I've been mapping for 5 years and I still use iD 95% of the time—because it
just gets stuff done quickly and visually—so it's not just for newbies!
Snapping to nodes isn't a problem per se but the implications of doing so
can be. I've lost count of the times I've encountered roads with adjoining
landuse boundaries that go right up to the centre line of the way rather
than stopping at the kerb/pavement edge. Unpicking all those nodes is
doable in iD but it's a slow and thankless task, and that's with clear and
unambiguous boundaries, never mind administrative or other invisible ones.

(It'd be nice if there were an intermediate OSM editor sitting somewhere on
the skill/complexity curve between iD and JOSM.)

Regards,
*Paul*

On Thu, 13 Dec 2018 at 12:08, Edward Bainton <bainton.ete at gmail.com> wrote:

> As a new mapper around just long enough to know that I've made some crass
> newbie mistakes already [point in case, just replied without editing the
> subject line... apologies!], 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.
>
> E
>
> 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
>>
> _______________________________________________
> 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/8a5b720b/attachment-0001.html>