Entire film indexed with incorrect location

LegacyUser

Heidi Marie Soderquist said: Film 1810971, which is the collection for Taufen 1841-1857 of the Fürstenwalde parish of Kreis Ortelsburg, Ostpreußen has been mis-indexed with the event place listed as "Fürstenwalde, Lebus, Brandenburg, Deutschland." These locations share a name, but are not even currently in the same country (One is in Poland, the other in Germany). Is this something that is fixable on your end?

In addition, most of the entries have been indexed as the wrong year. They either say 1873 (which is not the case for any entries in this collection) or 1857 (which is at least correct for a section of the records, but not as many as it has been attributed to). I realize this error may be more difficult to correct. If its possible, I'd even volunteer myself to correct the years in the index entry by entry.

I'll be happy if you could at least fix the location though.

LegacyUser

A van Helsdingen said: There is currently no means for indexes on FS to be corrected, even in cases like this where serious errors have been made. FS have promised for years to introduce a feature allowing users to suggest corrections to indexes, but there is no timeline for when this might actually happen.

LegacyUser

Phil Jeffrey said: This one depends on how the metadata is laid out. I'll open a bug request to have engineers look at it.
As announced at RT Error correction by end of year but it's closer than you may think.

LegacyUser

Heidi Marie Soderquist said: Thanks for checking. The "Church" line of the index lists the proper location. It was just the "Event Place" that was incorrect. I figure the correct location must be hidden somewhere within the file because FamilySearch was still able to hint several of the records for the correct people, even with the location error and the dates being off by up to 32 years.

LegacyUser

Tom Huber said: Phil, Ron Tanner at the 2018 RT conf said that error correction would be in place by the "end of the year." I'm not going to hold my breath.

LegacyUser

Phil Jeffrey said: I understand. Just a little insight behind it. It's not just fixing errors. You need to save them as an alias and then the search engine needs to find it, then the hinting engine as well. Changes had to be made to several systems in order for it to all work together. You won't have to hold your breath much longer.

LegacyUser

Adrian Bruce said: As has been said many times, if an error is endemic across a film / item / something, it is seriously not appropriate to expect patrons to use the (intended) index error correction facility to update some x-hundred indexes.

Apart from the workload issue, the incorrect indexes need to be deleted entirely - a parish register item where several hundred indexes have been assigned to "Wilmslow, Cheshire, England" instead of the correct "Wrenbury, Cheshire, England" simply because Wilmslow was the first item on the film (that's not meant to be a precise error but it's not far off) needs to have all the Wilmslow indexes for that item deleted and replaced by the correct value. That is simply not sensible for patrons to do.

LegacyUser

Tom Huber said: What amazes me is that the index errors have been around for at least a decade (when FamilySearch was first released to a select few people) and it was brought up over and over. Had the means to correct the indexes at that point been made, when the system was not nearly as complex as it is now, then it would not have taken as much work. The systems, as they were introduced, needing to integrate the corrections, additions, and changes, would have had this happen as they were developed.

Excuse after excuse was made all they way back then and I was just one of the ones requesting the feature (and arguing for it). Needless to say, it should have been part of the initial design for the index system, but was put off for "higher priorities". By the way, I was a missionary in the Church and Family History mission training zone (in the Joseph Smith building) at the time and so got to try FamilySearch, the then indexing system, and watched as FamilySearch slowly came into its own, replacing newFamilySearch.

I don't think it needs to be said, but I have never been a happy camper with FamilySearch's approach. All the way back when this thing was getting off the ground, Ancestry had such a system in place. They have continued to improve their correction system over the intervening years while FamilySearch is tied up just integrating a correction system into all the newer features that have come along.

In the meantime, index after index has been dumped into the system with some of them having gross errors -- Adrian in his response brings up another indexed collection that has just as gross an error as the one that Heidi raised. I ran into one that was an index for the second page of a set of marriage records, which I reported not that long ago (https://getsatisfaction.com/familysea...) for which you opened a bug report. I don't know if anything will be done with that set or not, but Adrian is correct. A bad index needs to be pulled, rather than sit out there generating hints that it should not.

You've got three examples (between mine, Adrian's, and Heidi's) where there is a gross error. Way back a number of years ago, another one came to light which had the wrong ship's name on a passenger list index. It was spread across a lot of people and I don't know what happened there, but without any doubt on my part, I suspect there are even more.

All of these grossly misindexed records, meaning those records where a major problem is spread across all of the records in the index, has given FamilySearch a very big black eye. So much so that I automatically check the index against the image (when it is available) and then make corrections to the sourced entry as needed.

LegacyUser

Tom Huber said: I fully agree that grossly misindexed indexes need to be deleted entirely and in addition to being sent back through the system, they need a flag that indicates why the system was pulled and sent back through for a new (hopefully correct) index.

LegacyUser

David Newton said: Yep. There are vast sectors of collections that have this problem. "Bentley, England" instead of Bentley, Hampshire, England, United Kingdom. "Warwickshire, England, United Kingdom" instead of whichever actual bit of Warwickshire it actually is. "West Clandon, Surrey, England" instead of Cove, Hampshire, England, United Kingdom. "Odd Rode" instead of Oughtrington is another example in Cheshire. Froyle, "Houts", England. What county is "Houts"? Oh yes that's right, it doesn't exist.

Again we come down to the issue of basic quality control lacking in workflows. These are NOT errors that are introduced at the indexing stage. These are errors that are introduced at the metadata preparation stage. Sloppy, shoddy work that shows no signs of being fixed. Some of it is old like the "Houts" example above, but some of it is from collections that were uploaded THIS YEAR.

Ancestry has the ability to do index corrections. Findmypast has the ability to do index corrections. I don't know, but strongly suspect that My Heritage also has the ability to do index corrections. However this goes beyond index corrections as others have said.

LegacyUser

RealMac said: Regardless of whether individuals will soon be able to correct individual records, after this feature has been discussed for about a decade, the other type of error, where metadata are wrong, is the responsibility of FamilySearch and must be fixed by FamilySearch. Fixing metadata should be an elementary exercise for the software engineer, and a desk procedure for helping the software engineer correct metadata should have been formalized long ago. No more excuses!

LegacyUser

Phil Jeffrey said: You know negative criticism like this will drive those that are trying to help away. Think if you were an engineer and read this would you want to help? We want engineers and those from FS to give you some answers but this surely doesn't help the cause.

LegacyUser

Carolyn Wheeler said: It’s easy to find fault, attach blame, point out failings, and make sweeping demands. It’s not so easy to come up with solutions. The world of tech is not new to me, and one thing I have learned over the years is that what seems like simple solutions are NEVER simple solutions. Those things that seem like they should be the easiest to fix often end up being the most complex - and the most aggravating.

The world of programming and coding is stressful and demanding. The hardest part is when demands are placed on you by those who don’t understand the mechanics of how to make them happen, or the ins and outs of inter connectivity in such a fluid world. It’s a domino; you touch one, and you may be surprised what else it touches!

Do I have a thousand wishes? A thousand frustrations even? You bet!! But do I have gratitude and appreciation for how far we have come? Absolutely!! We are a long ways away from the days of PAF (thank you very much!!!).

I no longer have to steal away hours to drive a long distance to a Family History Center with inconvenient hours and then hope that not all the microfilm readers are already taken. Now my Family History Center is my home and it is open 24/7. Now I can instantly access any and all parish records that I want instead of having to wait weeks for them to arrive. And not only that, but I can zoom in on images, bookmark them, and screenshot them. And it’s free!!! My productivity has shot up by 1,000% and that is NOT an exaggeration.

Phil, what you and your colleagues are doing is without precedent. Really? One giant tree for all mankind?? Only God, Himself, could come up with such an idea and provide the tools to make it happen.

Thank you, programmers and staff for all you do!! You make my little heart go pitter-pat.

LegacyUser

Tom Huber said: It isn’t an engineering problem that we’re complaining about, Phil. I hope you recognize that.

The problem is two-fold (possibly more): Procrastination in getting what you are saying is coming, and an unwillingness to pull indexes back that have metadata (gross indexing errors from the setup) problems.

Now if engineering is working on a fix for the metadata issue, then that’s great. But unless you know something we don’t, I do not believe that is what is being prepared for release whenever that will happen.

The metadata problem might have a software solution but those tend to make matters worse.

LegacyUser

Paul said: Phil

This issue should not be taken as any personal criticism, as it relates to a problem that should have been addressed many years ago: probably before many of today's engineers were even employed by FamilySearch.

So three main points:

(1) This is NOT negative criticism - solutions have been suggested AND other websites already have a provision to deal with this problem.

(2) As has been mentioned, the main complaint here will not be resolved by the enhancement you advise is soon to be introduced. In practical terms, this will only help in dealing with errors for an individual - not the thousands that might be subject to a data error that has been applied to every entry on a film.

(3) Any engineers that read this thread and are then (due to a few sharp comments) deterred from helping to put matters right should be thoroughly ashamed of themselves. It is surely the job of FS management and engineers to present accurate genealogical data on the website, so I would be appalled if anyone were to think (as you suggest), "Oh yes, there is a serious, ongoing problem here, but because of the attitude of contributors to this thread, we're certainly not going to do anything to remedy it."

I have apologised previously for upsetting you, Phil, when you are one of the very few FS employees trying to provide help through this forum. However, you (and by implication your colleagues) must be more sympathetic towards the feelings of the frustrated users who are trying so hard to improve the integrity of FamilySearch's data and have been continually told this problem is of low priority.

I do worry about the personal feelings of others, but hope you are wrong in suggesting engineers might become vindictive if offended by "negative" comments, which might lead to their deliberately putting aside very necessary enhancements.

LegacyUser

Phil Jeffrey said: Carolyn
Thanks for the comments. Positive feedback works much better.
While I know the frustration if we pulled every record that has an error, indexing, metadata, then all the records that the clerks, clergy, governments, census takers and any other record that a human makes a mistake on we would be back to asking for documents by mail.

I am thankful for any breadcrumb FS provides as it is much more helpful than having nothing. I hate it when I have to manually search every image so even with an index that has an error I will take it over manually searching. Does FS have mistakes sure but like all genealogists I validate that data to make sure it is correctly sourced and verified.

Just a note as well, Getsatisfaction isn't a requirement to watch for any engineer or employee including me. Everybody I know does it because they want to help so they take the time away from other things to read posts.

LegacyUser

Paul said: Phil

Many GetSatisfaction participants engage in genealogical research on a daily basis - using FamilySearch and many other resources in this respect. So perhaps it SHOULD be a requirement for engineers - especially those with little experience in genealogy - and other FS employees to visit this forum on a regular (if not daily) basis.

Even with my 33 years experience (including being with Family Tree from its introduction) I obtain so much useful advice - especially with regard to using the FS websites. Collaboration is supposed to represent the ethos of FamilySearch, so I feel employees could play a really useful role in this by coming here and noting the constructive ideas of some very experienced users.

I have received some really rude responses from a couple of GetSatisfaction participants, but I have still given them a "gold star" when they have posted a really good suggestion here!

LegacyUser

Phil Jeffrey said: I have no influence on who watches getsatisfaction and making it a requirement but I do believe FS gains a lot of useful information from watching. I'll do my part with the limited opportunities I have. The one big thing I can add is if the problems are described in such a way I can duplicate them I can open bug reports, which you notice I do.
I can also add hints as to what's happening but that's a very fine line between announcing before it officially announces which I can't do.
I can say FS has lots of pilots going on right now. Pilot=limited release. New Search pages and error corrections (name only) are 2 big examples currently. Typically you can tell if you are on pilot page you will see a feedback button on the right side of the page. The feedback goes directly to engineering and is a great opportunity to improve that particular feature.

LegacyUser

Adrian Bruce said: Phil - thanks for the insight. I'm fairly certain that I never realised the significance of the feedback button, so thanks for that understanding if I come across any.

You are absolutely right that problems need to be reported in a way that the engineers can reproduce the problem. Many times I have muttered "PID?" at the screen when reading a vague, generic description from a fellow patron.

I understand that you can't set policy and priorities but I would ask that you encourage the management to use this forum. Communication needs to be a dialogue and all too often FS isn't good at communicating the good stuff well. The new User Interface with its tabs and inability to reorder sections was a case in point. Feedback was being given in here but no one was quite certain of the degree to which that feedback was read - then implementation with no announcement until the day.

In this scenario, the contributions of you and your fellow engineers really are appreciated.

LegacyUser

Tom Huber said: Phil -- I seriously hope that name only corrections are not going to be it. I am sure you will see a whole lot of complaints that the corrections do not go far enough. Names are just a minor part of the indexing errors that we see in the system and those are all understandable.

Ancestry allows corrections to far more than names, so hopefully, we won't see a half-baked correction feature that needs a lot more work.

LegacyUser

David Newton said: If name corrections are the only thing you will get massive complaints. If they are the first thing launched but other fields will be supported later then you need to make that crystal-clear at launch to avoid said complaints.

Beyond names the most vital thing is to correct places. Places where events occurred has already come up, but as we've said that's often an example of poor metadata preparation for a whole chunk of the index. The examples I gave came from the old IGI-derived data and from parish registers uploaded this as recently as this year. With this sort of correction it is not an alias issue at all. It's a replace the incorrect entries in the master index issue.

However there ARE place issues where a more normal alias-based correction process is appropriate: single entries in parish registers where an event has taken place in an unusual location for example. The most pressing place fields where that alias based correction is very much needed are birth places in censuses and residence locations in both censuses and parish registers.

What we also need to be able to distinguish between are transcription corrections and further information corrections and insight corrections.

What do I mean by those three categories? Transcription corrections are correcting errors made by indexers misreading the original document. They are nice and simple. Further information corrections are adding information that was not transcribed in the original indexing but is present in the record image such as a date for a parish register-derived residence and making sure that such residences are associated with all appropriate individuals in the index. More complicated to do, but still fairly simple.

What about insight corrections,? These are very tricky because they span the gap between FSFT and indexing. So let me give a concrete example. Near where I live is the village of Bishops Tachbrook. Also near where I live is the hamlet of Tachbrook Mallory. In censuses and parish registers residences and birth places are very often abbreviated to simply Tachbrook. It is almost certainly the case that Bishops Tachbrook is what is meant. Tachbrook Mallory is essentially three houses, although one of those house is pretty large (lots of servants in the past large). However the standard places database interprets Tachbrook to mean Tachbrook Mallory. An insight correction would be to point that to Bishops Tachbrook, not Tachbrook Mallory.

Now you could argue that should be done in the FSFT profile the record is attached to. However it is possible the record could be attached and detached and re-attached multiple times to different profiles. The insight correction stays the same and should be suggested at each attaching. Insight corrections could be like my example of correcting standard place name interpretation, they might also be expanding abbreviations and acronyms in the original record. Jas to James. Geo to George. Gt to Great in a place name.

Insight corrections would have to be treated differently to transcription and further information corrections. They are not reproducing exactly what is in the original document but providing an interpretation of it.

One thing I do fear with index corrections is a phenomenon sometimes seen here on Getsatisfaction. What I mean by that is an irate relative comes steaming in and says Great Uncle Bob is indexed as Rob or Robert and insists they must be referred to as Bob when the original document actually DOES say Rob or Robert. With indexing correction someone could stick in a correction which they believe is a transcription correction but in reality is an insight correction. So another facility that needs to be available is to mark "corrections" which are nothing of the sort.

That could also be a possible route of preventing at least some dumb, destructive merg… [truncated]

LegacyUser

Adrian Bruce said: "transcription corrections and further information corrections and insight corrections."
That's a rather nice categorisation. If indeed we are talking of FS doing this by setting up aliases as Phil appears to imply, then that's good news to me because it avoids arguing over whether something is "mu" or "um" (count the vertical strokes and you'll see the problem). By using aliases (as per Ancestry, I believe) rather than replacements of transcription errors only (as per FindMyPast), then logically most complaints (about insight corrections in particular) can at least be mitigated.

As for the scope of corrections, well, I'm optimistic that FS will be going beyond names. But to repeat an old point - FS really must communicate by telling us what the immediate scope is and what the intended scope is. Otherwise there'll be an almighty car crash of expectations. I hope you can help get that message through Phil. I don't have a problem with a first phase of corrections being just for names, providing (a) we are told what's happening in the immediate term and (b) we get told what the future intentions are. As for that last one, no-one reasonably expects dates and it's always possible that functionality isn't quite what was hoped for in the end. Just trust us with some information please FS....

LegacyUser

Tom Huber said: Mm. Having worked with Ancestry for many years, I know that their index correction started at a simple place with the name of persons. However, they were also not guilty (to the best of my knowledge which does not take into account the British Isles situation with places and their names) of gross metadata errors that we've seen with FamilySearch indexes.

It would help to have FamilySearch dedicate some of its "limited" resources to correcting metadata errors that involve more than records where a transcription error took place (and is forgivable as long as it is also set up to allow corrections searching, which appears to be the situation).

I'm not sure Phil (or Joe Martel) is in a position to know what is planned for future feature development, but hopefully, FS will dedicate at least one person to correcting metadata problems if they are unwilling to pull an index from production when a major error is noted.

And hopefully, there will be a means by which metadata errors can be noted by people who know, such as those who live or have lived in the places involved.

And Phil, thank you for being willing to communicate with us on this important matter.

LegacyUser

David Newton said: Oh Ancestry have some real howlers in their places data alright. The BMD indices for England and Wales are infested with rubbish. Again it's the registration district hierarchy getting shoved together with the administrative/geographiical county hierarchy that caused a lot of the issues. Then we have the christenings which took place in "England" according to their source attacher!

LegacyUser

Jason Pierson said: FamilySearch has a team dedicated to fixing data errors and they correct thousands of records every week.

When errors are reported directly to FamilySearch Support, Support should be forwarding them to this team, who puts them into their backlog and works their way through them.

Phil's ticket was picked up by the data team and is being worked on.

--Jason

LegacyUser

Paul said: Jason

So can errors like the one below be corrected? It shows a christening at Postwick, Norfolk whereas the event took place at Ranworth, Norfolk. Please see https://www.familysearch.org/search/c..., which shows both Postwick and Ranworth Archdeacon's Transcripts appear on microfilm 1526737.

There are many other examples like this that I and other users come across. Obviously, the error does not just apply to this one record - possibly hundreds of events that took place at Ranworth are shown in FamilySearch as having taken place at Postwick.

I understand how these errors can be corrected if being of the example originally posted here by Heidi, where the whole contents of a microfilm have been recorded as being for the wrong (single) location, but can the relevant team adjust records where multiple parishes are involved?

There is another example in England (well, many more, actually) where hundreds of records are indexed as relating to Corbridge, Northumberland parish instead of for Alnwick, Northumberland - again because records for both parishes appear on the same microfilm. Would we be wasting our time in reporting this type of error? I have certainly reported them in the past, without any corrective action being taken.

VitaliiSushchenko

Where can I report about incorrect city in the catalog name?

MaureenE123

My understanding is that currently you should post in the Question and Answers section (Q and A, also called Help Center Categories)) under Search

https://community.familysearch.org/en/categories/search