* On Hold until 13 Dec 2024: Abbreviated Place Names

[tatewise]

Proposal 1. refers to an Options > Main page for charts, which does not exist, and currently the Place Format settings are on the Text tab via the Edit Text Scheme feature. i.e. Place formatting can be set independently for each Text Scheme and probably should continue that way.

Proposal 1. refers to the Use Short Form for Repeated Place Names but that only applies to Narrative Reports.
It suggests that option and the new Abbreviated Place Name option cannot both be checked.
IMO they could both be checked so that once the Abbreviated Place Name has been shown in full then it can be shortened if it is repeated later.

Proposal 4. does not make it clear enough that FH is expected to automatically populate the new proposed fields from installed lookup tables.

In general, it is not clear what happens if the Abbreviated Place Name option is chosen and a Place record has incomplete or empty SPC &/or Country fields.

[AdrianBruce]

... For each place name (row in the place table), add a corresponding 'Abbreviated Place Name' field for State/Province/County (SPC) and another for the Country. ...

Specific question - is the proposal suggesting that the abbreviations apply to the last two elements of the placename? In which case, it would surely be clearer to say that.

[AdrianBruce]

In general, I rather like the idea of being able to pick up an abbreviated placename. What I am very dubious about is attempting to fit ISO3166 into the picture - and I say this as someone who gets tired very rapidly of attempting to deal with the FamilySearch Standard Placenames database. Some specifics re ISO3166:

• Some of the lower-level codes in ISO3166-2 (the 2nd-level codes) are not what I would regard as 2nd-level codes for my purposes. For instance, I would never encode a placename as "Sutton, Great Britain". Exactly which Sutton would that be? But ISO3166-2 https://en.wikipedia.org/wiki/ISO_3166-2:GB has GB-STN (London boroughs count as 2nd-level for some reason). I would encode that place as "Sutton, London, Great Britain". I am not sure how any automatic algorithm could encode this in a useful ISO3166-2 compliant abbreviated form - GB-LND is the City of London, not Greater(?) London.
• I'm unclear how to handle the top-level code for the UK. According to Wikipedia, the top-level code is "GB" - so is it hard luck if you want to use "England" and have an automatic interface to ISO3166-2?
• The biggest issue with an automatic interface to ISO3166-2 is the historical angle. How would it work if you have placenames ending in "Czechoslovakia"? Or "Bohemia"? Etc, etc.
• Even for nominally current placenames, while some of us do use the administrative divisions of today (e.g. "Cheshire East"), plenty of us stick to the historic counties such as "Cheshire". Only "Cheshire East" is in ISO3166-2.

Personally, I think interfacing to ISO3166-2 is likely to be something of a waste of time and effort. I'd rather see the ability to specify an abbreviated form that I define for each placename. I guess the issue there is whether to have some sort of inheritance facility to ensure that the "United States of America" is consistently abbreviated to "USA" (say) - and not partly to "US" and partly to "USA".

[jimlad68]

I am a very big fan of standardisation, even if they are not perfect, ISO standards etc, ISO dates like yyyymmdd. But as we have reiterated many times through this forum, PLACes are a minefield. So I fully understand where Adrian Bruce is coming from.

E.G. - Whilst it seems normal for UK residents to use England as a top level, from an international perspective we live in the UK (as you soon discover going through USA customs) and England should be the 2nd level. I am surprised that "Great Britain" is used and not the UK as GB means different things in different situations.
- Do we use historical or current place names which themselves are likely to change.
- I like to order my PLACe parts biggest first, so that it sorts "out of the box", far more logical and computer friendly, just as the ISO standard yyyymmdd does.
Etc etc

Not forgetting that the only sure way to notate a place is by a GEO location, which should be the "root" of all PLACes.

The solution implemented must be user centric

Very much agree:

So for me the most important feature is to offer a simple ability to amend/create sets of abbreviations for different circumstances.