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

[Warin]

I have faced formal learning things by using tool A at first because it 
'is easy', then the next year learning tool B because 'we' needed to do 
more complex things, then the next year learning tool C because 'we' 
needed to do the most complex things...

on numerous subjects... taught in formal subjects.
Having to learn tools A and B were a waste of my time .. give the choice 
if I think I'm going to be around to need the more complex tools I go 
straight for tool C.

I have never bothered with ID .. I went straight for tool JOSM.

On 13/12/18 23:00, Edward Bainton 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.






___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Paul Berry]

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  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,  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 
>> To: talk-gb@openstreetmap.org
>> Cc:
>> Bcc:
>> Date: Wed, 12 Dec 2018 18:10:24 +
>> 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 

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

[Edward Bainton]

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,  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 
> To: talk-gb@openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 18:10:24 +
> 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 
> 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 d

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

[Gareth L]

If only it could “snap” to points, but not join, where the way is an 
administrative boundary.

> On 13 Dec 2018, at 11:39, Andy G Wood  wrote:
> 
>> 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

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

[Andy G Wood]

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

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

[Mark Goodge]

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

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[ael]

On Wed, Dec 12, 2018 at 06:10:24PM +, 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.

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


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Colin Smale]

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 [1]). 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 [2]) - 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
 

Links:
--
[1] https://www.openstreetmap.org/changeset/65101926
[2] https://www.openstreetmap.org/relation/146656___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Rick Bowlby]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb