OpenStreetMap

Nottinghamshire Civil Parishes - names for unnamed areas

Posted by alexkemp on 16 July 2016 in English (English)

I’m surveying my way currently through Carlton NG4, which is the suburb next-door to Nottingham NG3. In all the days & weeks that I’ve been covering this area I’ve puzzled over why Carlton does not have a designated area in OSM + where to find it. I believe that I may have discovered the answer for both questions.

csmale has put in place GPX file downloads for Counties, Districts, Boroughs, Unitary Authorities and Civil Parishes/Communities in the UK (sourced from Ordnance Survey shape-files + converted into gpx files for easy import) — how fantastic is that! Nottinghamshire is available as a county and Nottingham + other Boroughs/Districts are available as a Unitary Authority. The next level down from Unitary_Authority/Borough/District is Civil Parish, and they are all available as well. Hooray!

The 9 English Regions are available for download from OSM in multiple formats.

There is a worm in every apple it seems, and one problem with the Notts CPs is that, whilst most have a name, eight do not. So, to try & help, and after ludicrous amounts of research, here are the best answers that I can find:

Overview:

See Also:

(council) parishmaps.pdf
Nottinghamshire Civil Parishes (wikipedia)
(note that a Civil Parish (CP) has zero connection with an Ecumenical Parish)
OSM Wiki: What is a Relation
OSM Wiki: Relations for BoundaryLines
OSM Wiki: HowTo Add a New Member to a Relation
Proposal for UK Admin Boundaries
Parish Codes (2015)

Admin Tags for Nottinghamshire:

type=boundary
boundary=administrative: (on the relation grouping those ways)

admin_level=1: n/a
admin_level=2: (Border, external (with Irish Republic))
admin_level=3: n/a
admin_level=4: (Border, internal (with Wales/Scotland))
admin_level=5: Region is “East Midlands”
admin_level=6: County/Unitary_Authority is “Nottinghamshire/City of Nottingham”
admin_level=7: n/a
admin_level=8: Borough/District (eg Gedling, Rushcliffe District)
admin_level=9: n/a
admin_level=10: Parish (eg Alverton CP)

Attribution:

source=OS_OpenData_BoundaryLine

Extra Tags:

designation=civil_parish
designation=non-civil_parish (OS designation for Unparished parishes)
is_in:country=UK
is_in:region=East Midlands
is_in:county=Nottinghamshire
is_in:district=Rushcliffe District
name:old=Hucknall Torkard CP
old_name=Hucknall Torkard CP
ref:gss=E04007984 (Government Statistical Service codes; this is Kingston on Soar CP; obtained from within the Parish GPX)
wikipedia=en:North Leverton with Habblesthorpe

Unnamed Shapes Named:

Q: When is a Civil Parish not a Parish?
A1: When it is an unparished Parish
A2: When it is a Municipal Borough or an Urban District

