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
