Nov 23, 2023·edited Nov 24, 2023Liked by James O'Malley
The existing phone area code system would be a good place to start. Although fewer people use it now, it still has a strong recognition and association with place. The phone numbering system also effectively indicates the type of number it represents (07x vs 01x vs 08x) using a prominent leading pair. Beginning each phone number with a zero helps indicate *this is a phone number* rather than an arbitrary list of digits.
So building on this, a parking reference could be
53 302 342 213 :
[5 = this is a parking reference, they *all* start with 5. This would help interpretation if you’re an AI or a person]
[3 = in a multi-storey]
[302 = existing area code for Doncaster]
[six digit reference]
Not related to phone numbers but a final check digit could reduce errors. I’m not sure it’s necessary in this case.
[Reading other comments and perhaps my suggestion could be what sits behind a more random, meaningless identifier?]
I liked your idea of splitting the reference number into logical blocks that refer to specific pieces of information.
I think that a good way to do it could be to build car park reference numbers on top of USRNs.
Perhaps UPRNs could also help but I think using USRNs as the structure is the way to go.
I think that USRNs:
1. Could act as a geographical "stem" that would allow for extra complexity to built in with ease.
The structure could be:
[USRN]-[Type]-[Ownership]
The above structure could be tweaked to account for whatever nuances people feel necessary to capture to ensure that (i) the right carp park is selected and (ii) the right person gets paid.
For example:
11725156 - 09 - 02
USRN = 11725156 (is STATION APPROACH, DURHAM CITY which is where Durham train station is located and it has on site parking at the station)
Type = 09 (to reference that it is train station parking - 02 could reference another "type" etc, etc)
Ownership = 02 (to reference that it is owned by the local authority which I think it is - 01 could reference private ownership, etc, etc)
--
2. Would provide a solution to several problems:
(i) How to add in a geographical reference.
(ii) How to account for extra complexity that references "type" and "ownership" - and possibly others.
(iii) Users needing to input too many numbers. Using USRNs as the stem would allow for autofill functionalities as typing in half the USRN could bring up a selection of locations - given the USRN dataset already exists. You pick the right one and then move on to the next part - why do people have to put the number in all at once!? Split it up into steps with location being the first one and then type?
--
3. Would make car park reference numbers interoperable with other systems such as:
(i) Street Manager
(ii) National Streets Gazeteer
(iii) Ordnance Survey products such as the open source USRN dataset but also the national geographic database (NGD)!
It's really important to consider the already existing systems in place within the streets sector. USRNs are widely used and trusted already - use them as the core building block!
I think that including easter-eggs is a nice to have for now! Focus on getting something that doesn't become a silo and is interoperable with already existing systems.
The Unique Street Reference Number (USRN) is an 8 digit unique identifier for every street across Great Britain. There are over 1.4 million USRNs in England and Wales. And they can be found within the National Street Gazetteer (NSG) and OS MasterMap Highways Network. The NSG is the authoritative source of information about streets in England and Wales and is a compilation of data from 175 highway authorities' Local Street Gazetteers. This data is collected on a daily basis, validated and assured by GeoPlace.
The USRN is underpinned by legislation and statutory functions to name and number streets and maintain highways. USRN never changes and guarantees the identification of the street, providing confidence to those needing authoritative information about the road network.
I don’t think I ever notice what the number for parking is, so could it just assign numbers as and when (like who cares if the one car park has one set of numbers and the next one over has something in a completely different range, as long as the operator gets a block of them to manage)?
Overtime it’ll just get all mixed up anyway as some parking is turned into flats and the others are created.
Then maybe you could ‘reserve’ some Easter egg ones that operators could apply for, eg 101, 007 80085. Or pay for them (kind of like personalised licence plates).
One scheme might just be giving them each numbers corresponding to GPS coordinates, so Holywell Lane Car Park in Shoreditch has the number 515230000777, which is the combination of 51.52385140235222 and -0.07776063165991862, with some digits knocked-off (https://xkcd.com/2170/) and an extra zero added to the start of longitude because it's negative.
You could work easter-eggs into there by being judicious about where _precisely_ the GPS coordinates are taken to be, so you move them around until the least significant digits of either lat or long line up with what you need them to be.
Far too long. People struggle with mobile numbers, and all those begin 07 and only have 11 digits, ie 9 unique. You're going to give them a 12-digit number and hope they don't miss?
James, I think Parking Friend should at least consider one alphabetical, perhaps at the start of the code. Hugely expands what can be done while shortening potential code.
This is an interesting usability problem! Firstly, I would say that telephone numbers have been used for decades, and while not ideal, do work reasonably well for most people (especially when written down somewhere).
The problem with letters, when typed onto a numeric keyboard, is that they limit the number of possible combinations rather than increase them. Also, probably the next piece of information they may need to enter, after the parking code will be the long card number on their credit card, which is 14-16 digits.
One useful thing about using GPS coordinates is that a mobile phone with GPS can cross-check the code typed against the GPS on the phone, sort of like a checksum on what's entered.
One issue with that might be if people mistype the least-significant digits of the lat/long coordinates, because two nearby places might get confused. To prevent that, as with the how I mentioned you could generate easter-eggs before, an actual checksum on the least significant digits could be used, like the Luhn algorithm. You could then just have carve-outs of 'easter-egg' sites.
Whether or not GPS coordinates are used, a checksum of some sort would probably be a good idea.
"the long card number on their credit card, which is 14-16 digits". This is true, though credit card numbers include a checksum digit (and also follow a strict allocation pattern). A checksum digit is also used in ISBNs. Might be useful here too.
What about ordnance survey coordinates as those will have a government licence that could be easily implemented (I have no idea if there’s enough data in the coordinates for that or not).
That probably has the benefit of not having to deal with negative numbers(?). But yeah I don't know how precise those are, and it's not like using GPS coordinates costs money?
Here in Canada, we call them "parking garages" (even when they aren't in physical garages), and it's a completely privatized system that can and does rip off drivers. You might be on to something.
UK oil and gas blocks naming system. Divided into quadrants, then blocks, then partitioned as appropriate. Scalable. A field named 202/12b means the field is in quadrant 202, block 12 which has at least partition a and b. Not geographically intuitive but scalable.
A useful feature would be if nearby or adjacent car parks have very different codes - reducing the likelyhood of someone keying in another nearby car park, and not noticing the error.
It is irresponsible to put technocrats like us in charge because we'll do something stupid like insist that all identifiers be prime numbers.
This is purely a routing number. Are users *really* going to say "Ah! It ends with a 3, so it has an EV charger, but it also starts with binary sequence, therefore it's at a train station, also the middle digits are the ASCII value for Winchester!"
No.
You *could* do some clever stuff like leave out numbers which might get confused with letters (1 & l, 2 & Z, 5 & S, 0 & O) but if it's a purely numeric code, it shouldn't matter.
Just pick a length of digits which can reasonably contain the dataset but which isn't too long for people to type in. Do some user testing to see if people find it easier to type in 12-34-56-78 or 123-456-789. Then randomly assign numbers to each car park.
If you really want the Douglas Adams Memorial Car Park to contain the number 42, then force it in.
The identifier for a place is a primary key - you should never try to encode information in a primary key. Local government, facilities, means of payment can all change and you don't want to have to recode the car parks every time that happens. Even using the location itself is dangerous because you might find a single car park split into two with different charging arrangements (e.g. short stay/long stay) at some point. Other posters have pointed out that the requirement for users to type the primary key itself straight into their phones doesn't really exist so shouldn't over ride basic rules of data management.
This is the correct answer - primary keys should be unique, immutable and MEANINGLESS.
Not sure I agree that users will never type in the key directly, though. Scanning QR codes and verifying by GPS assumes a smartphone, and they have to make it inclusive enough that someone could park using voice only. (Although they could just mandate a physical Pay & Display machine to accommodate such luddites.)
Keeping it simple applies here - and if it's a 9 digit number make sure it has a slash so it isn't picked up as a phone number in phones.
There are ~ 400 LAs in the UK.
Giving them each a number will require 3 digits.
Then, assuming most LAs have fewer than 10,000 parking spaces given them 4 digits for their references, with LAs being able to pick multiple sequential area references should they have more than 5,000 at introduction.
Then I'd have two independent numbers one for type of parking, and one for pay method (e.g. 5 for multi-storey, 2 for pay at exit), so: XXX-YYYY-ZZ.
For the regional code I'd allocate the first digit to each NUTS area (combining NE + Yorkshire, and Midlands) to have a 0-9 first digit allocated to each of them. E.g. 1: NI, 9: London etc. Then I'd draw a grid (0-9) over each region and allocate LAs numbers based on what is closest, like so: https://www.reddit.com/r/HANQH/comments/182d59r/london_grid/, Hillingdon would be 03 and 04, Westminster 44, K&C 45, H&F 35, Greenwich 75 etc, if they need multiple codes the map can be distorted a bit, some codes will not be used.
I'd encourage councils to allocate their four digits similarly (0-9 grid followed by two numbers), but they'd be able to make exceptions like those mentioned in the article, secondary functionality could also be mandated, for example hospital car parks could be forced to start 00XX, or train station/P&Rs start with 50XX.
So putting it all together - a multi-storey carpark in Battersea (NE Wandsworth) where you pay at exit may be 946/9509/52
946 - London - Wandsworth
9015 - 90th+ percentile East, northern most 10%, 15 is random
52 - Multi-storey, pay on exit.
As short as is practicable, but highly geographical, and plenty of room for additions.
Not all the 430 LA’s are highways authorities - it’s usually the county council or unitary authority- district councils only have responsibility for highways when it’s devolved by county councils
No logical human readable system whatsoever is required. Your phone already knows where you are, and if it doesn't the app will tell you "type the code on the kiosk" or more likely "scan the QR code".
Codifying things like ev charging or other amenities into the number is an actively bad idea since the identifier will not change but the amenities likely will.
Any logic around the allocation of numbers will be quickly forgotten. Case-in-point the US interstate highway system: "Routes with odd numbers run north and south, while even numbered run east and west. For north-south routes, the lowest numbers begin in the west, while the lowest numbered east-west routes begin in the south". Almost nobody knows this or uses it as an aid to navigation.
Given all of that the numbers may as well be random, and if they can be random they can also be localized e.g., "007".
This is the right answer. Each parking SPACE requires a URN but it doesn’t matter at all if the URN is human readable, it just needs to be machine readable because humans won’t be doing the reading - computers will and they will translate the URN into the name that has most relevance to the individual user (‘near the GP’, ‘at my parents’ ‘shops’ … etc). There there needs to be a consistently applied taxonomy of all the features that apply to that parking space, again which are machine readable and openly licensed. However, this is the easy bit, speaking as a councillor in the middle of a CPZ consultation in my ward the main challenge will be getting both the councillor’s and the officers in all the country’s highways authorities onside… because network edicts mean that this needs to be done centrally across the whole of the UK.
HI All. We have Unique Property Reference Numbers (UPRNs) for all carparks already. At GeoPlace, we collect data from local authorities and third party sources and collate into a national datasets of properties (including car parks) which is then licenced to the market by Ordnance Survey as the AddressBase Products. I'd urge you to look at this data (available under a free development licence to review it and play around) as it does contain a reference number for all car parks. We've been working on improving data quality for these features as we are confident that we have the vast majority of car parks recorded in the AddressBase data.
I think most of the comments have it covered but, generally speaking, smart coding is a dangerous game and shouldn't be necessary in a world where a quick lookup gives you all the associated metadata you need. I'd plump for a 6-10 digit, pseudo-randonly assigned (others mentioned neighboring codes being different enough not to confuse, which sounds sensible), and starting 1-9 to avoid issues with dropping leading zeros (in Excel, inevitably).
We should perhaps go back to the objective: to identify the location of a car park so that the appropriate payment can be made to its owner.
The user would necessarily have a dialogue with the app about the length of stay, the characteristics of the space (if the owner wished to charge more, say, for space at a charging point, whatever the electricity supplier charged, or for one near the walking exit).
The user doesn't need to know who the owner is, the app has that in its reference data; it also, clearly, must have the tariff.
Ten digits of National Grid reference (the OS one, not the power distributor) – two for the (normally lettered) 100km square, eight for the eastings and northings within it – give a reference to a 10 metre square, small enough to be unique even for small on-street parking places. The phone can know where this is, by cross-reference to latitude and longitude, or can read it from a 'QR' code, or, if all else fails, can accept the user keying it in.
This has the advantage of giving geographical reality and, potentially, user back-up – 'What Three Words' is a particularly useless device, as it gives no geographical data, just the contents of its index.
You can make a key long/complex enough to encode information, like an email address. Then it’s human-readable, and tells the user useful stuff. “Huh… W1S-BondSt-1234-EVPremium? I didn’t mean to use the expensive charger!”
Or you make keys entirely meaningless, just random numbers, with a publicly accessible API to look up the associated properties (which can now be VASTLY more data than you could encode in a usable key).
Option 2 is better. If you want human-readable, you can still create aliases that point to a specific key, just like DNS.
Trying to embed data in a compact key… that way madness lies. People give examples like telephone area codes, but I’m old enough to remember how confused my parents were when all the area codes had to be changed by adding a 1 after the leading 0, and I’m personally suffering from Sheffield running out of 01142 numbers and having to change the code to just 0114, which nobody believes.
01 covers the type of parking e.g. 01 pay on arrival car park, 02 pay on exit car park, 03 on street, numbers allocated based on most commonly ocurring get lower numbers.
This could be a single digit but double digit allows for expansion e.g. motorbikes, electric recharging or just stuff we cant envisage now becoming important later.
next 2 are a geographic location gives you 100 locations, but they just need to be general areas. These should start at 00 in the orkney islands and get larger as you got further south. It could even mimic a grid, so 00 top North west Scotland and 99 would be south east england, so you could tell your approximate position (not really latitide/longtitude but an approximation.
next 6 are your individual car parks. These dont really matter aslong as they are unique within the geographic area, allows for reserving certain ones e.g. 080 085 and you could have as many 007's as there are bond streets.
Could you not lop off the first 4 digits and get the same effect? Then app users don't have to type as many numbers into an app on a cold, windy night with bad signal and a crying child, to pick a recent example
The term for a system that encodes geographic locations into a number or string is a "geocode", and there's quite a lot of prior art here: https://en.wikipedia.org/wiki/Geocode. But as others have said, it's probably a mistake to encode semantic information into the numbers - just let them be opaque numbers, possibly with Easter eggs as you describe. The only way I'd break from opacity would be by handing out prefixes to local authorities and letting them do whatever they want within their block of assigned numbers, much as we do with blocks of IP addresses.
The existing phone area code system would be a good place to start. Although fewer people use it now, it still has a strong recognition and association with place. The phone numbering system also effectively indicates the type of number it represents (07x vs 01x vs 08x) using a prominent leading pair. Beginning each phone number with a zero helps indicate *this is a phone number* rather than an arbitrary list of digits.
So building on this, a parking reference could be
53 302 342 213 :
[5 = this is a parking reference, they *all* start with 5. This would help interpretation if you’re an AI or a person]
[3 = in a multi-storey]
[302 = existing area code for Doncaster]
[six digit reference]
Not related to phone numbers but a final check digit could reduce errors. I’m not sure it’s necessary in this case.
[Reading other comments and perhaps my suggestion could be what sits behind a more random, meaningless identifier?]
I liked your idea of splitting the reference number into logical blocks that refer to specific pieces of information.
I think that a good way to do it could be to build car park reference numbers on top of USRNs.
Perhaps UPRNs could also help but I think using USRNs as the structure is the way to go.
I think that USRNs:
1. Could act as a geographical "stem" that would allow for extra complexity to built in with ease.
The structure could be:
[USRN]-[Type]-[Ownership]
The above structure could be tweaked to account for whatever nuances people feel necessary to capture to ensure that (i) the right carp park is selected and (ii) the right person gets paid.
For example:
11725156 - 09 - 02
USRN = 11725156 (is STATION APPROACH, DURHAM CITY which is where Durham train station is located and it has on site parking at the station)
Type = 09 (to reference that it is train station parking - 02 could reference another "type" etc, etc)
Ownership = 02 (to reference that it is owned by the local authority which I think it is - 01 could reference private ownership, etc, etc)
--
2. Would provide a solution to several problems:
(i) How to add in a geographical reference.
(ii) How to account for extra complexity that references "type" and "ownership" - and possibly others.
(iii) Users needing to input too many numbers. Using USRNs as the stem would allow for autofill functionalities as typing in half the USRN could bring up a selection of locations - given the USRN dataset already exists. You pick the right one and then move on to the next part - why do people have to put the number in all at once!? Split it up into steps with location being the first one and then type?
--
3. Would make car park reference numbers interoperable with other systems such as:
(i) Street Manager
(ii) National Streets Gazeteer
(iii) Ordnance Survey products such as the open source USRN dataset but also the national geographic database (NGD)!
It's really important to consider the already existing systems in place within the streets sector. USRNs are widely used and trusted already - use them as the core building block!
I think that including easter-eggs is a nice to have for now! Focus on getting something that doesn't become a silo and is interoperable with already existing systems.
Keen to know your thoughts!
Thanks,
Chris [find more info about USRNs below!]
--
Explore USRNs here:
https://www.findmystreet.co.uk/map
Link to overview here:
https://www.geoplace.co.uk/addresses-streets/location-data/usrn
Snippet from overview here:
The Unique Street Reference Number (USRN) is an 8 digit unique identifier for every street across Great Britain. There are over 1.4 million USRNs in England and Wales. And they can be found within the National Street Gazetteer (NSG) and OS MasterMap Highways Network. The NSG is the authoritative source of information about streets in England and Wales and is a compilation of data from 175 highway authorities' Local Street Gazetteers. This data is collected on a daily basis, validated and assured by GeoPlace.
The USRN is underpinned by legislation and statutory functions to name and number streets and maintain highways. USRN never changes and guarantees the identification of the street, providing confidence to those needing authoritative information about the road network.
I don’t think I ever notice what the number for parking is, so could it just assign numbers as and when (like who cares if the one car park has one set of numbers and the next one over has something in a completely different range, as long as the operator gets a block of them to manage)?
Overtime it’ll just get all mixed up anyway as some parking is turned into flats and the others are created.
Then maybe you could ‘reserve’ some Easter egg ones that operators could apply for, eg 101, 007 80085. Or pay for them (kind of like personalised licence plates).
To be honest, it’s a good thing if the next car park over has a completely different number. Avoids fat finger issues.
One scheme might just be giving them each numbers corresponding to GPS coordinates, so Holywell Lane Car Park in Shoreditch has the number 515230000777, which is the combination of 51.52385140235222 and -0.07776063165991862, with some digits knocked-off (https://xkcd.com/2170/) and an extra zero added to the start of longitude because it's negative.
You could work easter-eggs into there by being judicious about where _precisely_ the GPS coordinates are taken to be, so you move them around until the least significant digits of either lat or long line up with what you need them to be.
Far too long. People struggle with mobile numbers, and all those begin 07 and only have 11 digits, ie 9 unique. You're going to give them a 12-digit number and hope they don't miss?
James, I think Parking Friend should at least consider one alphabetical, perhaps at the start of the code. Hugely expands what can be done while shortening potential code.
Totally agree Charles. The more numbers, the larger the chance of finger problems.
This is an interesting usability problem! Firstly, I would say that telephone numbers have been used for decades, and while not ideal, do work reasonably well for most people (especially when written down somewhere).
The problem with letters, when typed onto a numeric keyboard, is that they limit the number of possible combinations rather than increase them. Also, probably the next piece of information they may need to enter, after the parking code will be the long card number on their credit card, which is 14-16 digits.
One useful thing about using GPS coordinates is that a mobile phone with GPS can cross-check the code typed against the GPS on the phone, sort of like a checksum on what's entered.
One issue with that might be if people mistype the least-significant digits of the lat/long coordinates, because two nearby places might get confused. To prevent that, as with the how I mentioned you could generate easter-eggs before, an actual checksum on the least significant digits could be used, like the Luhn algorithm. You could then just have carve-outs of 'easter-egg' sites.
Whether or not GPS coordinates are used, a checksum of some sort would probably be a good idea.
"the long card number on their credit card, which is 14-16 digits". This is true, though credit card numbers include a checksum digit (and also follow a strict allocation pattern). A checksum digit is also used in ISBNs. Might be useful here too.
What about ordnance survey coordinates as those will have a government licence that could be easily implemented (I have no idea if there’s enough data in the coordinates for that or not).
Six-figure OS grid references specify a 100m x 100m square, but to cover the whole UK you also need to specify which 100km x 100km square you're using: https://getoutside.ordnancesurvey.co.uk/guides/beginners-guide-to-grid-references/
That probably has the benefit of not having to deal with negative numbers(?). But yeah I don't know how precise those are, and it's not like using GPS coordinates costs money?
You can make OS grid references as precise as you like by adding more digits :-)
Here in Canada, we call them "parking garages" (even when they aren't in physical garages), and it's a completely privatized system that can and does rip off drivers. You might be on to something.
UK oil and gas blocks naming system. Divided into quadrants, then blocks, then partitioned as appropriate. Scalable. A field named 202/12b means the field is in quadrant 202, block 12 which has at least partition a and b. Not geographically intuitive but scalable.
A useful feature would be if nearby or adjacent car parks have very different codes - reducing the likelyhood of someone keying in another nearby car park, and not noticing the error.
User needs! User needs! User needs!
It is irresponsible to put technocrats like us in charge because we'll do something stupid like insist that all identifiers be prime numbers.
This is purely a routing number. Are users *really* going to say "Ah! It ends with a 3, so it has an EV charger, but it also starts with binary sequence, therefore it's at a train station, also the middle digits are the ASCII value for Winchester!"
No.
You *could* do some clever stuff like leave out numbers which might get confused with letters (1 & l, 2 & Z, 5 & S, 0 & O) but if it's a purely numeric code, it shouldn't matter.
Just pick a length of digits which can reasonably contain the dataset but which isn't too long for people to type in. Do some user testing to see if people find it easier to type in 12-34-56-78 or 123-456-789. Then randomly assign numbers to each car park.
If you really want the Douglas Adams Memorial Car Park to contain the number 42, then force it in.
The identifier for a place is a primary key - you should never try to encode information in a primary key. Local government, facilities, means of payment can all change and you don't want to have to recode the car parks every time that happens. Even using the location itself is dangerous because you might find a single car park split into two with different charging arrangements (e.g. short stay/long stay) at some point. Other posters have pointed out that the requirement for users to type the primary key itself straight into their phones doesn't really exist so shouldn't over ride basic rules of data management.
This is the correct answer - primary keys should be unique, immutable and MEANINGLESS.
Not sure I agree that users will never type in the key directly, though. Scanning QR codes and verifying by GPS assumes a smartphone, and they have to make it inclusive enough that someone could park using voice only. (Although they could just mandate a physical Pay & Display machine to accommodate such luddites.)
Keeping it simple applies here - and if it's a 9 digit number make sure it has a slash so it isn't picked up as a phone number in phones.
There are ~ 400 LAs in the UK.
Giving them each a number will require 3 digits.
Then, assuming most LAs have fewer than 10,000 parking spaces given them 4 digits for their references, with LAs being able to pick multiple sequential area references should they have more than 5,000 at introduction.
Then I'd have two independent numbers one for type of parking, and one for pay method (e.g. 5 for multi-storey, 2 for pay at exit), so: XXX-YYYY-ZZ.
For the regional code I'd allocate the first digit to each NUTS area (combining NE + Yorkshire, and Midlands) to have a 0-9 first digit allocated to each of them. E.g. 1: NI, 9: London etc. Then I'd draw a grid (0-9) over each region and allocate LAs numbers based on what is closest, like so: https://www.reddit.com/r/HANQH/comments/182d59r/london_grid/, Hillingdon would be 03 and 04, Westminster 44, K&C 45, H&F 35, Greenwich 75 etc, if they need multiple codes the map can be distorted a bit, some codes will not be used.
I'd encourage councils to allocate their four digits similarly (0-9 grid followed by two numbers), but they'd be able to make exceptions like those mentioned in the article, secondary functionality could also be mandated, for example hospital car parks could be forced to start 00XX, or train station/P&Rs start with 50XX.
So putting it all together - a multi-storey carpark in Battersea (NE Wandsworth) where you pay at exit may be 946/9509/52
946 - London - Wandsworth
9015 - 90th+ percentile East, northern most 10%, 15 is random
52 - Multi-storey, pay on exit.
As short as is practicable, but highly geographical, and plenty of room for additions.
Not all the 430 LA’s are highways authorities - it’s usually the county council or unitary authority- district councils only have responsibility for highways when it’s devolved by county councils
No logical human readable system whatsoever is required. Your phone already knows where you are, and if it doesn't the app will tell you "type the code on the kiosk" or more likely "scan the QR code".
Codifying things like ev charging or other amenities into the number is an actively bad idea since the identifier will not change but the amenities likely will.
Any logic around the allocation of numbers will be quickly forgotten. Case-in-point the US interstate highway system: "Routes with odd numbers run north and south, while even numbered run east and west. For north-south routes, the lowest numbers begin in the west, while the lowest numbered east-west routes begin in the south". Almost nobody knows this or uses it as an aid to navigation.
Given all of that the numbers may as well be random, and if they can be random they can also be localized e.g., "007".
This is the right answer. Each parking SPACE requires a URN but it doesn’t matter at all if the URN is human readable, it just needs to be machine readable because humans won’t be doing the reading - computers will and they will translate the URN into the name that has most relevance to the individual user (‘near the GP’, ‘at my parents’ ‘shops’ … etc). There there needs to be a consistently applied taxonomy of all the features that apply to that parking space, again which are machine readable and openly licensed. However, this is the easy bit, speaking as a councillor in the middle of a CPZ consultation in my ward the main challenge will be getting both the councillor’s and the officers in all the country’s highways authorities onside… because network edicts mean that this needs to be done centrally across the whole of the UK.
"an actively bad idea since the identifier will not change but the amenities likely will." Came here to say this, except that I'd delete the 'likely'!
I did ponder that (very soon) the car will not only know which car park you're in, but have the app to pay for parking .
HI All. We have Unique Property Reference Numbers (UPRNs) for all carparks already. At GeoPlace, we collect data from local authorities and third party sources and collate into a national datasets of properties (including car parks) which is then licenced to the market by Ordnance Survey as the AddressBase Products. I'd urge you to look at this data (available under a free development licence to review it and play around) as it does contain a reference number for all car parks. We've been working on improving data quality for these features as we are confident that we have the vast majority of car parks recorded in the AddressBase data.
I think most of the comments have it covered but, generally speaking, smart coding is a dangerous game and shouldn't be necessary in a world where a quick lookup gives you all the associated metadata you need. I'd plump for a 6-10 digit, pseudo-randonly assigned (others mentioned neighboring codes being different enough not to confuse, which sounds sensible), and starting 1-9 to avoid issues with dropping leading zeros (in Excel, inevitably).
We should perhaps go back to the objective: to identify the location of a car park so that the appropriate payment can be made to its owner.
The user would necessarily have a dialogue with the app about the length of stay, the characteristics of the space (if the owner wished to charge more, say, for space at a charging point, whatever the electricity supplier charged, or for one near the walking exit).
The user doesn't need to know who the owner is, the app has that in its reference data; it also, clearly, must have the tariff.
Ten digits of National Grid reference (the OS one, not the power distributor) – two for the (normally lettered) 100km square, eight for the eastings and northings within it – give a reference to a 10 metre square, small enough to be unique even for small on-street parking places. The phone can know where this is, by cross-reference to latitude and longitude, or can read it from a 'QR' code, or, if all else fails, can accept the user keying it in.
This has the advantage of giving geographical reality and, potentially, user back-up – 'What Three Words' is a particularly useless device, as it gives no geographical data, just the contents of its index.
Don't reinvent the wheel!
James Mackay
There are two valid approaches here.
You can make a key long/complex enough to encode information, like an email address. Then it’s human-readable, and tells the user useful stuff. “Huh… W1S-BondSt-1234-EVPremium? I didn’t mean to use the expensive charger!”
Or you make keys entirely meaningless, just random numbers, with a publicly accessible API to look up the associated properties (which can now be VASTLY more data than you could encode in a usable key).
Option 2 is better. If you want human-readable, you can still create aliases that point to a specific key, just like DNS.
Trying to embed data in a compact key… that way madness lies. People give examples like telephone area codes, but I’m old enough to remember how confused my parents were when all the area codes had to be changed by adding a 1 after the leading 0, and I’m personally suffering from Sheffield running out of 01142 numbers and having to change the code to just 0114, which nobody believes.
10 digit number
grouped as 2 2 3 3
01 01 111 111
01 covers the type of parking e.g. 01 pay on arrival car park, 02 pay on exit car park, 03 on street, numbers allocated based on most commonly ocurring get lower numbers.
This could be a single digit but double digit allows for expansion e.g. motorbikes, electric recharging or just stuff we cant envisage now becoming important later.
next 2 are a geographic location gives you 100 locations, but they just need to be general areas. These should start at 00 in the orkney islands and get larger as you got further south. It could even mimic a grid, so 00 top North west Scotland and 99 would be south east england, so you could tell your approximate position (not really latitide/longtitude but an approximation.
next 6 are your individual car parks. These dont really matter aslong as they are unique within the geographic area, allows for reserving certain ones e.g. 080 085 and you could have as many 007's as there are bond streets.
Could you not lop off the first 4 digits and get the same effect? Then app users don't have to type as many numbers into an app on a cold, windy night with bad signal and a crying child, to pick a recent example
The term for a system that encodes geographic locations into a number or string is a "geocode", and there's quite a lot of prior art here: https://en.wikipedia.org/wiki/Geocode. But as others have said, it's probably a mistake to encode semantic information into the numbers - just let them be opaque numbers, possibly with Easter eggs as you describe. The only way I'd break from opacity would be by handing out prefixes to local authorities and letting them do whatever they want within their block of assigned numbers, much as we do with blocks of IP addresses.