https://www.agi.org.uk/wp-content/uploads/2020/11/BS7666Guid...
# Standard data types used in BS 7666
CharacterString: a sequence of alphanumeric characters
...
The sign printer probably expects this format when printing signs for the government, or worse, has a contract that says the government must provide this standard format for the sign information.
So it's just a government mandated database schema... I don't think that's any better of a reasoning though lol
> How to use these standards > > The UPRN and USRN standards form a machine-readable addition to an address or street record held in a system. When using UPRNs and USRNs you can continue to use existing formats but add a field for these identifiers. https://www.gov.uk/government/publications/open-standards-fo...
Similarly Grangemouth apparently has a Bo'ness Road...
A related issue would be places in England named 'by-the-Sea', e.g. Newbiggin-by-the-Sea.
So the signs shall simply have to match reality.
https://en.wikipedia.org/wiki/Westward_Ho%21
Edit: ironically HN formatting couldn’t handle the exclamation mark either.
> Abbreviations and punctuation shall not be used unless they appear in the designated name, e.g. “Dr Newton’s Way”, and only single spaces shall be used.
Given that "alphanumeric" is vague, not defined, and prominently contradicted, I'd say it's quite clear that they can't really blame it on BS 7666.
The council probably have some horrible CSV-infested GIS workflow, and have decided to change reality to avoid the bugs.
So, even worse than imagined... it's an ambiguous standard blamed for a bad implementation of that standard.
If the standard restricts street names to those certain characters, may be it really is BS.
We love apostrophes so much we have them on our supermarkets. If they're not there we add them.
e.g. I'm going to Sainbury's
e.g. I'm going to Tesco's
...despite the fact that it's real name is plain old Tesco.
Why those dare to implement - and explain - standards who cannot comprehend their purpose?....
As a thought experiment, how far beyond the 'maximum' is acceptable? Latin letters with diacritics? Cyrillic letters? Arabic letters? Chinese logographs? Emojis? Would you expect all systems which are standard-compliant to be able to handle all of the above?
All the technical issues here have already been solved a hundred times, there's plenty of other options. It's a little worrying that we're eliminating punctuation in real life because of issues with integrating with geographical databases.
I know a business which has to pay a nominal $1 license fee for the names of its own stores to a map maker, simply because the business has lost any evidence that it had the names before the map maker put them in the map.
And people believe anything that comes out of a computer regardless of thousands of signs that something is really not right.
They rather prosecute others without doubt on mass scale rather than look into themselves.
(see the Post Office scandal)
https://news.ycombinator.com/item?id=40265929
> As far as I can tell, this isn't an issue with the specific database itself, but the standard they are required to record geographic data in, which the end of the article mentions as "BS 7666".
On the other hand, you’re naïve if you think English hasn’t already been simplified to fit on machinery such as typewriters and cheap printing presses. This process began long before computers.
Even cheap printing presses could handle more than you think. Here's a type case layout from 1846, again with æ, œ, fl, ff, and ffi, fi and ffl. https://archive.org/details/printingapparatu00holtrich/page/... .
That book is for the "Parlour printing press [which] was invented by Mr. Cowper for the amusement and education of youth, by enabling them to print any little subject they had previously written, provided the printing did not exceed in size the dimensions of an ordinary duodecimo page, which measures about 5 inches by 3 inches."
On one hand we have systems supporting Unicode and just about every character imaginable, it's an example of using technology to go beyond the limitations of the past. You could have a system that supports emojis on street signs, but instead we're going the opposite direction and introducing artificial limitations that are even more restrictive than 500 year-old technology.
When I moved I tried to fill in the form on their website to indicate that I wouldn't be paying the council tax on the house I used to live in anymore. Weirdly I couldn't make the form work, it broke with weird errors about timing out. After some headscratching I decided (on a whim) to change my computer's timezone back to GMT and hilariously the form started working perfectly.
Sadly I couldn't finish filling in the form, because it required a postcode for my new address, and would ONLY accept postcodes which matched the UK format (which my new address, in a different country obviously didn't match).
You shouldn't be surprised about any IT insanity from North Yorkshire Council, they are impressively incompetent.
It's led to some interesting outcomes - for example, I've seen people write "Princess Highway" a fair few times, presumably on account of the official spelling ("Princes") falling confusingly somewhere half-way between the more usual "Prince's" and "Princess".
In day to day use, I don't think most people actually use the apostrophe-free official spellings, at least for names comprised of ordinary English words (Prince's Hwy, Surfer's Paradise), but it might be more of a free-for-all with proper names (Wiseman's Ferry or Wisemans Ferry).
The "Princess Hwy" thing is also common I think because the pronunciation most often used sounds a lot like "Princess", particularly when it's run right into "Highway" without a gap.
St. James means something else.
So unless they go for St. Jamess it's have to be St. Jameses.
However, it does seem like it could be helpful when it comes to satnav applications to remove ambiguity. Google's going to autocorrect most of the time anyway, but this way, you're less likely to run into an issue where it takes you to Kings Landing in the wrong town because you didn't type King's Landing in the town you meant.
Sure, they tell you what town you're looking at, but I can't be the only one who's quickly typed in a destination and didn't take the time to double check and ended up driving to the wrong location for something. For some reason all of the hockey rinks near me have almost identical names...
That's pretty uncompelling. Should we also get rid of the letter s to avoid mix-ups between Kings Landing and King Landing?
Thomas’ and Thomas’s are the same thing.
> Some writers and editors add ’s to every proper noun, be it Hastings’s or Jones’s. There also are a few who add only an apostrophe to all nouns ending in s.
> ..One method, common in newspapers and magazines, is to add an apostrophe plus s (’s) to common nouns ending in s, but only a stand-alone apostrophe to proper nouns ending in s.
> Examples: the class’s hours; Mr. Jones’ golf clubs; The canvas’s size; Texas’ weather
That should break untold numbers of systems.
> [H2] provides a way to enforce usage of parameters when passing user input to the database. This is done by disabling embedded literals in SQL statements. To do this, execute the statement:
> SET ALLOW_LITERALS NONE;
> Literals can only be enabled or disabled by an administrator
I guess there are lots more in other languages...
Ruby Wang... did not mind the changes. "To be honest with you, because I'm not from this country it doesn't matter because it's the same pronunciation," she added.
They "solved" this problem by just having you enter the street name with no punctuation or suffix (ave, st, etc), and if there is a collision the form pops out a drop-down selector to have you disambiguate.
It's not the cleanest solution but it works. I agree that bending the humans to serve the needs of the machine feels... Sub-optimal.
I wonder what address verification services expect for the “numbers in the address” when the address is 123 1/2 4th Ave #5”.
Apostrophes seem like the least of anyone’s concerns.
USPS APIs in general:
https://www.usps.com/business/web-tools-apis/#dev
https://www.usps.com/business/web-tools-apis/documentation-u...
The specific API:
https://www.usps.com/business/web-tools-apis/address-informa...
BS 7666: 2006 is based upon an International Standard ISO 19112 Spatial referencing by geographic identifiers.
If a standard isn’t publicly available under a free license it should not be called a standard.
https://www.agi.org.uk/wp-content/uploads/2020/11/BS7666Guid...
4.4.1 Street names The designated street name is usually to be found on the name plate on the street. However, these may not always be correct, and may differ between the ends of the street. Unofficial street names are ones that have not been adopted by the appropriate Highways Authority but may be in common usage, e.g. "The Great North Road". Street names, whether designated or unofficial, should be recorded in full. Abbreviations and punctuation should not be used unless they appear in the designated name, e.g. "Dr Newton's Way". Only single spaces should be used.
So I think all its saying gazetteer editors should not add punctuation if its “missing” from the designated place name.
Punctuation is fine if it already part of the place name.
I think the intention is to preserve the original place name.
So the council is wrong to blame the specification.
>GeoPlace does not advise that councils include or remove punctuation in official naming or on the street name plate. Street naming and numbering is a council policy decision.
>However, the Data Entry Conventions documentation does state that GeoPlace would prefer not receive data (including street names) with punctuation.
>This is for two main reasons:
> machine readability – punctuation can be misinterpreted by computers
> usability – for example, if loaded into say an emergency service command and control system and a caller provides a street name, the search will be faster if the search is entered and returned without punctuation.
https://www.geoplace.co.uk/street-naming-and-numbering/guida...
This isn't a new issue. Around 1990 one of the computer labs at my school was run by someone with an Irish surname starting "O'", and I remember him complaining about software which couldn't handle his name.
It's been 30 years, and there are still problems?!?
(To say nothing of "Madeleine L'Engle" or any of many others with an apostrophe in their name.)
https://members.parliament.uk/members/commons?SearchText=%27...
I am all for keeping in the apostrophes as they are mini 'flashcards' to help the youngsters learn the value of punctuation. I also think that it is out of respect for residents, if I was on 'St. Mary's Road' and I had to write 'st marys rd' then I would worry that people outside Yorkshire might think I was illiterate.
One day a UK county will do an excellent job of signs, so people always know where they are without SatNav. Remember that many signs were removed just in case the Germans arrived, and we couldn't have them finding their way around, could we?
North Yorkshire council could trial some best practice signage that involves having actual signs instead of making the punctuation vanish. They could get an unexpected tourism boost from doing so with mildly fewer cars on the roads.
https://news.ycombinator.com/item?id=40265929
> As far as I can tell, this isn't an issue with the specific database itself, but the standard they are required to record geographic data in, which the end of the article mentions as "BS 7666".
On the other hand, you’re naïve if you think English hasn’t already been simplified to fit on machinery such as typewriters and cheap printing presses. This process began long before computers.
It is named primarily for Peter Stuyvesant and Peter Cooper (NYC historical notables), secondarily for Peter Piper, Peter Parker, Peter Pan, Peter Peter Pumpkin Eater, Peter Rabbit, and Peter from "Peter and the Wolf".
Seems they use Peters Field and Peter's Field but not Peters' Field.
We all know that older systems had problems with encoding and escaping special characters, but wouldn't they have encountered and dealt with all the possible problems by now?
So first question in my mind is what/why is this software that they are attempting to accommodate??? Or is this all just based on misinterpretation of the mentioned BS7666 and nobody thought to check it??
Our tools should adapt to the needs of humans, not the other way around!
https://en.wiktionary.org/wiki/Appendix:Spanish_alphabet
https://web.archive.org/web/20150426001803/https://www.nytim...
This particularly irked me as unicode was a few years old at this point, and while not really adopted yet, was clearly the future.
So I thought, how can this problem be solved? IMHO by doing a hex representation 0x00-0xFF per char. That would also increase entropy.
MySQL and other databases would need to support hex input of passwords, also setting of hex passwords via SQL.
Post office scandal about the inability to add numbers, a tiny line f uk the whole system, and we want to give your life into the hands of AI systems. What can go wrong?
(If all you have is a phone, everything can be solved with an app.)
But unrecoverably modifying the data to fit within constraints on input, storage or output seems a rather poor "solution".
... but in reality, no human was messing with those; system bugs were dropping or duplicating data. The government should not have trusted claims of a third-party without independent auditing they controlled (and, ultimately, I think that's the takeaway that all governments should be taking from this disaster).
Around here (Melbourne, Australia) I don't think they are ever used. "Princes St" etc. It's fine.
Searching if users omit the apostrophes, etc.
