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-requ...@openstreetmap.org> 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 <r...@libarch.co.uk> > To: talk-gb@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.sm...@xs4all.nl> > 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 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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > > > > > ---------- Forwarded message ---------- > From: ael <law_ence....@ntlworld.com> > To: talk-gb@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 <m...@good-stuff.co.uk> > To: talk-gb@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 <a...@bas.ac.uk> > To: talk-gb@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb >
_______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb