Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.genealogy > #5587 > unrolled thread

FamilySearch introducing errors

Back to article view | Back to alt.genealogy

Contents

  FamilySearch introducing errors Steve Hayes <hayesstw@telkomsa.net> - 2021-10-29 10:07 +0200
    Re: FamilySearch introducing errors Ian Goddard <ianng@austonley.org.uk> - 2021-10-29 09:48 +0100
      Re: FamilySearch introducing errors Steve Hayes <hayesstw@telkomsa.net> - 2021-10-30 06:54 +0200
        Re: FamilySearch introducing errors Graeme Wall <rail@greywall.demon.co.uk> - 2021-10-30 08:38 +0100
          Re: FamilySearch introducing errors Steve Hayes <hayesstw@telkomsa.net> - 2021-10-31 20:32 +0200
        Re: FamilySearch introducing errors knuttle <keith_nuttle@sbcglobal.net> - 2021-10-30 08:51 -0400
          Locations (was: Re: FamilySearch introducing errors) "J. P. Gilliver (John)" <G6JPG@255soft.uk> - 2021-10-30 15:38 +0100
            Re: Locations (was: Re: FamilySearch introducing errors) knuttle <keith_nuttle@sbcglobal.net> - 2021-10-30 18:06 -0400
        Re: FamilySearch introducing errors Ian Goddard <ianng@austonley.org.uk> - 2021-10-30 16:02 +0100
          Re: FamilySearch introducing errors "J. P. Gilliver (John)" <G6JPG@255soft.uk> - 2021-10-30 16:23 +0100
            Re: FamilySearch introducing errors Steve Hayes <hayesstw@telkomsa.net> - 2021-10-31 20:34 +0200
          Re: FamilySearch introducing errors Steve Hayes <hayesstw@telkomsa.net> - 2021-10-31 20:26 +0200
        Re: FamilySearch introducing errors Ian Goddard <ianng@austonley.org.uk> - 2021-10-31 17:25 +0000
      Re: FamilySearch introducing errors Ian Goddard <ianng@austonley.org.uk> - 2022-02-14 23:23 +0000
        Re: FamilySearch introducing errors Daniel65 <daniel47@eternal-september.org> - 2022-02-15 22:42 +1100
        Re: FamilySearch introducing errors Steve Hayes <hayesstw@telkomsa.net> - 2022-02-16 07:45 +0200
        Re: FamilySearch introducing errors Nigel Reed <sysop@endofthelinebbs.com> - 2022-02-22 14:15 -0600
          Re: FamilySearch introducing errors Ian Goddard <ianng@austonley.org.uk> - 2022-02-23 15:45 +0000
            Re: FamilySearch introducing errors Nigel Reed <sysop@endofthelinebbs.com> - 2022-02-24 17:34 -0600

#5587 — FamilySearch introducing errors

FamilySearch has been plugging standardised place-names, which is not
a bad idea but has now gone too far -- their software triest to
automatically substitute "standard" place names for non-standard ones,
but in the process it often inserts a place name that is entirely
wrong and misleading, wand will ruin the usefulness of their
collaborative family tree. 

See 

<https://hayesgreene.blogspot.com/2021/10/familysearch-introducing-errors.html>

or

https://t.co/a8XuL86WsA



-- 
Steve Hayes
Web: http://hayesgreene.wordpress.com/
     http://hayesgreene.blogspot.com
     http://groups.yahoo.com/group/afgen/
     

[toc] | [next] | [standalone]

#5588

On 29/10/2021 09:07, Steve Hayes wrote:
> FamilySearch has been plugging standardised place-names, which is not
> a bad idea but has now gone too far -- their software triest to
> automatically substitute "standard" place names for non-standard ones,
> but in the process it often inserts a place name that is entirely
> wrong and misleading, wand will ruin the usefulness of their
> collaborative family tree.
>

FamilySearch have a long history of mangling places.  From the errors 
I've seen it appears that batches of records from multiple places must 
have been entered without changing the place name on the data entry 
screen and any QA procedure has failed to trap it.

This casual attitude seems to have affected search.  It's a while since 
I used FS until recently when I found that the 1st search page has been 
dumbed down.  I entered a name, place (Holmfirth) and year (1911), 
looking for the 1911 census date.  There would likely have been one 
record that fully matched.  The search returns pages of hits for the 
name and county.  None of the initial hits have either year or place. 
About 2/3 or the way down we finally get the subject: it's his death 
registration in 1911 but the place name in Huddersfield, the 
registration district.  The combination of name, year and place, the one 
and only fully matching hit, appears one up from the bottom of the first 
page.