In short, there are 9 areas in Nottinghamshire that, if it were drawn as a map of CPs, would have 9 holes within it, each of which is given the generic classification of being “unparished”. Whatever that means.

  1. Unnamed_shape_5619
    This is part of the former “Worksop Municipal Borough”. Currently, Worksop is a node. Worksop is unparished & is within the Bassetlaw district.
    30 July: see Diary Entry and Relation 6447017
  2. Unnamed_shape_5620
    This is the former “East Retford Municipal Borough”. Currently, Retford is a node. East Retford is unparished & is within the Bassetlaw district.
    29 July: Lord, but this one was painful & took forever. The previous author of the Parish boundaries had welded them to land-use areas (farmland, etc.) and rivers. Mile after mile after mile of them. Where the OS gpx & the former boundary matched closely I let it be. The rest was a life-deadening process of unweld & re-constitute. It took most of a full working day to finish one miserable little Parish. But now it is done & uplifted.
  3. Unnamed_shape_5732
    This is the former “West Bridgford Urban District”. West Bridgford is unparished and is within Rushcliffe district. The current West Bridgford residential relation contains a note, saying: “naive, includes Edwalton”. The OS includes both West Bridgford & Edwalton within shape_5732.
    29 July: added; fiddly, but easy; some existing boundaries required lots of nips & tucks, others were already spot on the ball
  4. Unnamed_shape_5749
    This is a union of part of the former “Arnold Urban District” and “Carlton Urban District”, each of which is within Gedling district. Both Arnold & Carlton are unparished. The current Arnold CP relation is mostly the correct shape, but with errors (wrong name, little attribution, no ‘outer’ type, etc.).
    16 July: boundary updated from shape_5749 + relation, etc. fixed
    17 July: name fixed; entry s/b complete
  5. Unnamed_shape_5761
    This is a union of the former “Kirkby in Ashfield Urban District” and “Sutton in Ashfield Urban District”, each of which is within Ashfield district. Both Kirkby & Sutton are unparished.
    28 July: this was so easy! (see Mansfield below), and is now in place
  6. Unnamed_shape_5762
    This is the former “Hucknall Urban District”. Hucknall is unparished and is within Ashfield district. A Hucknall (unparished) admin boundary relation (name:old=Hucknall Torkard CP) already exists, although the Relation is broken due to various missing features.
    18 July: boundary updated from shape_5762 + relation, etc. fixed; s/b complete
  7. Unnamed_shape_5851
    This is part of the former “Beeston and Stapleford Urban District”. Beeston is unparished and is within Broxtowe district.
    10 August: *finally tackling the last unnamed-shape as the final parish at the bottom of Broxtowe (pdf), this one is in process; here is a listing as I tackle the issues:—
    (a) Unglueing the BoundaryLine from the River Erewash
    (not my favourite activity) if you want to abuse the map & render it unmaintainable, then weld a BoundaryLine to as many other features as you can find. Naturally, if a boundary is legally attached to a road, river, whatever, then you can merrily merge away. Otherwise, please do not bother.
    (b) The utter tedium of working from 1m to 10m and click-click-bloody-click along the line
    Every BoundaryLine is already in place. After the entire circle has been reset, it is a simple matter of creating a new Relation (menu:Presets | Relations | Boundary)
  8. Unnamed_shape_5861
    This is a concatenation of the former “Mansfield Municipal Borough” & “Mansfield Woodhouse Urban District”. Both Mansfield + Mansfield Woodhouse are unparished, and each is within Mansfield district.
    28 July: this was not easy, requiring fixes & repairs to existing districts, but is now in place.
  9. Unnamed_shape_9346 Nottingham
    The hole at the centre of Nottinghamshire is unparished and was formerly known as “Nottingham County Borough”.
    10 August: This was put in place weeks & weeks ago as “City of Nottingham” admin_level=8, but I never documented it here. First was “Nottingham (Unparished)” admin_level=10, using the existing hole at the centre of Nottinghamshire (admin_level=6), but then I discovered City_of_Nottingham.gpx in the District downloads (it is a ‘Unitary Authority’, admin_level=8) and that was identical to the hole. So in the end I added 3 BoundaryLines at admin_level=6, 8 & 10, all identical ways. Then today, whilst walking the bounds of Broxtowe, I came across yet another ‘Nottingham’ Boundary; it was identical to all the other three with the sole exception that the ways were unsorted & seemed not to be able to sort. It was also named wrong, since it was admin_level=6. In the end, I just deleted it.
    (wrong wrong wrong, oh dear, what a palaver this mistake on my part has caused: I did not read the wiki correctly; “City of Nottingham” is a UA & thus is admin_level=6, not 8; deleting the boundary quite reasonably caused all kinds of upset reactions, although that did not stop the The Maarssen Mapper, someone that is not even based in the UK, from coming in & deleting the Nottingham Unparished Boundary - quite extraordinary behaviour)
    31 July: fixing Woodsetts CP required a break & subsequent repair on a BoundaryLine containing a dozen different relations and several hundred members in total. After fixing Woodsetts CP I needed to reassure myself that those relations were still intact, so walked the bounds of each one, making sure that they were consistent & could be placed into a circle (see bottom). One of them was Nottinghamshire (admin_level=6, County) and that has Nottingham as an inner boundary (a hole). After creating consistency for both outer & inner I used the inner to create a Nottingham (Unparished) parish. The one missing item is that I am unsure what District (admin_level=8) Nottingham is in.
    Updated later: the district is “City of Nottingham” (a Unitary Authority); that also has a .gpx available, which I used to make the now-normal nips&tucks to convert the entire boundary (where necessary) from ‘NPE’ to ‘OS_BoundaryLine’. Nottingham is most unusual. The identical shape is used for admin_level=6 (County, inner (the hole in the county)), admin_level=6 (UA) and admin_level=10 (Parish). The final, intriguing, comment to make is that Nottingham is the only Boundary line that I’ve met which contains circles (or at least, parts of circles) throughout it’s length, and usually for no apparent reason; I found that immensely pleasing!

