Restore administrative hierarchy for GB postcodes

[missinglink]

🏃‍♂️ moving the discussion over from #13

Pelias relies on the administrative hierarchy being set for all WOF records, the recent change in GB postcodes has removed many hierarchy entries which were previously available:

---

My understanding of the motivation for this change was to introduce a new postalregion placetype which better represents the 'postal hierarchy' of the UK, I think that's a great idea.

The issue I'm facing is that GB postcodes are not associated to anything in the administrative hierarchy below the country, eg. 'England', 'London', etc. are missing from data in the screenshot.

This makes GB postcodes different/special compared to all other WOF records and will require consumers to treat them differently.

I wanted to open a discussion about whether you'd consider reverting the deletion of the administrative hierarchy generated through PIP?

Was this change intentional? I can see that it's not always technically correct to say a postcode belongs to a single neighbourhood, but for the most part this is true due to the granularity of GB postcodes. I feel like the macrocounty should always be set.

How would you feel about moving the new placetype to an alternative hierarchy (at index 1) and restoring the hierarchy at index 0 so it behaves like other WOF records?

cc/ @tomtaylor @thisisaaronland @nvkelso @stepps00 @orangejulius

EN5 2LP on Github

[missinglink]

I see there was a new drop of ONS postcode data last month so it would be nice to discuss this before we do the next import.

[straup]

It seems like there are a few overlapping things happening here:

1. Postal codes may be parented by postal regions but given the order of precedence in the list of valid parent types locality and region should be chosen first, if present
2. Postal regions are only parented by country and higher, which would explain the label changes
3. There is currently no way to specify that a second parent type be included in the final hierarchy. For example: locality (x) is considered to be the wof:parent_id but please also ensure that postalcode (y) is included in the final wof:hierarchy list (which is derived from locality (x))
4. I am guessing that @tomtaylor manually assigned the relevant postalregion for each postalcode as its wof:parent_id value at which point the code worked as expected (following the rules defined in the whosonfirst-placetypes definitions). @tomtaylor - is that what happened?

• https://github.com/whosonfirst/whosonfirst-placetypes/blob/main/placetypes/postalcode.json
• https://github.com/whosonfirst/whosonfirst-placetypes/blob/main/placetypes/postalregion.json

[tomtaylor]

Hello, just catching up on this. Yes, I made the decision to parent these by just the postalregion - I don't think I appreciated the implications however. I made this decision because GB postalcodes can straddle regions, localadmins and even macroregions. (Some postcodes straddle England and Scotland, for example.) But that might be a nuance that's not worth capturing, given the downside.

We could add the postalregion hierarchy as a separate element in the hierarchy and re-PIP all the records into the admin hierarchy if that's preferred?

[missinglink]

Hey Tom 👋

We could add the postalregion hierarchy as a separate element in the hierarchy and re-PIP all the records into the admin hierarchy if that's preferred?

This would be my preference, because otherwise I'm going to need to figure out a way of PIP-ing them for Pelias users, either after downloading or by hosting alternative distribution files on our CDN, which I'd like to avoid if possible.

What's the easiest path to restoring the admin hierarchy to what it was before but also supporting postalregion so that we can benefit from that work?

Seems to me that having either multiple hierarchies or having a single hierarchy with postalregion added are both workable solutions.

In order to achieve this we'll need to change wof:parent_id such that the immediate parent of a postalcode is never a postalregion, does that still work for you?

[missinglink]

@straup for this file you linked: https://github.com/whosonfirst/whosonfirst-placetypes/blob/main/placetypes/postalcode.json#L5 is the expected behaviour that the wof:parent field is iterated from left->right until a matching hierarchy item is found and then that's the preferred placetype to use for the immediate parent, which is recorded in wof:parent_id on the feature?

[thisisaaronland]

@missinglink Yes, that is correct.

[tomtaylor]

@missinglink hi! I'd prefer to have both hierarchies in place (admin first, then postalregion). I don't know when I'm going to get to it at the moment - a bit too snowed under at the moment - but I'd also like to get the ONS update out, so hopefully not too long...

[missinglink]

snowed under at the moment

Yeah all good, sounds like we're all on the same page for the next release which will happen when it happens, no stress.

[missinglink]

Hey @tomtaylor, anything I can do to help get this moving?

[tomtaylor]

@missinglink I've got this on our internal roadmap now, hopefully will be sorted in the next few weeks.

[tomtaylor]

@missinglink if you're able to have a review of #15 when you get chance, that'd be great!