I was using search engines that worked properly - including the ability 
to include NOT terms - in the mid '80s.  Nowadays any search engine I've 
used (including Google, Bing and Amazon) seems to be based on quantity 
of output, not specificity.  (FreeBMD and its relatives are an 
honourable exception.)  It might be reasonable to allow a margin of 
place and date but at least make the effort to order the results in 
closeness of match to the search terms.

[toc] | [prev] | [next] | [standalone]

#5589

On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
<ianng@austonley.org.uk> wrote:

>On 29/10/2021 09:07, Steve Hayes wrote:
>> FamilySearch has been plugging standardised place-names, which is not
>> a bad idea but has now gone too far -- their software triest to
>> automatically substitute "standard" place names for non-standard ones,
>> but in the process it often inserts a place name that is entirely
>> wrong and misleading, wand will ruin the usefulness of their
>> collaborative family tree.
>>
>
>FamilySearch have a long history of mangling places.  From the errors 
>I've seen it appears that batches of records from multiple places must 
>have been entered without changing the place name on the data entry 
>screen and any QA procedure has failed to trap it.

Yes, indeed. There have been transcrtiption errors, where someone has
transcribed a parish register and gone on to transcribing another
parish, without changing the name of the parish on the entry form. It
is the kind of error where it might be qute easy to do a batch
correction. 

But what I am talking about here is not a human error of a fallible
transcriber, but a deliberately introduced software error, which would
be much more difficult to trace and correct.

Here is an example:

Mount Fenning
England and Wales Census, 1841
Name: Mount Fenning
Event Type:	Census
Event Date:	1841
Event Place: Chichester St Martin, Chichester, Sussex, England, United
Kingdom
Event Place (Original):	St Martin, Essex, England
County:	Essex
Parish:	St Martin
Residence Note:	Copping'S Buildings
Sex:	Female
Age:	9
Age (Original):	9
Birth Year (Estimated):	1832
Birthplace:	Essex
Page Number:	12
Registration Number:	HO107
Piece/Folio:	344/24
Affiliate Record Type:	Institution
Affiliate Image Identifier:
GBC/1841/0344/0453&parentid=GBC/1841/0001424136
Household	Role	Sex	Age	Birthplace
Mount Fenning		Female	9	Essex
Mary Fenning		Female	45	Essex
Mary Fenning		Female	25	Essex
John Fenning		Male	20	Essex
Sarah Fenning		Female	16	Essex
Thomas Fenning		Male	13	Essex

When I copy this event to my own family tree, it does not copy the
original event place, but the spurious Chichester one. 

I hope the people at FamilySearch will soon correct this software bug,
but until they do, people who use FamiloySearch should be warned that
they need to treat every place name as suspect. 

Ancestry.com have long done this kind of thing, but it is new on
FamilySearch. 


-- 
Steve Hayes
Web: http://hayesgreene.wordpress.com/
     http://hayesgreene.blogspot.com
     http://groups.yahoo.com/group/afgen/
     

[toc] | [prev] | [next] | [standalone]

#5590