Add/Edit a Parish Boundary HowTo:

In OSM a BoundaryLine is a relation that groups a set of ways; with a Parish, the beginning of the first way joins with the end of the last way to form a continuous loop. So:

a. 2 or more nodes connected together form a way
b. 3 or more ways listed as members of a relation with the following properties set constitute a Civic Parish:-

  • type=boundary
  • boundary=administrative
  • admin_level=10
  • name=name-of-parish

c. Above are required; below is strongly advised:-

  • set member role for each way to “outer
  • add an admin_centre node (place=hamlet|village|town|city ; one only) to each Parish
     
    It took me a long while to realise, but a combination of Bing aerial imagery and OS OpenData StreetView is perfect for finding villages/hamlets; get very close then switch Download OSM Data Continuously ON and you will normally find that the place is already named. Node it & name it yourself (with a vacarious thrill of discovery) if not (menu:Presets | Geography | Places | …).

I did this for the 1st time with 4. Unnamed_shape_5749 to edit the Arnold CP boundary to become (in the end) the Arnold and Carlton (unparished) boundary. My 2nd edit will use 6. Unnamed_shape_5762 to edit the Hucknall (unparished) boundary. I’ll edit this blog live to make sure that the instructions are as accurate as possible. It will assume that you have already installed & use JOSM on a desktop computer, that it is connected to the Internet, and that everything is up-to-date.

  1. You will need the fastest computer possible with as much memory as possible
      My JOSM offline save-file is 437MB. JOSM seems to load all of that into memory at once.
  2. Start with a fresh load of JOSM; wait until the very first screen comes up; do nothing else!
  3. Use the File menu and, if you have the option to Download OSM Data Continuously, switch it OFF.
  4. Bring up Preferences (F12 or Menu:Edit | Preferences...) | Display Settings | GPS Points and put a tick in ✔Draw large GPS Points
  5. Outside of JOSM, copy the GPX url-link for the file that you are going to use
  6. In JOSM, use Open Location... (Ctrl-L), paste the URL + press OK (you should now be looking at a black screen with a magenta/purple outline)
  7. Use the “+” key and the “Ctrl+arrow” keys to view a part of the outline at high magnification
    (it was 6 “+”’s for me initially) (once working, a length of “3.00 m” at top-left on the screen is typical for me, going to 1m or less if more detailed work is required.
  8. Switch Download OSM Data Continuously back ON
  9. (this was probably a mistake): I loaded my save-file, obtained previously by Save As.... It took forever to load. It would in hind-sight have been better to have let the machine auto-download from OSM. At high mag that is very quick.
  10. You now need the GPX trace + any prior boundary lines easily viewable in the window. It is almost certain that the magnification will need to be very high to be able to operate comfortably. Do NOT switch any imagery on unless you need to check the boundary against rivers, roads, etc..
  11. Unless the territory in front of you is perfectly virgin it is likely that, once highlighted, any existing boundary lines will contain more than one Relation. That means that you need to careful if editing any boundary, as it will affect all other relations.
      SORT In my case, viewing the Parish boundary just below Linby, there are four: “Linby CP” (admin_level=10), “Gedling” district (admin_level=8) & “Ashfield” district (admin_level=8). The fourth is “Hucknall (unparished)”, but it has neither admin_level nor roles for any members. In addition, the last member does not connect back to the first (unlike all of the other 3), which suggest some kind of breaks in the chain.
  12. The first thing to do is to add roles for each member (it can only be “outer”, since there will be no holes within this boundary) + admin_level=10 so that it can look “Linby CP” in the eye.
  13. Next is to trace round the boundary circle, looking to try to find any errors in the chain. Here is my first example of the kind of mind-numbingly stupid ‘errors’ that you may find:
     
    The boundary is following a footpath heading north-west through a wood and joins another couple of Parish Boundaries coming up from the left (south) on the edge of that wood. One of those boundaries (“Nuthall”) follows back down the track I’ve been chasing, whilst the other (“Greasley”) joins with the track I’m on, heading north. So far, so normal. These are the 3 values for “source” in those 3 tracks meeting at a point:
     
    source=OS OpenData BoundaryLine (the track I’ve followed to this point)
    source=OS_OpenData_Boundary-Line (the track joining from below)
    source=OS_OpenData_Boundary_Line (the track continuing above)
     
    Because the Relation indicated that the ways were disjointed I attempted to merge them, but those different source values stopped it. Sometimes I want to spit. All 3 were changed to source=OS_OpenData_BoundaryLine, and all thoughts of merging the ways were abandoned.
     
    One more feature was that originally the footpath & the boundary nodes were joined - a foolish idea if you want easy maintenance. Up to the 3 ways joining, the boundary track had been astonishingly accurate to the gpx track (much better than how I left Arnold CP). However, at the 3 way join it all went to pot, and I had to split them all to be able to conduct repairs. By going to the highest-mag the nodes could be placed side-by-side without needing to merge them.
     
    03:25am: phew! painstaking small trims to the line of the Parish boundary to keep it true to the gpx track & after meeting up with yet another set of boundary line + relations (Broxtowe, Nottingham & Nottinghamshire) I finally am able to get all ways into line & it merges into a circle! Wow! dunnit. Here’s the overview of that specific procedure:
     
    (A far simpler procedure than below: one of the JOSM buttons is a sort button; if it will not sort, then it is likely that a small section of way has been missed for the circle, so read on)

Lines of nodes are joined together into a ‘way’. Click on a line between 2 nodes in JOSM & all connected lines in the way will be selected. That way is given a number, and the Relation window shows all ways in order. So, the currently selected way that I’ve just been working on is 61594085. The next one will be 61594091. It is also currently the next one in the window below 61594085, but when I reached the junction of the two ways it was NOT the next one. I clicked on the “Move the currently selected member up” icon within the Members section of the Relation window, as I had for the previous out-of-order sections and lo! It was the final one to slot into position.
 
I have absolutely no idea what difference that will make, but it does mean that I should have finished my work on this Parish Boundary and, after saving & uplifting everything, I should be able to finally get to bed. Hooray.

02 August: added wikipedia=en:North Leverton with Habblesthorpe as an example of how to add a wikipedia link, using the English village with the longest name (and one of the shortest Wiki entries, which is not too surprising for a parish with population=1,047 in 2011).
07 August: added change to GPS Points settings; I do not know how I managed to place/edit BoundaryLines before adding this setting. Also added wiki help on Administrative Boundaries.
10 August: Harry Wood’s WayDownloaderPlugin (find it at the bottom of Plugins via F12) is very useful for quickly finding the end of a Boundary way & thus the next Boundary that joins it. Nice one, Harry!

Location: Lace Market, St Ann's, City of Nottingham, East Midlands, England, NG1 1LJ, United Kingdom

Comment from DaveF on 15 August 2016 at 11:59

Hi Alex

is_in:* is redundant when boundary=* is used. OSM is geospacial. Mathematics can be used to determine if one area is within another.

Dave F.

Comment from alexkemp on 15 August 2016 at 16:23

Hi Dave F

What you say is accurate in itself. However, there are 2 aspects to consider:—

  1. Humans are lousy at geospacial mathematics
    For this reason those keys are valuable when a human browses the BoundaryLine
  2. geospacial mathematics is resource intensive
    Thus, (in my experience) Nominatum & suchlike use the as_in* keys to show search & location info.

It is because of (2) in particular that I add those keys into every Boundary relation.

Comment from DaveF on 16 August 2016 at 13:30

Hi

  1. Computers are very good at geospacial mathematics

  2. Where does it say Nominatum uses is_in rather than boundaries?

Similar to your assertion that boundaries shouldn’t be be attached to other entities because they might change, boundary lines often get amended. Using the hard coded is_in tags means the entity will become inaccurate.

.

Comment from alexkemp on 16 August 2016 at 21:21

Hi DaveF

You ask: “Where does it say Nominatum uses is_in rather than boundaries?”
My reply: Absolutely nowhere, DaveF; no-one has used the phrase ‘rather than’; that would be foolish.

It has been my experience, across the 6 months that I’ve been mapping, that Nominatum makes use of some *is_in** values within admin_level=10 BoundaryLines whilst producing search & location info.

Please recall that there is zero insistence from me that you use any *is_in** values within your mapping. I have personally found that they have assisted search & location info produced from OSM within those parts of the map that I’ve placed such values. Further, my programming + database experience suggests that the resource levels for DB lookups would be minimal cf geospacial mathematics, and thus such an action would make sense within the code. In addition, it should be obvious that humans read maps and can find those values useful. Finally, they produce no harm.

I am not going to deny my personal experience. I will disseminate that experience to anyone willing to listen. If you choose not to listen, that is your prerogative.

You are welcome to deny my assertions by quoting from the Nominatum source, or any of the other utilities used by Nominatum to produce it’s results. If you cannot do so, then please leave me free to carry on my mapping in peace. Thank you.

Comment from DaveF on 16 August 2016 at 23:43

Please have a read of this:

https://lists.openstreetmap.org/pipermail/talk/2016-August/076596.html

Specifically:

“Is geospacial mathematics is resource intensive?”

“Not at all. Nominatim happily processes boundaries and always prefers it over any other hierarchy information.”

“As soon as there are boundaries, multiple candidates don’t happen anymore, so that is_in:* is ignored for all practical purposes.”

“Yes, if possible always draw boundaries. They are more precise and easier to maintain. is_in is unnecessary.”

Regarding “doing no harm” please read this post regarding your ref:hectare tag: https://lists.openstreetmap.org/pipermail/talk-gb/2016-August/019076.html

Comment from alexkemp on 17 August 2016 at 00:14

That first is an excellent link, DaveF, and is food for thought - thank you. Where is the source-code referred to, please? I’m going to need to see that before I switch (my personal experience tells me otherwise, so I need to discover where I was wrong). I’ve tried to find the source find it in the past & could not after ages of searching.

Regarding the second link I’ll stop using ref:hectare immediately (not that I’ve done any areas for a little while, now). I respect Andy’s work & opinion totally.

Many, many thanks for taking the time to set this out for me (and all others that read this).

Comment from alexkemp on 17 August 2016 at 00:35

Hmm, quick follow-up having read the thread to date on ‘as-in’. As I suspected, even the Nominatim folks do not know how their program works. Good stuff.

Comment from DaveF on 17 August 2016 at 15:06

“Where is the source-code referred to, please?”

Why not join in on the community forum so you can ask for yourself & so find solutions to your queries on this collaborative project?

Comment from alexkemp on 17 August 2016 at 15:43

Because this is your query, and not mine. There are other things (mapping + diary entries) that I put my time into.

Comment from Colin Smale on 19 August 2016 at 11:28

Alex, please go easy on the personal affronts. I have considerable knowledge and experience of UK local government and administrative boundaries. Where you think I am based is of no relevance to the facts. If your understanding of the subject was better you would realise why things are like they are, and why it’s best to ask before unilaterally upending the status quo.

–The Maarssen Mapper

Login to leave a comment