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

Thu Dec 13 12:18:33 UTC 2018

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, <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). 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 <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.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
> > >  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
> listTalk-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/1b52adf8/attachment-0001.html>