On 30/10/2021 05:54, Steve Hayes wrote:
> On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
> <ianng@austonley.org.uk> wrote:
> 
>> On 29/10/2021 09:07, Steve Hayes wrote:
>>> FamilySearch has been plugging standardised place-names, which is not
>>> a bad idea but has now gone too far -- their software triest to
>>> automatically substitute "standard" place names for non-standard ones,
>>> but in the process it often inserts a place name that is entirely
>>> wrong and misleading, wand will ruin the usefulness of their
>>> collaborative family tree.
>>>
>>
>> FamilySearch have a long history of mangling places.  From the errors
>> I've seen it appears that batches of records from multiple places must
>> have been entered without changing the place name on the data entry
>> screen and any QA procedure has failed to trap it.
> 
> Yes, indeed. There have been transcrtiption errors, where someone has
> transcribed a parish register and gone on to transcribing another
> parish, without changing the name of the parish on the entry form. It
> is the kind of error where it might be qute easy to do a batch
> correction.
> 
> But what I am talking about here is not a human error of a fallible
> transcriber, but a deliberately introduced software error, which would
> be much more difficult to trace and correct.
> 
> Here is an example:
> 
> Mount Fenning
> England and Wales Census, 1841
> Name: Mount Fenning
> Event Type:	Census
> Event Date:	1841
> Event Place: Chichester St Martin, Chichester, Sussex, England, United
> Kingdom
> Event Place (Original):	St Martin, Essex, England
> County:	Essex
> Parish:	St Martin
> Residence Note:	Copping'S Buildings
> Sex:	Female
> Age:	9
> Age (Original):	9
> Birth Year (Estimated):	1832
> Birthplace:	Essex
> Page Number:	12
> Registration Number:	HO107
> Piece/Folio:	344/24
> Affiliate Record Type:	Institution
> Affiliate Image Identifier:
> GBC/1841/0344/0453&parentid=GBC/1841/0001424136
> Household	Role	Sex	Age	Birthplace
> Mount Fenning		Female	9	Essex
> Mary Fenning		Female	45	Essex
> Mary Fenning		Female	25	Essex
> John Fenning		Male	20	Essex
> Sarah Fenning		Female	16	Essex
> Thomas Fenning		Male	13	Essex
> 
> When I copy this event to my own family tree, it does not copy the
> original event place, but the spurious Chichester one.
> 
> I hope the people at FamilySearch will soon correct this software bug,
> but until they do, people who use FamiloySearch should be warned that
> they need to treat every place name as suspect.
> 
> Ancestry.com have long done this kind of thing, but it is new on
> FamilySearch.
> 
> 

One I came across was my gg-grandfather's christening at St Thomas 
Charterhouse, Clerkenwell (now demolished). The Family Search index 
shows it as St Thomas, Virgin Isles!

-- 
Graeme Wall
This account not read.

[toc] | [prev] | [next] | [standalone]

#5599

On Sat, 30 Oct 2021 08:38:07 +0100, Graeme Wall
<rail@greywall.demon.co.uk> wrote:

>> When I copy this event to my own family tree, it does not copy the
>> original event place, but the spurious Chichester one.
>> 
>> I hope the people at FamilySearch will soon correct this software bug,
>> but until they do, people who use FamiloySearch should be warned that
>> they need to treat every place name as suspect.
>> 
>> Ancestry.com have long done this kind of thing, but it is new on
>> FamilySearch.
>> 
>> 
>
>One I came across was my gg-grandfather's christening at St Thomas 
>Charterhouse, Clerkenwell (now demolished). The Family Search index 
>shows it as St Thomas, Virgin Isles!

Another good example of the kind of thing I am talking about. 




-- 
Steve Hayes
Web: http://hayesgreene.wordpress.com/
     http://hayesgreene.blogspot.com
     http://groups.yahoo.com/group/afgen/
     

[toc] | [prev] | [next] | [standalone]

#5591

On 10/30/2021 12:54 AM, Steve Hayes wrote:
> On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
> <ianng@austonley.org.uk> wrote:
> 
>> On 29/10/2021 09:07, Steve Hayes wrote:
>>> FamilySearch has been plugging standardised place-names, which is not
>>> a bad idea but has now gone too far -- their software triest to
>>> automatically substitute "standard" place names for non-standard ones,
>>> but in the process it often inserts a place name that is entirely
>>> wrong and misleading, wand will ruin the usefulness of their
>>> collaborative family tree.
>>>
>>
>> FamilySearch have a long history of mangling places.  From the errors
>> I've seen it appears that batches of records from multiple places must
>> have been entered without changing the place name on the data entry
>> screen and any QA procedure has failed to trap it.
> 
> Yes, indeed. There have been transcrtiption errors, where someone has
> transcribed a parish register and gone on to transcribing another
> parish, without changing the name of the parish on the entry form. It
> is the kind of error where it might be qute easy to do a batch
> correction.
> 
> But what I am talking about here is not a human error of a fallible
> transcriber, but a deliberately introduced software error, which would
> be much more difficult to trace and correct.
> 
> Here is an example:
> 
> Mount Fenning
> England and Wales Census, 1841
> Name: Mount Fenning
> Event Type:	Census
> Event Date:	1841
> Event Place: Chichester St Martin, Chichester, Sussex, England, United
> Kingdom
> Event Place (Original):	St Martin, Essex, England
> County:	Essex
> Parish:	St Martin
> Residence Note:	Copping'S Buildings
> Sex:	Female
> Age:	9
> Age (Original):	9
> Birth Year (Estimated):	1832
> Birthplace:	Essex
> Page Number:	12
> Registration Number:	HO107
> Piece/Folio:	344/24
> Affiliate Record Type:	Institution
> Affiliate Image Identifier:
> GBC/1841/0344/0453&parentid=GBC/1841/0001424136
> Household	Role	Sex	Age	Birthplace
> Mount Fenning		Female	9	Essex
> Mary Fenning		Female	45	Essex
> Mary Fenning		Female	25	Essex
> John Fenning		Male	20	Essex
> Sarah Fenning		Female	16	Essex
> Thomas Fenning		Male	13	Essex
> 
> When I copy this event to my own family tree, it does not copy the
> original event place, but the spurious Chichester one.
> 
> I hope the people at FamilySearch will soon correct this software bug,
> but until they do, people who use FamiloySearch should be warned that
> they need to treat every place name as suspect.
> 
> Ancestry.com have long done this kind of thing, but it is new on
> FamilySearch.
> 
> 
This has been a problem for years, and is why I do not merge data into 
my database.  For several generation, my family come from one county in 
Indiana.  As the county changed from wild forest to a fairly large city 
things changed.  Many times a family is listed in one small community in 
one census and another in the next, but they are still on the farm they 
were on in the previous census.

