Standardizing of "Custom Event" Place Names

LegacyUser

Paul said: I wonder if other users ever bother to standardize place names carried across to the Custom Event section - e.g. when census sources are attached? The screenshots below illustrate the situation:

(Some of these place names are just nonsense, but a couple look perfectly okay)


Extract from a census source:


Does any "standardization" take place during the indexing process? Note the different fields for "Event Place (Original)" and "Event Place" - the latter having the appearance of a perfectly acceptable standard name. Surely the purpose of this must relate to some sort of intention for the latter to act as a standardized name?

I have far too many of these to deal with in relation to the time I set aside to work in Family Tree, so won't be addressing the "problem" any time soon. In any case, there being no data error warning flags at the top of the person page(s) must indicate NOT standardizing these place names would not affect any search algorithm results. Regardless, just a bit of an eyesore having all those red exclamation marks staring at me!

LegacyUser

Stewart Millar said: Having noticed the same effect - it would seem that somewhere in the creation of these types of records - the system seems to have missed trying to get a matching standard place name thereby leaving the entry with no matching standard place name - hence the red exclamation . . . if you merely alter the entry by deleting and re-entering the the last character - it invariably suddenly finds a matching standard.

LegacyUser

Jordi Kloosterboer said: or just enter a space if you want to match the standard and then add additional information if needed (like street address).

LegacyUser

Adrian Bruce said: I certainly standardise my non-Vital place names, but then that's me and my pedantry. So far as I understand, having both Event Place and Event Place (Original) indicates that the index record has had its place name standardized - the latter is the original input, the former the standard.

LegacyUser

Paul said: Yes, that's how I thought it would work, but as you can see from the 1871 census example, (the assumed standardized) "Norwich, Norfolk, England" has not been put to this use - as "St Paul, Norfolk, England", the "Event Place (Original)", has been brought over during the attachment process, instead! Why on earth program it that way, instead of allowing for the detail in the "Event Place" field to move across?

LegacyUser

Adrian Bruce said: Maybe, just maybe, Event Place Original was moved into the Display Place Name and Event Place (the Standardized version) was supposed to be moved into Standardized Place Name. Except, guess what. It didn't work.

LegacyUser

Juli said: Part of the problem, I think, is that a lot of these indexes are ten, twenty, even thirty years old. They tweak things here, adjust things there, and suddenly those extra commas or whatever are throwing the system for a loop when they didn't used to be a problem. FS is just too vast for them to keep up.

LegacyUser

Adrian Bruce said: Very possible...

LegacyUser

Gordon Collett said: I have notice that the few times I have tried out the "Improve Place Names" routine that the majority of the place names I am presented with to standardize are custom events such as the ones shown above. In fact, I just went through a set to confirm this and all ten were either custom events or residences.

So FamilySearch is encouraging people to help get rid of all those red marks.

LegacyUser

Paul said: One more recent problem is that (usually with census sources) there are now TWO Residence places that can be move across in the source attachment process. The second one is generally just a street name - e.g. "John Street". That might be helpful information in context, but showing just that (i.e. a lone "John Street") as a Custom Event is completely meaningless - not even a year to give a clue of when they lived at John Street.

I have requested in another post that this "secondary" residence data cannot be brought across. It being indexed (in the source) is great - tells me exactly where in the town / city my relative lived - but coming across to the Custom Event section serves no purpose and automatically means an extra place name has to be standardized!

LegacyUser

Paul said: Here is an example of the problem of an additional place name needing to be standardized due to the pointless exercise of carrying meaningless (except in context) Residence detail across:

Source ready to be reviewed and attached:


The option to carry across two pieces of residence data - including "Chapel Square":


The end result - "Chapel Square" is disconnected from the 1841 census source detail and needing to be standardized:


In this case, I will need to carry out research before I even get to be able to standardize "Chapel Square", as "Earsdon, Northumberland, England" is the registration district and not the town / village which is the actual location of Chapel Square.

In trying to be helpful, the developers have made things very difficult for me with this piece of programming - which I believe is relatively new.

UPDATE - A while after writing the above, I did get to view the original image - and have discovered Chapel Square is / was in the town of SEGHILL! (In the registration district of Earsdon, I believe, but the latter place is not mentioned on the census page at all.)

LegacyUser

Jordi Kloosterboer said: If they implement my idea of adding a place detail (https://getsatisfaction.com/familysea...), then they could simply add it as a place detail for the normal place residence.