Place name errors introduced in xls export
I noticed some strange place names in records I exported to xls (Search/Preferences/Export)
It occurs when the place is not a Standardised Place Name.
Example 1. Place Name in the tree ", Yorkshire, Yorkshire (West Riding), England" exported as "Cleveland, …….". Note the comma as the first character.
Example 2. Place Name in the Tree "Darfield" (alone, no other text) exported as "Darfield, New Zealand " (Standardised place should have been "Darfield, Yorkshire,…."
The problem appears similar to what happens when a spreadsheet tries to look up a value in a table which does not contain the value.
Could the original text in the tree be exported? And also, could the person's reference number (nnnn-nnn) be included in the export to facilitate users standardising the place names?
The ", Yorkshire, Yorkshire…." place name is very common on the UK 1851 census. About 10,000 instances.
Answers
-
@BrianPeaker just checking back to see if this issue has been corrected?
0 -
I wondered if this might be part of the problem with the auto placename standardizing algorithm.
0 -
On your comment about the " Yorkshire, Yorkshire (West Riding), England" format, this has been present in FamilySearch records for as long as I've been using the website. I don't know if all the records that include this have been passed over from Find My Past (the 1851 census ones certainly have) but they should never have appeared in that form, of course. Not only is the "Yorkshire, Yorkshire" bit unnecessary, but parenthesis should never appear, as they are forbidden characters in placename inputs in Family Tree!
I know nothing directly about how these (Yorkshire, Yorkshire (West Riding), England") records become "Cleveland…" records in the export process, but remember I once raised the whole issue of "Cleveland" appearing as a placename on the search results page(s) when there was no trace of that as the placename when the record itself was opened up. I guess there is some connection between the issue I reported (never addressed / any explanation produced for this) and what you are experiencing with your exports.
BTW - And as you are probably aware, the Cleveland area does have an overlap with the former North Riding of Yorkshire, but many of the records I come across relate to parishes in the old West Riding - many miles from the area that (more recently) came to represent the north east of Yorkshire and south east of County Durham.
1 -
Yes, this looks, walks, acts, and quacks like the place name issues that are becoming all too familiar. In the 1851 England and Wales Census collection, a search with the resident place of "Cleveland, England" yields 964,000 all with the place name:
, Yorkshire,Yorkshire (North Riding), England
I have seen other examples where the system has swapped an historic place name for a later place name and vice versa. I have also been seeing collections where the place names have been repaired but the filtering process still remembers the incorrect data. Hopefully, engineers will one day get this all sorted out.
1 -
That's interesting, as I just undertook a similar search with the resident place as "Cleveland*" which produced a totally different set of results!
As you will see, this gives 133 results, covering North, West and East Ridings of Yorkshire.
(Update - extract of my screenshot, and comment, from my 2022 post has just been added below):
UPDATE - have managed to produce the link at last! Please click on below and scroll down to my post (on page 1 of 2) of June 11, 2022 which shows how the results pages appeared back in 2022. This specific issue does now, superficially, appear to have been addressed, but I wonder if there is still that "Cleveland" link that comes into play when making an export, as described. Obviously, the search engine still links Cleveland to Yorkshire, as illustrated in our two respective searches (on "Cleveland, England" and "Cleveland*").
https://community.familysearch.org/en/discussion/125985/auto-standardization
0 -
Perhaps the problem is related to the wider auto-standardization problem, as you suggest. If so, this one appears to have been corrected (i.e., "Cleveland" no longer showing anywhere in the search results - albeit the ", Yorkshire, Yorkshire (West Riding), England" placename being a totally unacceptable format). However, "Cleveland" must still be lurking somewhere in the background, but it seems just as difficult to explain why the problem should now only surface in (.xls) exports as in explaining why it has only ever appeared on the Results pages (but never in the record - either as Event Place or Event Place Original), whether back in 2022, or in November 2024!
0 -
"Finally", here is the link to the page that illustrates the currently displayed result relating to the record of a John Wright, born 1824 Thorp Audlin (though Thorp-Audlin, with hyphen back in 2022) - see page 8 of 15, 10th entry down:
(See comparison to how it appeared in 2022, either through link or screenshot in my earlier post.
UPDATE - You can now see the "original screenshot", which has just appeared (after passing through the moderation process).
1 -
@Paul W Thank you for illustrating so well some of the many facets of place name standardization errors. We know there are multiple ways place names have been perverted from original indexes and are attempting to categorize them. In addition, the reports of unusual errors are needed even if they seem trivial. We need to understand if "fixes" are causing new issues or not fully correcting the original errors.
2 -
Thanks for your commenting on my post and the variation in transcription of Yorkshire place names. I can add "County of York" being entered as "York" which results in an inability to find a person in their birth parish.
The comment was about EXPORTING records rather than viewing them (I wanted to analyse large numbers of ancestors in my own database). The problem in the export is due to "garbage in, garbage out". It is usual to perform checks on any input field to make sure it is sane. In Paul's latest link the insanity can be seen in place names beginning with a comma. Software often split texts into fields with a comma (e.g. CSV). Defensive coding would spot the lack of the required data before the comma and report an error. This should have occurred at data entry and also during export. Without any data, export has tried to look up "<nothing>". Some common software used for this will return what appears to be a random answer - e.g. Cleveland.
I haven't heard any response to the export problem.
0 -
I think what we are all saying is that the errors you are seeing in the export are the result of the placename auto standardizing issue. Until the gremlin in that algorithm gets fixed, we can't trust that a place will be accurately represented anywhere in FamilySearch - whether as a list of record results on the website or an exported list.
3 -
Even accepting the reason provided could be unrelated to your issue with exports, it might take a very long while before the matter is investigated. There have been issues of many different types that have been reported - some by multiple users - during the last couple of years, which have still to be addressed. So, even if several other users report your specific problem, it will likely join an already very long queue of matters waiting to be investigated by the FamilySearch engineers. In other words, I'm afraid it is highly unlikely you will get a positive response any time soon.
2 -
Apart from the 'standarization' errors that have been introduced, which seem to be sporadic, there have been some blanket changes that have subtituted geographically impossible places in many existing records. All of the tax records collection for Manchester, Lancashire, England have been changed to Philadelphia, Pennsylvania, United States. It has now migrated to the burial records too.
Surely the change history for the collection will show how and when this happened so that it can be reverted.
I wanted to to tag this for SerraNola, but the tag mechanism seems to be broken too.
1 -
'Surely the change history for the collection will show how and when this happened so that it can be reverted.'
Exactly.
0 -
@SerraNola Tagging since @Re Searching was unable.
2 -
In the hope that someone might be able to fix this collection, here's an example
https://www.familysearch.org/search/record/results?count=20&q.surname=A%2A&f.collectionId=2075052
0 -
@Re Searching Yes, I do have a report for that one with this description:
19,000 burial records for Whittington Workhouse in Lancashire show in search results as Philadelphia, PA, USA. (DGS: 4510268, 4510277, 4510286, and 4510294)
9 million poor law tax records for Manchester township, 1795-1900 (175 films) show in search results as Philadelphia, PA, USA.
If you find more affected, let me know. As I think I mentioned in a previous post, we are trying to categorize the place name errors to roll issues that are alike into one work ticket. This one falls into the category of "Entire films changed to ONE incorrect place name (without any obvious reason)". As always, thank you for input.
3