Many years ago I standardized my location, to the smallest stable 
location.  In this county it is townships.  I  then note the community 
in the description part of the location fact.  An example:  the family 
lived in Milan township, and in the Chaberlain community. Since in the 
stable community is Milan township,  I put that in the location field. 
and in the description, Chamberlain.  (Today very few people know 
Chamberlain existed.)

In my opinion, the location is so that I can go to any current map and 
locate where the family lived. In this way when in the area I can easily 
travel to that location.   If I use the name of community that no longer 
exist, I may never find the family farm.  The historical location is put 
in the description, or a note if the information on the historical 
location is to large for the description.

[toc] | [prev] | [next] | [standalone]

#5592 — Locations (was: Re: FamilySearch introducing errors)

On Sat, 30 Oct 2021 at 08:51:32, knuttle <keith_nuttle@sbcglobal.net> 
wrote (my responses usually follow points raised):
>On 10/30/2021 12:54 AM, Steve Hayes wrote:
[]
>>  Ancestry.com have long done this kind of thing, but it is new on
>> FamilySearch.

I don't know if they've fixed it (I haven't renewed my Ancestry sub for 
a while, though will do eventually), but there was - maybe still is - a 
problem on Ancestry, such that the search result list shows a place 
different to that the individual record is. For example, Bedlington, 
Northumberland (England) - if you did a search (for a person's name, for 
example), you might find the resulting list showed some hits in a 
Bedlington somewhere in the US - but if you clicked on one of the 
entries in the list to see the individual record, you could see that 
they were in fact the England one. (But unless you _knew_ about this 
wrinkle, you'd not look at those list entries, if you were looking for 
England hits.)
>>
>This has been a problem for years, and is why I do not merge data into 
>my database.  For several generation, my family come from one county in 
>Indiana.  As the county changed from wild forest to a fairly large city 
>things changed.  Many times a family is listed in one small community 
>in one census and another in the next, but they are still on the farm 
>they were on in the previous census.
>
>Many years ago I standardized my location, to the smallest stable 
>location.  In this county it is townships.  I  then note the community

I standardised for place, county, country for UK, and place, 
state/province, country for north America. For anyone else near enough 
to starting your data that you can change it, don't do what I did: north 
America (at least US, not sure about Canada) really needs four levels - 
place, county, state, country. (Though the sizes are a LOT smaller [than 
_most_ states], UK counties are very roughly analogous to US states, and 
we don't really _have_ a level below county - not that anyone outside 
local government administration knows about, anyway.)

