Placename standardization: revising the display name no longer works in many cases
I've given up on waiting until I can include screenshots; y'all will just need to go try it yourselves.
I can't put a date to this disimprovement, but I can no longer associate "Bőd, Vas, Hungary" with "Nemesbőd, Vas, Hungary" as the standard: if I try, the associated standard reverts to just the county, with no sign of the correct place on the drop-down list.
What I've tried: I typed Nemes-Bőd, Vas, Hungary into the placename field, and clicked the reddish text to keep what I typed. This picked the correct location for the standard while giving me the separate display versus standard boxes. I then edited the display box's contents to remove the prefix.
If I clicked the reddish text to keep my text as edited, then the standard box's contents changed to "Vas, Hungary" at the top, then four places in other counties of Hungary, one in Tibet, then the U.S. state of Virginia, then a place in Romania, two in Slovenia, one in Vanuatu (wherever that is!), one each in Italy, Sweden, and Pakistan, and then the Yugoslavia version of one of the places in Slovenia.
If I did as before with the editing, but clicked outside the box instead of on the reddish text, then it showed the desired contents for the boxes — but the "Save" button was disabled.
I have a vague idea for the reason for the change: it makes it exceedingly difficult to end up with, say, "Tennessee" accidentally associated with, say, "Tibet". But it is none the less aggravating as heck: it makes it impossible to enter places as they were called at the time of the event, unless the database is cluttered with every possible name of every possible place. (I'm perhaps making an unwarranted assumption, that adding "Bőd" to the Places database as a variant name of Nemesbőd would fix the problem.)
Answers
-
Doesn't work right in Safari, either. Sigh… Why this ever ending battle to keep the place standardizing working right?
5 -
"… Why this never ending battle to keep the place standardizing working right?"
Cynically - because no-one knows how it's supposed to work any more, therefore they can't code any changes nor test those changes…
Slightly less cynically - it also fails for me - I couldn't make "Bőd, Vas, Hungary" work (Windows 10, Firefox 125)
I then tested standardising a value as "Nantwich, Cheshire, England, United Kingdom" - perfectly successfully as it's a standard place.
If I then altered my standardised placename to the entirely fictional "Upper-Nantwich, Cheshire, England, United Kingdom", and then clicked on the red, it stayed standardised at "Nantwich, Cheshire, England, United Kingdom".
On the other hand, if I tried to alter my standardised placename to the also fictional "UpperNantwich, Cheshire, England, United Kingdom" (no hyphen), and then clicked on the red, it standardised upwards at "Cheshire, England, United Kingdom". Fundamentally it looks like the hyphen splits things and allows the Nantwich word to do its bit.
Also, as soon as I tried to shorten my name to "Nanwich, Cheshire, England, United Kingdom" (without the "t"), it refused to retain the previous standard.
I'd summarise it by saying that I can add or subtract separate words (delineated by space, hyphen or ???) to a standardised value but I can't alter the spelling of a standardised word within that single word.
Presumably, this means, therefore, that I can no longer enter new spelling variants of placenames - any and every spelling variant must be entered into the list of standardised placenames.
4 -
I've played around a bit more and it looks like what has been lost is the ability to lock the standard in then edit the display name. Checking the examples Julia and Adrian gave and using a variety of my own, what I see happening is that the standard always changes to the top standard in the drop down list when editing the displayed value. If the edit does not trigger any changes to the drop down, then the standard previously chosen appears to stay the same but probably what is really happening is that it is still "switching" to that top standard but since that standard didn't change, it looks like nothing happened.
Unfortunately this has removed a very valuable feature in Family Tree which allowed very flexible place name entry at the cost of a bit of confusion until a user figured out how it worked. Replacing the instructions on how to enter place names with a version that clearly explained the feature would have been better. I hope this is just a temporary accidental loss. If not, then I hope they more widely publicize how to request variant names be added to the Places database.
4 -
@Gordon Collett said:
"… it looks like what has been lost is the ability to lock the standard in then edit the display name … "
Agreed. In my head I'd got as far as wondering at what point it started recalculating the possible standards. Your phrase "lock the standard in" is a good way of putting it.
" … I hope this is just a temporary accidental loss … "
Me too. Will the engineers know what's going on? That's my concern…
4 -
Update: I just got the email from the places team that they've added Bőd and Beöd as alternate names of Nemesbőd. I tested it, and my assumption was correct: having every possible name of every possible place in the database would allow the current algorithm to work as desired.
1 -
@Gordon Collett @Adrian Bruce1 @Julia Szent-Györgyi - Sorry about the direct tagging but it seems something is afoot so I thought I'd try and prod the bear.
I'd noticed a postive change in the auto-place name chooser today, which I posted in the new Linker feedback. However, I also noticed a negative change a bit later.
Example:
OK so that didn't work, try again another way.
Then..
Hmm, that didn't work either. It seems that the forum has been subject to "a process of continuing improvement"
Nevertheless , I shall persist, let's try this workaround …
Well, I would have liked to have shown an example of how the place name in the original indexed source was not used to select a place by the chooser, and then to show that the actual 100% match was available in the list of choices, but was not selected as a probable match.
Give me while, and I'll sese if I can process the images as ASCII (…takes me back to dot matrix pictures), and see if they can be pasted without a permission problem.
0 -
@Re Searching, you're going to need to put the screenshots in Memories or some such, because only mods have been able to post images here since April.
Alternately, tell us what placenames you're working with, and we can go experiment.
0 -
Thanks Julia,
The target record was the 1841 census record : https://www.familysearch.org/ark:/61903/1:1:MQPF-QYK
which I was trying to attach to Sarah Ann Garside : https://www.familysearch.org/tree/person/details/KJVQ-X49
I have pasted a sequence snapshot of the place name selection issue into memories of her person record.
1 -
Bizzarre ! The image is there in memories, it's just a plain jpg, but when I try to view it I get "Well, this is unexpected..."
I can view a readable thumbnail if I right click and select view image.
0 -
That is truly odd.
In case all of the image viewers on FS start having conniptions, I'm adding a text description. The index entry has a residence place of "Saddleworth, Yorkshire, England, United Kingdom". When said residence is transferred in Source Linker, however, the place inexplicably changes to "Yorkshire West Riding, England, United Kingdom" — but deleting that and typing "Saddleworth" into the field reveals that the exact label of "Saddleworth, Yorkshire, England, United Kingdom" is in the database not just once, but three times.
2 -
@Julia Szent-Györgyi said
The index entry has a residence place of "Saddleworth, Yorkshire, England, United Kingdom". When said residence is transferred in Source Linker, however, the place inexplicably changes to "Yorkshire West
Riding, England, United Kingdom"I'm not sure that the change of place is totally inexplicable. The Event placename for the Index entry reads "Saddleworth, Yorkshire, England, United Kingdom", which is indeed in the Standard Places database. However, Saddleworth also has a down arrow by it, which, when clicked, reveals a second entry of "Yorkshire West Riding, England, United Kingdom" - the second entry is what ends up on the righthand side of Source Linker, even though it's not what's on the left! Surely it can't be a coincidence that it was involved previously?
I cannot begin to understand what's going on nor why. It would be good to know that someone understands it and can fix it. However, I fear that it's gotten so complex that…
0 -
I think Gordon mentioned something about synonyms in a post last year. It might be that "Yorkshire West Riding, England, United Kingdom" has been added as a synonym for Saddleworth, which is not good. If it were the case that a synonym can be created like that, then in principle everywhere could be given the synonym "Earth" and then the place name chooser would be a real pain.
0 -
At least I can say that Saddleworth doesn't have that as a synonym - I just checked it. It does have that as a related place, of type County (top level), which seems innocent enough.
I think that, unless I've missed it or forgotten it, we've never been told what the list revealed by the down arrow means. Or whether it still means the same today as when it first appeared.
I'm sure it's suggestive of what happened but I remain baffled about the sequence of software instructions, particularly since the basic placename of Saddleworth seems to be there...
0 -
Not so much Fuzzy logic as Fluffy logic, like an old sweet that you find in a pocket.
0 -
@Adrian Bruce1 Do you think that there's any connection between the above example of Saddleworth being offered as Yorkshire West Riding, England, United Kingdom, and the apparent replacement of many places in the 1851 census for this area. Huge tracts have become "Huddersfield, Yorkshire,Yorkshire (West Riding), England" when the actual places such as Golcar, Linthwaite, Slaithwaite etc. are given in the original record.
0 -
I guess anything is possible @Re Searching depending on how the census is indexed in FMP and in FS. Given I don't understand why Saddleworth was messed up, it's a step of speculation too far for me to guess about Golcar etc but it's surely not a coincidence!
0 -
I've noticed when using the new source linker to add a place in a christening, the place name gets dealt with in an inconsistent manner. If the place as shown has a prefix, such as "St John", will get stripped of the prefix leaving only the location, and not the church. But, if the place has no prefix, such as "Miles Platting, Lancashire, England, United Kingdom", then the chooser will offer "St John, Miles Platting (St John), Miles Platting, Lancashire, England" as a non-standardised place, which then requires the user to select what was already there in the original.
The corrections can be made manually, but I question whether it should be done at all. Would we be better without the auto-selector ?
0 -
I haven't explored enough to be certain, but I think Source Linker is showing the indexed text but transferring the autostandardized location.
It would be nice if Source Linker didn't take it upon itself to be Smarter Than Thou like this. Please let users make the decisions. Don't artificially limit them based on some flawed algorithm working on likewise-flawed data.
2 -
I've discovered yet another way that the standard-chooser has been severely disimproved: you cannot enter a name that happens to match a wrong jurisdiction and associate it with the correct jurisdiction. For example, it is no longer possible to end placenames at "England" while associating them with the (technically more correct) "England, United Kingdom" version: the UK bit must show, or it'll be the pre-1801 jurisdiction that's associated.
For England, it's largely just a perfectionist's quibble, because the database is more correct than not for that country, and there's nothing (yet) that "enforces" timeframes or place types. The map pin is the same and the place types are comparable for the populated place of "Bickley, Kent, England" (unknown-1801) and the hamlet of "Bickley, Kent, England, United Kingdom" (1801-1965). But the same thing's not true for Lugos, Krassó-Szörény, Hungary versus Német-Lugos, Krassó-Szörény, Hungary: the one's classified as a district, the other as a municipality. If I type the full jurisdiction, including the country, then the only way I can keep what I typed is to choose the district, and whatever I do, I cannot then make the display and background values be different.
In the process of exploring this new fault, I've discovered another one: we can no longer trust or believe the place-editing fields. What's showing in the top place box and what will be in it when you click Save may be two entirely different things. For example, one of the ways I tried to get around the "must choose the coincidentally-matching standard" was to add some text at the end: "Lugos, Krassó-Szörény, Hungary tt". This allowed me to click the reddish text and then choose a different standard. I then went back and deleted the extraneous characters, and then clicked Save — which saved it as "… Hungary tt". I repeated it several times to make sure I hadn't forgotten to delete the letters, but no: the currently-displayed contents of the field are not what is saved. What You See is Not What You Get.
2
