Errors in Indexed Record Updated Place Names
I have previously reported problems with some historical record database collections in which the original name of a place was updated with an incorrect standard place name, receiving a reply which said:
Thank you for reporting the errors in the auto-standardization of some of the event places in the Norway Census of 1891. We have reported the errors to engineering. Unfortunately, they have a large list of similar errors they are working to correct in our massive historical records collection, so it will likely be quite some time before all are corrected.
However, not knowing if Engineering is aware of all of these errors, wanting to be able to keep a list of these to be able to keep track of ones I have reported in one place, wanting to have a place where I can check back and see if these are corrected yet, and knowing that I only use a small part of the databases, I have decided to start this topic as a place where anyone can post this type of error as they run across them.
I think it would help if we report these in a uniform format with specific examples. Usually these errors are the same for every instance of a place name in any one indexed collection so each error would only need to be reported once here. A good format would probably be:
- Collection Name
- Original Event Place applied to the Index:
- Incorrect Standard Applied:
- Correct Standard (if known and available):
- Example URL:
- (Notes if any)
I will post below ones I have already run across and add more as I happen to find them.
Best Answer
-
@7AM, that kind of error (and that entire collection) has absolutely nothing to do with the type of error being collected here.
"United States Public Records" is assembled by a data aggregator based on things like phonebooks. I'm pretty sure the errors in it outnumber the non-errors, but I consider that a security feature: it means that people cannot correctly identify or track down anyone using this database. (None the less, I think FamilySearch needs to stop carrying this index. It generates nothing but complaints and provides no trustworthy genealogical data.)
0
Answers
-
Collection Name: Norway Census, 1891
Original Event Place: Tysnæs
Incorrect Standard Applied: Tysnes Kyrkje, Tysnes, Hordaland, Norway
Correct Standard: Tysnes, Hordaland, Norway
Example: https://www.familysearch.org/ark:/61903/1:1:DJ2T-7KPZ
Notes: Tysnes Kyrkje is Tysnes Church
0 -
Collection Name: Norway Census, 1891
Original Event Place: Tysnes
Incorrect Standard Applied: Tysnes, Nordland, Norway
Correct Standard: Tysnes, Hordaland, Norway
Example: https://www.familysearch.org/ark:/61903/1:1:DJ5Z-3XN2
Notes: Caution! There is a Tysnes, Nordland, Norway which was just a small farm but it does not appear that any of the indexed records for Tysnes municipality were for that place.
0 -
Collection Name: South Africa, Cape Province, Probate Records of the Master of the High Court, 1834-1989
Original Place Name: Gordons Bay Somerset West
Incorrect Standard Applied: West, Somerset, Maryland, United States
Correct Standard: Gordon's Bay, Cape Town, Western Cape, South Africa. (Not sure about this one)
Example: https://www.familysearch.org/ark:/61903/1:1:QGLX-D8C2
0 -
This one is a little different.
Collection Name: Norway Church Books, 1815-1930
Original Birth Year: was blank
Incorrect birth year added: 1803
Correct birth year: 1903
Example: https://www.familysearch.org/ark:/61903/1:1:68Q4-7ZZ5
Note: Christening date did include the year which was 1903.
0 -
Collection Name: Norway Census, 1891
Original Place Name: Lindås
Incorrect Standard Applied: Lindås, Valestrand, Hordaland, Norway
Correct Standard: Lindås, Hordaland, Norway
Example: https://www.familysearch.org/ark:/61903/1:1:DJ5V-NTPZ
Note: There is a Lindås farm in Valestrand municipality, but these census records are for Lindås municipality which is farther north and much larger.
0 -
I notice that an incorrect "United Kingdom" suffix has been added to many pre-1801 records. The "Event Place (Original)" was correctly shown / indexed, but the "Event Place" is in the wrong format.
This may seem to be trivial, but I have been getting a lot of "Missing standardized place name" warnings lately, which appear to relate to this issue.
See examples at: https://www.familysearch.org/ark:/61903/1:1:N5ZY-JPD?from=lynx1UIV8&treeref=MZKL-7DH
https://www.familysearch.org/ark:/61903/1:1:N2DQ-C8W?from=lynx1UIV8&treeref=MZKL-7DH
0 -
You say: "Usually these errors are the same for every instance of a place name in any one indexed collection", but this not apply if the collection covers a wide area, of course. Take the "England Births and Christenings, 1538-1975" collection. There are a huge number of sources for totally different parishes in the collection, but a random sample examined appears to indicate that in about a quarter of these sources the original place name for events dated 1790-1800 has been incorrectly changed to a "Christening Place" that includes the suffix "United Kingdom".
How does one tell if the changes were made by the auto-standardization process or, say, a volunteer exercise where a manual exercise was responsible for the change in the original (usually correct, in this example) event place?
In short, I would be grateful if you would clarify exactly what examples you are looking for and if the dates do offer any clues as to how and why the original place names were changed.
0 -
Paul,
I decided to start this place for people to list the errors as I am seeing more and more complaints about this and that people are being told to just edit the place to correct it. Basically, this is the post that triggered this: https://community.familysearch.org/en/discussion/comment/378222#Comment_378222 (Not the original post, the first comment.)
What I meant by saying that generally only one example of error is needed, was that in the collections I have seen problems in, the same Original Event Name is changed the same way in the entire collection. For example, in my post above about Lindås, every occurrence of Lindås has been changed in the same way.
It is easy to tell which records have been corrected by a user and which were updated by what the reply I got called "auto-standardization." Here is an example where a user made a correction: https://www.familysearch.org/ark:/61903/1:1:QL8L-CJP1
I didn't notice before, but it looks like editing the place name removed the Original Event Name. That's not good.
0 -
Gordon
Obviously, this is a complicated issue - that is, the reason places have become standardized in the (incorrect) way they currently appear.
The "volunteer project" has been blamed for many of us having to "re-standardize" many place names they we know we had standardized correctly and suddenly, without any apparent change in format, showed as "Missing Standardized ---- Place".
The example you are highlighting is where all records in a collection have been standardized incorrectly but, as I have illustrated, collections like the "England Births and Christenings, 1538-1975" one - to which additions are ongoing and cover many different places in England, too - are only partially affected by this issue.
Still further, there are problems like the one another user recently mentioned here. From the screenshot below, how are we to tell how the correct location of "Needham, Norfolk, Massachusetts" has ended up appearing as "Needham, Norfolk, England"?
So, my main question is - do you want examples added to your thread that must contain an "Original Event Place" field, or are you looking for a more extensive examination (through a variety of examples) of how many thousands of records are now appearing (usually) with standard names from the database - but ones that are inapplicable to an individual source or (in your main example) a whole collection of (Norway) sources?
See record at https://www.familysearch.org/ark:/61903/1:1:QPCZ-BZP3?from=lynx1UIV8&treeref=9VD9-6X6. In this case, have all similar events been standardized (incorrectly) as "Needham, Norfolk, England"? As this has been highlighted by another user, I only have to assume so.
0 -
You're right. This is very complicated. My hope was that if we compile a list of sources with these incorrectly updated, not user edited, place names, that that will help make sure that as the programmers are trying to deal with the problem that they don't miss collections effected by this that people are actively using and maybe overly optimistically hope that those collections might get higher priority for being repaired.
1 -
"New York, New York City Marriage Records, 1829-1940," database, FamilySearch (https://www.familysearch.org/ark:/61903/1:1:Q2CX-HQMQ : 22 July 2021), James H Lott and Idat Keating, 04 Jan 1917; citing Marriage, Queens, New York, United States, New York City Municipal Archives, New York; FHL microfilm 1,902,743.
Didn't know where else to post this or who to contact, so I decided this may be as good a place as any. I apologize if this is not appropriate.
The bride's name in this record should be Ida. These are my grandparents. Any search of her name with that of her parents indicated in the marriage record will confirm this. Thank you.
0 -
Firstly, you should have created a post of your own, as this thread relates to errors with place names.
However, I'm afraid that wherever you had posted your issue the response would be the same. Unless you can edit the item / record yourself, there is no facility for it to be changed by FamilySearch.
In this example, if you hover beneath the "Edit" box, it shows the message: "Edit unavailable. Sorry, this record cannot be edited." All you can do is add a note of the error if/when you attach it to Ida Keating's Sources section in Family Tree.
You are fortunate in this being a relatively minor error - "Idat" instead of "Ida" - as many users encounter far more serious transcription errors, yet still cannot edit/amend them.
0 -
Example URL: https://www.familysearch.org/ark:/61903/1:1:6ZDL-4PF6
Collection Name: England, Middlesex Parish Registers, 1539-1988
Digital Folder Number: 007906592
Image Number: 00423
Baptism Place (Original) St. Matthews, Bethmal Green
(Typo - should be Bethnal)
Incorrect Standard Applied: Baptism Place: Ywathit, Mandalay, Myanmar
The entire collection comprises data only from Middlesex, England. How can the autoselector be populated with any places outside Middlesex, England ? Even with the typo, if the exact place name couldn't be matched, it should simply have defaulted to the Collection place, and flagged an error that the Place name could not be matched.
0 -
I was thinking this might be a metadata issue, but could only find Ywathit, Mandalay, Myanmar as the baptism place in this one record. Obviously, there might be more, but I didn't have time to check the 50,000+ results!
On a completely different issue, a search of all records relating to 007906592 shows that some have been indexed as both baptisms and christenings! (The ones with the camera icon as the former, those without as the latter.) See https://www.familysearch.org/search/record/results?q.filmNumber=7906592&q.surname=boyce (which includes your reported source).
0 -
I have previously had issue with the place name auto-selector w.r.t. the England and Wales Census. The family that I was researching had a lot of candidate members each of whom had to be traced and followed to attempt to verify whether they were part of this family, or another one. That required building a lot of mini-trees around each candidate. Each time I added a family member who was resident in Runcorn, Cheshire (remember this is the England & Wales census), the place name auto-selector would default to Runcorn, Christchurch, New Zealand. Now I just found this intensely annoying, but imagine the effect if someone is indexing a huge bunch of records, and is quite adept at the task, and can work speedily. They might reasonably presume that the source location will dominate when the auto-selector completes the standardised place name, and they might not pay great attention to what gets written into the record after they have copied the place name from the source.
The overall result will be a huge batch of records that will fail to appear when the correct place name is specified. In the above example, a search for records in Runcorn from the England and Wales census will not produce the desired results if the Location is set to England, because some of the records are now associated with New Zealand.
0 -
- Collection Name: United States Census, 1870
- Original Event Place applied to the Index:Beat 5, Marion, Texas, United States
- Incorrect Standard Applied: Beat 5, Marion, Mississippi, United States
- Correct Standard (if known and available): Judicial Precinct 5, Marion, Texas, United States (this is just another way of saying Beat 5, Beats are Precincts)
- Example URL: https://www.familysearch.org/ark:/61903/1:1:MXG3-PZY
- (Notes if any) I noticed this same thing on a few places in 1860 and 1880 as well, but can't find them now. I don't know why they keep marking the Texas places as Mississippi but it is problematic, when other people attached these sources, the imported residence says "Mississippi" instead of Texas.
0 -
Sorry this does not conform to the format requested, but this is so typical of many examples of the "United Kingdom" suffix being added (in an update of 22 March 2020) in place of the correct place name for the time - i.e. without the United Kingdom suffix. Why was it changed when the "Event Place (Original)" was correct?
1 -
Collection Name: Norway Church Books, 1815-1930
Original Event Place: Sola (Håland), Håland, Rogaland, Norge
Incorrect Standard Applied: Solakrossen, Sola, Rogaland, Norge
Correct Standard: Håland, Rogaland, Norway
Example: https://www.familysearch.org/ark:/61903/1:1:68QQ-3XNW
Notes: The original place name was an attempt to show that Håland parish, which this particular record is from, is now known as Sola parish. Solakrossen is a small village within the much larger Sola municipality. Sola municipality covers pretty much the same area as the former Håland parish (prestgeld). The records for Håland prestegjeld cover the four churches (or sogn) in the parish, Sola, Madla, Håland, and Tjora. The index did not always include the sogn.
0 -
Example URL: https://www.familysearch.org/ark:/61903/1:1:68VK-3ZFQ
Original Place: St John The Baptist Hoxton
Standardised Place: St John the Baptist, Muston, Leicestershire, England, United Kingdom
Correct Standarised Place Should be: St. John The Baptist, Hoxton, Shoreditch, Hackney, Middlesex
But, if you enter only "St John The Baptist, Hoxton" the correct place is not in the list. If you tag "Shoreditch" on the end, you can only choose "St John The Baptist, London...." or "Hoxton, London" neither of which provides adequate description.
0 -
Error in record https://www.familysearch.org/ark:/61903/1:1:J993-NVY
Original Place name: St Mary Whitechapel, Stepney, London, England
Incorrect Standardised Place: Altab Ali Park, Stepney, London, England, United Kingdom
Correct Standardised Place: Saint Mary Matfelon, Stepney, Middlesex, England, United Kingdom
0 -
Error in record https://www.familysearch.org/ark:/61903/1:1:68FN-DXVL
Source: "England, Middlesex Parish Registers, 1539-1988"
Many Errors referencing Leicestershire or Cornwall for place names
The standardised place name selection MUST be set to the location of the record BEFORE the records are indexed and then the standardised place name list MUST restrict the available places to ONLY those in that location.
Most of the errors in this collection could be repaired automatically. A few will need intervention to make the determination.
Edit:
Also https://www.familysearch.org/ark:/61903/1:1:6Z6V-FDZ6
Shown as Christ Church, Wheelock, Cheshire. Should be Christ Church, Spitalfields, Middlesex
0 -
Performing an exact search for birthplace "????*Salops*" will produce 144 results citing "Salopshire"
There is no such place. It is either Salop, or Shropshire.
These could all be corrected automatically.
0 -
As @Gordon Collett explained in his superb answer to https://community.familysearch.org/en/discussion/105732/why-does-this-happen
The matcher uses alternate names when locating a place name. It seems to break the entered place into parts, and looks for alternate names for those parts. If it finds a match for a part, it populates the list with those matches in alphabetical order.
As you enter more data, the previous match might be excluded.
So using the info below and following the process from "Oneida," forwards
Name -- 1st item in populated list
"Oneida," -- Oneida, Morales, Izabal, Guatemala
"Oneida, " -- Oneida, Morales, Izabal, Guatemala
"Oneida, N" -- Oneida, Morales, Izabal, Guatemala
"Oneida, Ne" -- Oneida Township, Kearney, Nebraska, United States
"Oneida, New" -- Oneida, New York, United States
"Oneida, New " -- Oneida, Morales, Izabal, Guatemala
"Oneida, New Y" -- Oneida, Morales, Izabal, Guatemala
"Oneida, New Yo" -- Oneida, Morales, Izabal, Guatemala
"Oneida, New Yor" -- Oneida, Morales, Izabal, Guatemala
"Oneida, New York" -- Oneida, New York, United States
The first match in the alphabetcially ordered list is "Oneida, Morales, Izabal, Guatemala"
You would expect it to be "Oneida, Brown, Wisconsin" before "Oneida, Morales" but no. It's sorted by Country first, and the Country starts with G so it jumps the queue ahead of all those in the US.
If you just stopped typing at this point,and hit enter, then you would expect to see the field containing "Oneida," and get the data problem "Nonstandardized Place", but you don't get that, instead the selector will automatically fill the field with the first match in the list. It forces you to have a standardised place. If you manually choose "Oneida," from the selectable items, it will put it in the field, and then attach the Standardised Place name "Oneida, Morales, Izabal, Guatemala" as well. So you're stuck. Your only option is to enter more information.
It remains "Oneida, Morales," even when the entered data is "Oneida, N" because there is no match for any place that has an alternate name "N" that also matches "Oneida"
When you get as far as "Oneida, Ne" it finds the alternate for "Ne"="NE"="Nebraska" and then the first place in the list becomes "Oneida Township, Kearney, Nebraska"
With "Oneida, New" it fails to match Nebraska, but there is no alternative for "New" that also matches "Oneida" instead it appears to match "New" as 'contained in' "New York" ** We'll come back to this later.
Next we get a wierdo.
With "Oneida, New " [note the space] you would expect it to match as above i.e. 'contained in' "Oneida" with "New York", but you don't. I think that's for the same reason that the "New Search" finds such dodgy results. The query matching algorithm strips all non-alphabetical characters from potential matches before comparison. So "Oneida" and "New " is not 'contained in' "Oneida" and "NewYork" because the criterion has a space in it and the stripped place name hasn't. As a result, the Standardised Place name goes back to matching "Oneida, Morales," because it's the first match for "Oneida"
Same thing for "Oneida, New Y"
When you get to "Oneida, New Yo", the matcher recognizes "Yo" as an alternative for "Yorkshire" as well as matching the various places called "Yo", but this precludes it from being part of "New Yo" so it can't match "NewYork". It's trying to match three place name parts now. "Oneida" "New" and "Yo", which it can't so it falls back to matching "Oneida", and the first in the list is again "Oneida, Morales"
The same happens with "Oneida, New Yor" because there is place called "Yor"
Eventually you get as far as typing "Oneida, New York" and the matcher gets it right.
So, to get the place name autoselector to work properly, you have to type a lot or trawl through a long drop-down list. BUT!
Not all the Standarised place names are correct. Some of them have been 'brought up to date' so they are not as they were when a document was created. To preserve an original place name, you cannot select one from the drop-down list. Instead you must type (or paste) it into the field, then select it from the grey section of the selection area, then separately choose the closest matching "Standardised place" as well.
** Back to "Oneida, New" - This is the shortest form that will result in the correct auto-selection. Any indexer (auto or manual) that puts in less than this will get Guatemala --- However: If the auto-selector was only populated with values using the Location of the source, or if it used the Location of the source as a priority when sorting, then it would be far better.
2 -
Error: https://www.familysearch.org/ark:/61903/1:1:QGRL-7VJ4
Source: New York, State Death Index, 1880-1956
Original Index: Oneida, Madison, New York, United States
Incorrect Standard Applied: Oneida, Morales, Izabal, Guatemala
Correct Standardized (?): Oneida, Madison, New York, United States
Comment: I agree with @LDS Search Test The auto-selector should be 'bounded' to locations within the record location meta-data(? whatever defines the location the collection originated from). There should be some method of making this a static/fixed location rather than changing to another location. Maybe it should start from the other end and get the country right first... 'New York, State Death Index, 1880-1956' - once the other locations in the document are 'pooled' obviously refers to New York, United States and not Guatemala.
Why is this and other automated processes changing the Index from what was originally entered now? And why on the production/published records? Can we expect more of this type of processing/mixing up of Indexes now?
The question which I think is trying to be answered here - why did the Index change from the location that was originally indexed? or am I misunderstanding what this post is about? I believe this record to which I refer above at one point was indexed correctly and now something has changed it.
@LDS Search Test I think what you are explaining is how the system - might have changed it due to some implementation of automated processes in place names? That might explain how it changed but not why. I am interested in knowing why these step-backward changes are occurring.
0 -
@genthusiast It's far easier for me to determine how a process works than to understand how people behave. I can only speculate about that.
2 -
More from UK Middlesex Parish Registers. Collection ID 3734475
14,057 results showing Standardised Place: Ywathit, Mandalay, Myanmar
0 -
I apologise for thinking this might have just been a "one off", when you first raised the specific issue of Middlesex records being standardised as if they were for Mandalay.
I am surprised that FamilySearch managers do not appear to be extremely embarrassed at errors like these - well, not enough to ensure they are fixed as quickly as possible, as is the case when such reports are received by other websites (small and large, from FreeBMD to Find My Past).
0 -
New York, State Death Index, 1880-1956
There are errors in the transcription of the Index. An original image of the Index appears in a window and at the bottom there is a transcription. The errors are in the locations of the deaths in the transcription. Presumably, the location of death should be in New York. The place of death for a person I was looking for was listed on the original as "Kingston" which I understood to mean Kingston, NY which is correct as the person lived in Kingston, NY. In the transcription, however, the place of death was listed as "Kingston, Jamaica." I was curious so I scrolled through the transcription and found many other such errors. On the original, a place of death was listed at "Pt. Ewen" which is shorthand for "Port Ewen", a place name in New York. On the transcription it became "Portugal." Other examples on the same page: "Rch." which is probably "Richmond" becomes "Rocha, Uruguay." "Lafayette" becomes "Lafayette, Louisiana." "Windham" becomes "Windham, Vermont." All of these are New York place names.
1 -
My Notifications advise you have posted comments here, about an hour ago, but I am getting a "Comment Not Found" message from the "link".
0 -
@Paul W I deleted the comment. I posted it on the wrong thread. I was simply saying that this is an ongoing problem that has very little to do with the indexing side of things. (But, I realize that Gordon created this discussion so everyone would have a location to post their problems with Place Names).
I guess my greatest hope is that FamilySearch will step up and write a report, a blog, a post, something... so that everyone knows that it is a universal problem, that indexers have nothing to do with it, and that it is being worked on and hopefully a solution is near. The problem seems to be growing in intensity. It reminds me of the 1958 sci-fi thriller, The Blob, which as some may recall wreaked havoc on a small town and the sheriff didn't believe the teenagers who saw it because they had no proof.
There's plenty of proof that there is a problem. Now we just need an official statement on what to expect and what to do in the meantime.
4
