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 +0000, 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, <[email protected]> > wrote: > > Send Talk-GB mailing list submissions to > > > > [email protected] > > > > > > > > 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 > > > > [email protected] > > > > > > > > You can reach the person managing the list at > > > > [email protected] > > > > > > > > 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 <[email protected]> > > To: [email protected] > > 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). 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 <[email protected]> > > To: [email protected] > > 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.openstre > > etmap.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). 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 > > > > > > > > > > > > _______________________________________________ > > > Talk-GB mailing list > > > [email protected] > > > https://lists.openstreetmap.org/listinfo/talk-gb > > > > > > > > > > ---------- Forwarded message ---------- > > From: ael <[email protected]> > > To: [email protected] > > 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 <[email protected]> > > To: [email protected] > > 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 <[email protected]> > > To: [email protected] > > 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 > > > > [email protected] > > > > https://lists.openstreetmap.org/listinfo/talk-gb > > > > _______________________________________________Talk-GB mailing > [email protected] > https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________ Talk-GB mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-gb
