Loomio
Thu 21 Jan 2021 2:48AM

ONS Electoral Ward data for England

JT Jay Turner Public Seen by 37

I've checked and found that Electoral Ward data is available under OGL v3 and I'm wondering if we can import that data. How do we import the data?

I was looking specifically at my area but I do think a national import would be a good idea. I checked the wiki for ref:gss and E05 can be mapped as boundary=political + political_division=ward so I was thinking we can do that.

Mapping the following keys like so (using Margate Central as an example): 

"boundary"="political"
"political_division"="ward"
"official_name"=officialname
"name"=displayName  
"ref:gss"=code

Geometry can be derived from the hasGeometry linked resource, although I'm not sure exactly how to convert that.

CS

Colin Smale Sat 23 Jan 2021 9:12AM

This is definitely a "look before you leap" moment.

Firstly, we need to identify the different types of ward/electoral division. These names are used at the constituency level, county level, district level and parish level. Which types are available, and which types are we going to do? How do we distinguish between the different levels?

https://en.wikipedia.org/wiki/Wards_and_electoral_divisions_of_the_United_Kingdom

Secondly, having spent many, many hours getting all the 10000+ Civil Parishes and Welsh Communities into OSM, I can say that the biggest issue is going to be conflation with the existing data. Rather than invent a mechanical conflation process which would be imperfect at best, I worked manually, boundary by boundary, sorting out all the conflicts with existing data on a case by case basis. Where I was working on "virgin territory" it was quite quick, just a few minutes per parish (in its own changeset). Other cases actually took hours just to sort out a single boundary.

There are many reasons why the current OSM data might not align with OS data. Some that spring to mind:

1) There are some boundaries in OSM that pre-date my work and are based on hand-tracing from old OS maps, usually identified with source=npe . These are often very generalised, inaccurate and sometimes actually obsolete.

2) Some boundaries "almost" align with roads, waterways etc and people have been tempted to "improve" the boundaries by aligning them with the geographical features and combining the ways. Boundaries were indeed often in the past defined in terms of these geographical features, but as these features sometimes tend to move in the course of time, we have no simple way of knowing where the exact boundary lies in these cases. The most reliable source is IMHO the OS data, which is relied upon by just about everyone in government and the judiciary.

3) Coastal boundaries (usually going down to MLWS) change on a daily basis and are resurveyed every few years by the OS by some clever magic... They only coincide with the coastline (which is based on high water) where there are vertical cliffs, walls etc.

4) Many people conflate boundaries in OSM with hedges, ditches etc and move the OS boundary to align with imagery.

EB

Edward Bainton Sun 24 Jan 2021 8:30AM

Wow, kudos for all that effort.

I may have been guilty of some of those sins of "improvement" in the past, and definitely seem to recall "stitching" linear ground features to boundaries in my mapping youth, which only makes them more likely to be pulled about when new/different imagery suggests a realign.

Not wanting to fork the thread so not necessarily for a reply; but it has occurred to me after learning how flat-footed those edits were that we could lock the boundaries or at least prevent them being stitched to other features. Accurate boundary info seems a highly valuable addition to OSM, but also hard to spot new errors by peer review - good case for reserving edits to experts like you.

(And what a pity the legal boundary doesn't move when the river changes course: so much simpler!)

JT

Jay Turner Mon 25 Jan 2021 5:33PM

I too have been known to link the boundaries to fences and roads or rivers in the past, I now realise how wrong that was. I've only just found out I can actually hide the boundaries when I'm editing other features. But that doesn't help if they're already glued to those features. iD has had a habit of glueing features to nearby features if you even touch them.

If I wanted to import just my area (Thanet), what's the right way to go about that @Colin Smale?