I was having fun yesterday surveying all the post boxes in Belfast BT1 & BT2.
A couple of practical points:
it looks like many of the post box reference numbers have changed slightly since the 2013 FOI dataset was published - not the numbers themselves, but a lot of them now have a letter suffix (usually a ‘D’ - I’m note sure what that denotes…. the ‘meter’ design boxes usually now have a ‘P’ suffix, which I gather is cos they accept parcels). When mapping these on OSM last night, I used the current post box numbers as displayed on the boxes, although I fear this will make the PostHoc tool think that the matching is worse now as a result of my efforts
BT1 & BT2 have quite a few ‘type C’ boxes (2 slots, 1 box). It seems each slot (or ‘aperture’, to use the POL term) has its own reference number. Generally the pair of apertures have the ‘same’ number only the second one has a ‘10’ or ‘1’ appended to the beginning (e.g. ‘BT1 10’ and ‘BT1 1010’ are the two slots in the Type C box outside Belfast Central Post Office on the High Street). Again, this may confuse Post Hoc (and seems to have been the reason for several ‘unmapped boxes’ reported by the tool) as OSM’s tagging thinks the ‘ref=’ tag pertains to the post box, not to the aperture, so for dual-slot boxes I had to put in two ref numbers, separated with a semicolon.
The tool knows about the D and P suffixes, and removes them before comparing with the Royal Mail data. So it should be fine that you’d added the full refs as found on the boxes.
The tool can also cope with multiple semi-colon separated refs on the same OSM node. For a typical dual-aperture Type C box, you’d list both refs. The tool will split them up and record two “post boxes”, one for each ref. So provided the Royal Mail data has an entry for each ref, the matching should work. One thing to watch here is that you shouldn’t put an spaces around the semi-colon. That’s an OSM standard for multivalued keys. (Unless it’s opening_hours=* where the OSM spec says you should!)
If anything doesn’t seem to be working as it should once the OSM data is refreshed in the tool, do let me know and I’ll take a look.
Oh well, that sounds like my fears were unfounded and Post Hoc will cope 100%
/waits eagerly for the next refresh/
One thing I totally noticed when doing the survey is how Royal Mail had slashed Last Collection Times compared to the last time these boxes had been surveyed - most are now ‘Last Collection 9am (7am on Saturdays)’.
Does anyone know what the ‘D’ suffix on a post box reference number means?
I believe the ‘D’ suffix means it is emptied as part of a delivery round. Practically speaking, the collection time is best interpreted as “not emptied before 9am” because I’ve seen them emptied many hours later!
Cheers!
And yeah, I was thinking the ‘Last Collection Time’ must be taken with a pinch of salt, as there are about 3 dozen post boxes in a couple of square miles all with identical times, and there’s no way they’re all gonna be simultaneously emptied!
I’m not sure if this is of any use for your tools or to @philipcullen, but I’ve just noticed that the FHRS LocalAuthorityBusinessID field (sometimes tagged with fhrs:local_authority_id) used by Fareham is the UPRN of the food business. I’m not sure if any other local authorities do this.
Even when they weren’t collected as part of the local postie’s delivery rounds, there would be five or six post boxes with the same collection time. I think it was always designed to mean “anything posted by this time will be collected on the day” and as you’ve noticed, they are getting less specific but guarantee that the collection won’t be before 9am.
A few weeks ago, I updated the UPRNs in my UPRN Viewing Tool and at the same time added the postcodes from ONS UPRN Directory. I’ve now added the ability to highlight all the UPRNs with a given postcode. So you can now view things like https://osm.mathmos.net/addresses/uprn/SW1P-3PA . The larger darker dots are UPRN locations that include the given postcode, the smaller lighter dots are the other UPRNs inside the dotted rectangle.
The new postcode view can be accessed either by manually adding the postcode to the URL, using the postcode box below the map, or clicking on a link in the popup for a UPRN point on the map. I think it can be really helpful in understanding which set of properties a given postcode applies to.
The UPRN and Postcode data that I’ve used is all licensed under the OGL so can be used to help improve OpenStreetMap. If you’re wanting to do so, there are a couple of caveats:
Note that the UPRN data from OS Open UPRN includes all UPRNs both current and historic. Not all UPRNs correspond to current properties, they also exist for streets, postboxes, phone boxes, substations, and other stuff. So it’s not a good idea to blindly add UPRNs to OSM, without understanding what they correspond to. In a lot of cases you can make a good guess, but other times it might not be clear. I’d suggest only adding them where they are added to an object that we would map anyway.
The Postcodes attached to each UPRN come from the ONS UPRN Directory. ONS has been releasing this for some time under the OGL so I think we should be on pretty safe ground using them. But there have been some questions raised about whether the IP Holders (Royal Mail and Geoplace/Ordnance Survey) might object to ONS doing so (see this post).
Would it be possible to use a different colour for dots where the ONSUD and OSM postcodes do not match? I’ve come across quite a few of these while importing USRNs and postcodes (the import doesn’t change existing values, but they’re in the log output). An example is on the West side of Boscobel Road North in St. Leonards-on-Sea, where the same postcode was added to both sides (without a declared source) - Way: 27 Boscobel Road North (1382360376) | OpenStreetMap
That’s a good idea, but I think I’m not actually collecting the data to do this at the moment. My tool is getting each object with a UPRN or Postcode, so it should be relatively simple to run the checks. I’ll add it to my to-do list.
Thank you so much Robert for your excellent tools. I use Survey Me page mostly, when I’m planning my walks or visiting somewhere new.
Can I make a request - out of date POI’s. Show me POI’s that haven’t been updated or “last_Checked” in say a year or 5 years. It could be similar to the “Stale Developments“ page.
It would be amazingly useful to have a tool that compares all the highway=bus_stop nodes against NaPTAN data, and flags any that are missing a Key:naptan:AtcoCode - OpenStreetMap Wiki tag, and vice versa.
(I have absolutely zero knowledge of how difficult it is to build and maintain such a tool, so I can only gormlessly advocate for how useful it would be )
Really useful set of tools — I’ve been using the Wiltshire
progress/tagging-errors pages this week.
I found a specific case that I wanted to check whether your tooling
already catches, or whether it’s outside current scope: way 31642593
( Way: CHIP108 (31642593) | OpenStreetMap ) (Chippenham parish path
CHIP108, a BOAT). Before I edited it, it had highway=bridleway,
ref=CHIP108, and a free-text note= describing its BOAT status — but no
designation= and no prow_ref= at all (changeset 185555601
( Changeset: 185555601 | OpenStreetMap ) has the fix).
It doesn’t appear in the Wiltshire “Missing or incorrect designation tag”
or “Missing prow_ref tag” lists in the current snapshot, which makes sense
if those reports start from ways already carrying some PRoW tag and check
the other — this one had neither, just a generic ref= matching the
county’s prow_ref format.
Is that pattern (generic ref= used instead of prow_ref=, no designation=
at all) something your existing scripts catch elsewhere, or a genuine gap?
Happy to help scope a targeted query for it if useful — I’m coming at
this from building a UK PRoW walking app (MOROW) and hit this exact case
in the field.
The “Missing or incorrect designation tag” and “Missing prow_ref tag” flags are designed to catch ways that are partially tagged with PRoW tags (either designation=* or prow_ref=*) but with one of them missing or inconsistent.
Ways with no designation=* and no prow_ref=* are not examined by the tool, and I don’t check for ref=* tags that might look like the prow_ref=* format. So anything with only a suggestive ref=* won’t be flagged, but that’s no different from other existing mapped highways that might follow the line of a PRoW and don’t have any PRoW tags at all.
Thanks Robert, that’s really helpful, and makes sense. Given the
ambiguity of bare ref= values (same reasoning as roads/bus routes), I
agree it’s not worth building anything to chase that pattern specifically.
I’ve been working through a small hand-verified batch of the existing
Wiltshire “Missing prow_ref”/“Missing or incorrect designation” lists this
week, cross-checking each against the council’s Open Data Hub feed before
touching anything, which has been a useful exercise in its own right.
I’ll keep going with that rather than anything scope-extending.
)