Why does the christening location in FIND not match that in the Vitals section of the ID?
The screenshot below shows a location that: (1) would not have existed in 1773 and (2) cannot be found either in the Vitals section of the ID, or in the attached source.
How does this specific place name manage to get displayed in FIND when it cannot be found elsewhere?
Ah, here's a clue. When I attempt to edit the standardized place name (see 2nd screenshot) the name in FIND is found at the top of the drop-down list, but I still can't see how a name that has not be selected has been "moved across" to FIND.
Answers
-
For some ridiculous reason a few months back FS decided to not use the actual recorded value for a vital when using the source linker and other places like the list you've identified. Instead, they use the standard value that is standardizing the recorded vital's value. If a non-standard place name has no standard name assigned to it, they will use the standard name "at the top of the list" as you've pointed out.
However, in addition to the totally ridiculous practice of never using the actual vital value that was originally recorded, in this case, the software is also BROKEN in that it doesn't recognize the fact that a standard has actually been assigned to the vital!
Both issues were reported to FS a ways back but nothing ever came of it. They need to fix this.
0 -
Jeff is right - in so far as anyone can understand what's going on.
For various reasons that no doubt seemed a good idea at the time, the indexes used for searching are rebuilt from the data including an automatic, untouched by human hand, standardisation. Regardless, it seems, of whether the data was already standardised with a valid standard.
This fouled up my search for a relative because it found the wrong St. Mary's in Cheshire. Because the correct value can be seen on the Historical Record or whatever, the fact that the intermediate display value is garbage didn't seem to be thought to be a problem. My point was that most people would assume that the intermediate value was correct and (incorrectly) discard that answer.
The logic for this automatic, untouched by human hand, standardisation seemed to be that the indexes were created by a background job - true. But also there seemed some desire to reduce the volatility - which I didn't altogether understand. If a system can't cope with volatility, it's the wrong system.
I daren't think how many screens are infected by this algorithm.
0 -
Paul - I believe that the cure for this would be to replace the display (and standard) name of "St. Mary Whitechapel, Stepney, London, England" with "Saint Mary Matfelon, Stepney, Middlesex, England" which is the same geographic spot, an alias for your church, and whose display and standard name are the same.
It just doesn't work when display and standard don't match because the automatic restandardised name may be different.
0 -
Thanks for your responses, Jeff and Adrian. Just when you think the engineers are getting on top of things you come across issues that still need to be resolved!
0 -
I have also requested that the 2 place-names for the park be taken out from under St. Mary's place and given their own place, leaving the place for the church just to its St Mary place-names. Yes, church place and park place have the same coordinates but they do not serve the same purpose so should not be equated.
0 -
St Mary Matfelon and Altab Ali Park / St Mary Gardens have now been separated so that they are now 2 places, not different place names for the same place. Thanks to the Standard Places team for that.
I'm sure that because of the way that the automatic background standardisation algorithm works - or rather, how often - full separation will take some time to work through and remove the silly suggestions.
Incidentally, the notification that I got from the team for that, came out of the new Vanilla forums software....
0