[I'd rather switch to top-down - country, state/province/county, place - 
because then location lists would come in a sensible order (all the 
England places together, ditto all the US ones) rather than listing New 
Jersey, New York, and New Zealand next to each other - but can't, 
because in the software I use (Brother's Keeper) the autocomplete 
function for locations (F8) currently is only starts-with rather than 
contains, so I'd have to scroll through all the England places.]
[]
>In my opinion, the location is so that I can go to any current map and 
>locate where the family lived. In this way when in the area I can 
>easily travel to that location.   If I use the name of community that 
>no longer exist, I may never find the family farm.  The historical 
>location is put in the description, or a note if the information on the 
>historical location is to large for the description.

Yours sounds like a very good reason to use modern names. (The only snag 
I can think of being you might not always know what it is, but some 
research can probably tell you.) I've not been consistent, but I've 
_tended_ to use the name current at the event in question (meaning a 
person might be born and die in the same place but it's shown as two). 
Your idea of putting that (original location name) in the comment is a 
good one: maybe I'll do a global change sometime. That tuit shortage is 
growing ..

In UK, it's not so much placenames disappearing - it does happen, but 
they usually remain [and Google Maps can find them], if only as a suburb 
of somewhere else - it's more county boundaries moving, and new counties 
appearing [1974 was the big change]. For example, a lot of my own 
ancestry was in either Northumberland or [County, not city] Durham, the 
border roughly following the river Tyne; but from 1974, places from 
somewhat west of Newcastle all the way to the sea, for a swath some way 
either side of the Tyne, are now in "Tyne & Wear".

Actually, that's one slight snag with your "use the modern name" policy 
- when there's a major border move, and/or completely new county, what 
was the modern name ceases to be so, so global changes are needed. 
Probably less of a problem in the US as I don't think state boundaries 
change much. (I don't know about US counties.)
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"I'm tired of all this nonsense about beauty being only skin-deep. That's deep
enough.  What do you want, an adorable pancreas?" - Jean Kerr

[toc] | [prev] | [next] | [standalone]

#5596 — Re: Locations (was: Re: FamilySearch introducing errors)

On 10/30/2021 10:38 AM, J. P. Gilliver (John) wrote:
> On Sat, 30 Oct 2021 at 08:51:32, knuttle <keith_nuttle@sbcglobal.net> 

> [I'd rather switch to top-down - country, state/province/county, place - 
> because then location lists would come in a sensible order (all the 
> England places together, ditto all the US ones) rather than listing New 
> Jersey, New York, and New Zealand next to each other - but can't, 
> because in the software I use (Brother's Keeper) the autocomplete 
> function for locations (F8) currently is only starts-with rather than 
> contains, so I'd have to scroll through all the England places.]

It would be nice to be able to search on each of the segments of the 
place name.   ie if the location is:Milan Twp. Allen Co, Indiana
It would be nice to be able to search on Milan or Allen or Indiana.


> Actually, that's one slight snag with your "use the modern name" policy 
> - when there's a major border move, and/or completely new county, what 
> was the modern name ceases to be so, so global changes are needed. 
> Probably less of a problem in the US as I don't think state boundaries 
> change much. (I don't know about US counties.)

There is one major situation like this in the US.  That is the state of 
West Virginia.   Prior to the 1860 this whole state was part of 
Virginia.  Because the citizens of that area prefered the Union they 
stayed with the north, and became a new state.

Again I handle this location like others,  If I have an ancestor whose 
home was in Virgina in 1850 and it became West Virginia after the 
1860's, I list the location as West Virginia. With a note.

I have family who originated in Germany, I can find their German home on 
the map, but have much difficulty during research indentifying the 
historical area, or more important find the historical area on a modern map.

[toc] | [prev] | [next] | [standalone]

#5593

On 30/10/2021 05:54, Steve Hayes wrote:
> On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
> <ianng@austonley.org.uk> wrote:
> 
>> On 29/10/2021 09:07, Steve Hayes wrote:
>>> FamilySearch has been plugging standardised place-names, which is not
>>> a bad idea but has now gone too far -- their software triest to
>>> automatically substitute "standard" place names for non-standard ones,
>>> but in the process it often inserts a place name that is entirely
>>> wrong and misleading, wand will ruin the usefulness of their
>>> collaborative family tree.
>>>
>>
>> FamilySearch have a long history of mangling places.  From the errors
>> I've seen it appears that batches of records from multiple places must
>> have been entered without changing the place name on the data entry
>> screen and any QA procedure has failed to trap it.
> 
> Yes, indeed. There have been transcrtiption errors, where someone has
> transcribed a parish register and gone on to transcribing another
> parish, without changing the name of the parish on the entry form. It
> is the kind of error where it might be qute easy to do a batch
> correction.
> 
> But what I am talking about here is not a human error of a fallible
> transcriber, but a deliberately introduced software error, which would
> be much more difficult to trace and correct.
> 
> Here is an example:
> 
> Mount Fenning
> England and Wales Census, 1841
> Name: Mount Fenning
> Event Type:	Census
> Event Date:	1841
> Event Place: Chichester St Martin, Chichester, Sussex, England, United
> Kingdom
> Event Place (Original):	St Martin, Essex, England
> County:	Essex
> Parish:	St Martin
> Residence Note:	Copping'S Buildings
> Sex:	Female
> Age:	9
> Age (Original):	9
> Birth Year (Estimated):	1832
> Birthplace:	Essex
> Page Number:	12
> Registration Number:	HO107
> Piece/Folio:	344/24
> Affiliate Record Type:	Institution
> Affiliate Image Identifier:
> GBC/1841/0344/0453&parentid=GBC/1841/0001424136
> Household	Role	Sex	Age	Birthplace
> Mount Fenning		Female	9	Essex
> Mary Fenning		Female	45	Essex
> Mary Fenning		Female	25	Essex
> John Fenning		Male	20	Essex
> Sarah Fenning		Female	16	Essex
> Thomas Fenning		Male	13	Essex
> 
> When I copy this event to my own family tree, it does not copy the
> original event place, but the spurious Chichester one.

Looking at the list there are two Event Places, the Chichester one and 
Event Place (Original) which is the correct one.  This suggests to me 
that it has been "corrected" by someone with a limited grasp of British 
geography.  It may have been a batch correction for the entire census. 
Alternatively it might have been yet another artefact of slipshod data 
entry and QA given that Chichester comes before Colchester alphabetically.

Unfortunately the Feedback tab does absolutely nothing useful in terms 
of being able to give feedback despite it's offering "specific" feedback 
to the page.  All it does is get in the way of the scroll bar.

Ian

[toc] | [prev] | [next] | [standalone]

#5594

On Sat, 30 Oct 2021 at 16:02:53, Ian Goddard <ianng@austonley.org.uk> 
wrote (my responses usually follow points raised):
[]
>Unfortunately the Feedback tab does absolutely nothing useful in terms 
>of being able to give feedback despite it's offering "specific" 
>feedback to the page.  All it does is get in the way of the scroll bar.
>
>Ian

Do tell them! I did (well, my point was more that, as it obscured the 
"thumb", I initially didn't realise the column _was_ scrollable); the 
more who tell them, the more chance they'll do something about it. (I 
suppose, use the feedback tab to tell them about the feedback tab! I 
can't remember how I got to the place where I could - I think it was 
that way.)
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

It is important to write so that you can be understood.  It is far more
important to write so that you cannot be misunderstood.

[toc] | [prev] | [next] | [standalone]

#5600

On Sat, 30 Oct 2021 16:23:15 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>Do tell them! I did (well, my point was more that, as it obscured the 
>"thumb", I initially didn't realise the column _was_ scrollable); the 
>more who tell them, the more chance they'll do something about it. (I 
>suppose, use the feedback tab to tell them about the feedback tab! I 
>can't remember how I got to the place where I could - I think it was 
>that way.)

I haven't seen the Feedback tab for a while. If I had I would
certainly have told them about that. 


-- 
Steve Hayes
Web: http://hayesgreene.wordpress.com/
     http://hayesgreene.blogspot.com
     http://groups.yahoo.com/group/afgen/
     

[toc] | [prev] | [next] | [standalone]

#5598

On Sat, 30 Oct 2021 16:02:53 +0100, Ian Goddard
<ianng@austonley.org.uk> wrote:

>On 30/10/2021 05:54, Steve Hayes wrote:

>> Event Type:	Census
>> Event Date:	1841
>> Event Place: Chichester St Martin, Chichester, Sussex, England, United
>> Kingdom
>> Event Place (Original):	St Martin, Essex, England
>> County:	Essex
>> Parish:	St Martin

>> When I copy this event to my own family tree, it does not copy the
>> original event place, but the spurious Chichester one.
>
>Looking at the list there are two Event Places, the Chichester one and 
>Event Place (Original) which is the correct one.  This suggests to me 
>that it has been "corrected" by someone with a limited grasp of British 
>geography.  It may have been a batch correction for the entire census. 
>Alternatively it might have been yet another artefact of slipshod data 
>entry and QA given that Chichester comes before Colchester alphabetically.

I very much doubt that it has been corrected by a "someone", but
rather a "something", shich is programming to substitute a
FamilySearch standardized place name for the original event name. 

In the event I changed the place name to "Colchester St Martin, Essex,
England" and copied it back to FamilySearch it has been "standardized"
to "St Martin's Church, Colchester, Essex, England, United Kingdom".

Now that would be fine if it were a baptism or marriage that had taken
i'place in the church, but I doubt that anyone was actually *residing*
in the church at the time of the census. 

I'm pretty sure it's a programming error by programmers who think they
are infallible, and think they now exactly what they are doing when
they don't. 

And the longer it persists, the more errors will creep in, and the
less useful the FamilySearch Family Tree and record indexes will
become. 


-- 
Steve Hayes
Web: http://hayesgreene.wordpress.com/
     http://hayesgreene.blogspot.com
     http://groups.yahoo.com/group/afgen/
     

[toc] | [prev] | [next] | [standalone]

#5597

On 30/10/2021 05:54, Steve Hayes wrote:
> On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
> <ianng@austonley.org.uk> wrote:
> 
>> On 29/10/2021 09:07, Steve Hayes wrote:
>>> FamilySearch has been plugging standardised place-names, which is not
>>> a bad idea but has now gone too far -- their software triest to
>>> automatically substitute "standard" place names for non-standard ones,
>>> but in the process it often inserts a place name that is entirely
>>> wrong and misleading, wand will ruin the usefulness of their
>>> collaborative family tree.
>>>
>>
>> FamilySearch have a long history of mangling places.  From the errors
>> I've seen it appears that batches of records from multiple places must
>> have been entered without changing the place name on the data entry
>> screen and any QA procedure has failed to trap it.
> 
> Yes, indeed. There have been transcrtiption errors, where someone has
> transcribed a parish register and gone on to transcribing another
> parish, without changing the name of the parish on the entry form. It
> is the kind of error where it might be qute easy to do a batch
> correction.
> 
> But what I am talking about here is not a human error of a fallible
> transcriber, but a deliberately introduced software error, which would
> be much more difficult to trace and correct.
> 
> Here is an example:
> 
> Mount Fenning
> England and Wales Census, 1841
> Name: Mount Fenning
> Event Type:	Census
> Event Date:	1841
> Event Place: Chichester St Martin, Chichester, Sussex, England, United
> Kingdom
> Event Place (Original):	St Martin, Essex, England
> County:	Essex
> Parish:	St Martin
> Residence Note:	Copping'S Buildings
> Sex:	Female
> Age:	9
> Age (Original):	9
> Birth Year (Estimated):	1832
> Birthplace:	Essex
> Page Number:	12
> Registration Number:	HO107
> Piece/Folio:	344/24
> Affiliate Record Type:	Institution
> Affiliate Image Identifier:
> GBC/1841/0344/0453&parentid=GBC/1841/0001424136
> Household	Role	Sex	Age	Birthplace
> Mount Fenning		Female	9	Essex
> Mary Fenning		Female	45	Essex
> Mary Fenning		Female	25	Essex
> John Fenning		Male	20	Essex
> Sarah Fenning		Female	16	Essex
> Thomas Fenning		Male	13	Essex
> 
> When I copy this event to my own family tree, it does not copy the
> original event place, but the spurious Chichester one.
> 
> I hope the people at FamilySearch will soon correct this software bug,
> but until they do, people who use FamiloySearch should be warned that
> they need to treat every place name as suspect.
> 
> Ancestry.com have long done this kind of thing, but it is new on
> FamilySearch.
> 
> 

You have two Event places shown with the correct one as "original".

My guess is that there were several batches of "St Martin" entries 
against the location of the first batch, Chichester, and nobody bothered 
to change the location at the start of the next batch.  The data itself 
would contain the actual location and that's been entered as "original". 
  It really needs a script to go through the database looking for "Event 
place (original)" fields, change these to the main event and change the 
label on the first "Event place" field to "Incorrect event place entered 
due to incompetence".

Really, if data contains an event place and it conflicts with what the 
operator has entered it should raise an alert and hold the data in 
suspense until it's been checked and a correction entered if necessary 
by someone has a grasp of where things are.  Not to do so is an obvious 
newbie error.

[toc] | [prev] | [next] | [standalone]

#5604

It seems to have gone from bad to worse.  Of the browsers I regularly 
use (I won't use Chrome or its derivatives) only Firefox now works.

This seems to be a recent trend in web-sites: using developers who are, 
presumably young, inexperienced and not aware that the web was designed 
to provide a universal platform so that users with a wide variety of 
platforms could access the same material.  Too clever by half so not 
clever enough.

A message to all web developers: if your site won't work on the user's 
chosen browser it's not the user's fault; it's yours.

[toc] | [prev] | [next] | [standalone]

#5605

Ian Goddard wrote on 15/2/22 10:23 am:
> It seems to have gone from bad to worse.  Of the browsers I regularly 
> use (I won't use Chrome or its derivatives) only Firefox now works.
> 
> This seems to be a recent trend in web-sites: using developers who are, 
> presumably young, inexperienced and not aware that the web was designed 
> to provide a universal platform so that users with a wide variety of 
> platforms could access the same material.  Too clever by half so not 
> clever enough.
> 
> A message to all web developers: if your site won't work on the user's 
> chosen browser it's not the user's fault; it's yours.

YEAP!! Yeap! Yeap.
-- 
Daniel

[toc] | [prev] | [next] | [standalone]

#5607

On Mon, 14 Feb 2022 23:23:54 +0000, Ian Goddard
<ianng@austonley.org.uk> wrote:

>It seems to have gone from bad to worse.  Of the browsers I regularly 
>use (I won't use Chrome or its derivatives) only Firefox now works.
>
>This seems to be a recent trend in web-sites: using developers who are, 
>presumably young, inexperienced and not aware that the web was designed 
>to provide a universal platform so that users with a wide variety of 
>platforms could access the same material.  Too clever by half so not 
>clever enough.
>
>A message to all web developers: if your site won't work on the user's 
>chosen browser it's not the user's fault; it's yours.

Hear! Hear!


-- 
Steve Hayes
Web: http://hayesgreene.wordpress.com/
     http://hayesgreene.blogspot.com
     http://groups.yahoo.com/group/afgen/
     

[toc] | [prev] | [next] | [standalone]

#5608

On Mon, 14 Feb 2022 23:23:54 +0000
Ian Goddard <ianng@austonley.org.uk> wrote:

> It seems to have gone from bad to worse.  Of the browsers I regularly 
> use (I won't use Chrome or its derivatives) only Firefox now works.
> 
> This seems to be a recent trend in web-sites: using developers who
> are, presumably young, inexperienced and not aware that the web was
> designed to provide a universal platform so that users with a wide
> variety of platforms could access the same material.  Too clever by
> half so not clever enough.
> 
> A message to all web developers: if your site won't work on the
> user's chosen browser it's not the user's fault; it's yours.


I use Opera and it works fine.


-- 
End Of The Line BBS - Plano, TX
telnet endofthelinebbs.com 23

[toc] | [prev] | [next] | [standalone]

#5609

On 22/02/2022 20:15, Nigel Reed wrote:
> On Mon, 14 Feb 2022 23:23:54 +0000
> Ian Goddard <ianng@austonley.org.uk> wrote:
> 
>> It seems to have gone from bad to worse.  Of the browsers I regularly
>> use (I won't use Chrome or its derivatives) only Firefox now works.
>>
>> This seems to be a recent trend in web-sites: using developers who
>> are, presumably young, inexperienced and not aware that the web was
>> designed to provide a universal platform so that users with a wide
>> variety of platforms could access the same material.  Too clever by
>> half so not clever enough.
>>
>> A message to all web developers: if your site won't work on the
>> user's chosen browser it's not the user's fault; it's yours.
> 
> 
> I use Opera and it works fine.
> 
> 

That was my point.  Opera is one of those Chrome derivatives.

[toc] | [prev] | [next] | [standalone]

#5610

On Wed, 23 Feb 2022 15:45:13 +0000
Ian Goddard <ianng@austonley.org.uk> wrote:

> > I use Opera and it works fine.
> > 
> >   
> 
> That was my point.  Opera is one of those Chrome derivatives.

I just tried Firefox and it works fine. I could navigate trees and
enter information, do indexing and a few other things. What doesn't
work exactly?

-- 
End Of The Line BBS - Plano, TX
telnet endofthelinebbs.com 23

[toc] | [prev] | [standalone]

Back to top | Article view | alt.genealogy

csiph-web