Difference between Displayed Place Name and "Standardized" Place Name Continues to Cause Confusion
Comments
-
Fascinating idea, to have an additional box besides the freeform and menu-derived boxes which would be a custom latitude and longitude to finetune where the map pin on the timeline map goes. You should probably post that as a separate ID. I suspect any one in charge around here quit following this topic a long time ago since we are just repeating ourselves and not really getting anywhere.
1 -
Went ahead and posted the Idea separately. Hmm, I thought I wasn't repeating ... repeating ...
Thanks
0 -
I suppose this means you're in favor of the map pin icon indicating a selected place matches a Standardized place?
I really don't care about the map. I care about locations being parsed correctly by the system for record hints, duplicate hints, searches, etc. I care that if the location the system is parsing is vastly different from what's written or intended, that fact is plainly obvious on the profile page. I care that this functionality isn't buried just because it a couple users blamed it for their data being overwritten by some other careless editors.
Personally I don't feel that identifying a location down to square-centimeter is a common or important enough that the UI needs to be designed primarily around it, especially at the expense of being able to easily identify inconsistencies between the user-visible and system-visible entries.
1 -
System-visible entries are easily seen just by clicking on the data or just at a glance by checking the time line map. And, of course, if all users understood how places are entered and took the time and care to proof read entries before saving them, other users would not need to come behind them and do that proof reading for them.
I think that if more users would realize that we are no longer limited by paper forms created and standards set nearly 100 years ago and made use of what Family Tree is capable of they would enjoy seeing the richness of information that can be recorded. When users get used to seeing right there under a residence not just that an ancestor lived in New York but that the ancestor lived at a specific address in New York, they will realize the value of adding that information to Family Tree.
0 -
System-visible entries are easily seen just by clicking on the data or just at a glance by checking the time line map.
I think it's far, far more important that those be immediately visible. I deal with way too many profiles to go manually checking multiple fields, and the map isn't a reliable way to check that.
if all users understood how places are entered and took the time and care to proof read entries before saving them, other users would not need to come behind them and do that proof reading for them.
Most of the time these fields are filled automatically as sources are attached. Proofreading has nothing to do with it. There's STILL a bug when adding sources where a location can be letter-perfect and indicate it's standardized in the source linker, then fail to be standardized when added. Users aren't the only problem. And if we could rely on them to be diligent about the info they enter, The number of users who will use a free-form field to enter pinpoint-accurate locations is utterly miniscule compared to the number who will use it to copy-and-paste whatever garbage they find on Ancestry or Find a Grave, or whatever malformed location is scraped from our continually-degrading databases here.
When users get used to seeing right there under a residence not just that an ancestor lived in New York but that the ancestor lived at a specific address in New York, they will realize the value of adding that information to Family Tree.
I've seen it, and with very few exceptions, I see no value to forcing that level of detail into a general purpose field. I definitely do not see any benefit that warrants crippling functionality like this, and I really don't see how doing this is going to improve location precision at all. Ensuring the system is seeing the same thing as users is vastly more important than playing games with UI in a fruitless attempt to dissuade people from overwriting addresses for places that don't exist or are nothing like how they used to be.
The only real upside to having that data would be if we could use to generate a list of neighbors or use proximity in searches, but we can't even search for a street address even when it's included in the location field.
0 -
@RTorchia would it be possible for you to give an example of this bug/defect that you reference is in FamilySearch Places authority? I'm having difficulty knowing whether you mean you would prefer an alternate place name to be visible rather than the display name - or whether you are wanting to Suggest a new Place if it isn't found or whether a specific jurisdiction/Place is not hierarchically correct for a certain timeframe? The Places database is editable to correct mistakes or omissions - but I don't know if that is your situation.
0 -
@RTorchia, which would you rather do: enter your grandfather's birthplace as being in a country that didn't exist until three decades after his death (as I am forced to do on other genealogy sites which solve the places database problem by using modern jurisdictions only), or enter your grandfather's birthplace correctly down to the name of the farm?
The places database is not complete, and it basically never will be complete, but FS's dual-entry setup means that this is not a problem. This is the polar opposite of "crippling functionality".
1 -
would it be possible for you to give an example of this bug/defect that you reference is in FamilySearch Places authority?
When I run across an example, I'll share it, but this isn't new. The bug is that a location added from a source might be identical and even display as standardized in the source linking window, then (with the exact same text) become non-standardized on the profile page. There's at least one thread about it already: https://community.familysearch.org/en/discussion/91438/standardized-places-dont-persist-from-source-linker
And it's not really the point. These changes assume and expect a consistently high level of quality and diligence from editors, and that point-blank is not going to happen. This change is focused on appeasing a relatively small number of editors who want to enter exceptionally precise information and worry that it might get overwritten. It's a valid concern, sort of, but honestly has a much simpler fix: See All Changes → Restore. Meanwhile the rest of the database has over a decade of varying-quality location data to deal with, and this bug with some collections that standardize to the wrong location: https://community.familysearch.org/en/discussion/64377/1840-census-locations-are-still-botched
which would you rather do: enter your grandfather's birthplace as being in a country that didn't exist until three decades after his death (as I am forced to do on other genealogy sites which solve the places database problem by using modern jurisdictions only), or enter your grandfather's birthplace correctly down to the name of the farm?
Well when that actually happened with my Armenian great-grandparents, I just added the place to the locations database. I'm not sure what your point is here? This isn't other sites, and the purpose of allowing the field to be freeform at all certainly isn't so that we don't have to improve the location database. And clearly my reference to "crippling functionality" wasn't about the ability to enter free-form data and standardize separately, but this update's removal of an icon that indicates the user-facing location text matches the standardized location. That's the functionality that's being crippled, just to try (probably unsuccessfully) to fix an edge-case scenario that doesn't affect most users.
0 -
These changes assume and expect a consistently high level of quality and diligence from editors, and that point-blank is not going to happen. This change is focused on appeasing a relatively small number of editors who want to enter exceptionally precise information and worry that it might get overwritten.
I guess I'm more optimistic that the average user can easily understand place names in Family Tree and see the value in a tool that may not always be needed but is great to have when they do need it.
A few months ago I was part of a webinar for a group of people in Norway who are rather lukewarm users of Family Tree. Most of them used Legacy or My Heritage and only went into Family Tree when they had to. One of their big complaints was place names. The Places database was missing far too many places where their relatives were from. What farm names were there, a part of the place name they all agreed must be included, were not listed properly under their municipality but were instead just under the counties.
They were thrilled to learn how to record full place names and link them properly to the municipality place name. I did also explain to them how to request that missing places be added to the database but there did not seem to be a great interest in that as long as the farm, municipality, county, county, could be linked to the municipality, county, country.
For another conversation here, I did a little analysis of one of the less populated counties in Norway. I'll just quote myself (apologies to anyone that has already read it) to point out the shortcoming in the Places database for Norway.
The county of Sogn og Fjordane, Norway, currently has 1859 children in the Places database. Of these, 1611 are direct children. That county has only 26 municipalities. These municipalities should be the only direct children of the county. This means that 1585 places in the county are incorrect in the database because they are direct children of the county instead of being under a municipality as they should be.
Glancing over a map, each municipality in Sogn og Fjordane probably averages about 75 place names that should be in the database. This means that there probably should be around 2000 places in the database. Also, all the places currently only have one time period. I haven't looked into the history of this county, but if it is similar to the neighboring county of Hordaland, each place should have 3 or 4 historical periods. That would bring it to a total of at least 6000 places.
This means there are 274 standard place names in the database than might be correct and over 5726 places that are either incorrect or missing from the database. If someone were to persist in the common misunderstanding that only "standards" can be used and went though Family Tree "correcting" every place in Sogn og Fjordane to get that map pin, the damage would be severe, particularly because place names are often used in more than one municipality.
For example, there is one entry for Berg, Sogn og Fjordane, Norway while there are twelve municipalities that each have a place named Berg in them. The Berg in the database is Berg, Leikanger, Sogn og Fjordane. The other 11 are missing. "Standardizing" everyone living in Berg and requiring use of the database entry means that 92% of the time the place would be completely wrong on the map.
Yes, I could request 6000 places be added or improved for this rather small and rather unimportant place in the world and hope that in ten to fifteen years they would all be there. In the meantime, this ability to enter the correct place name and link to the equivalent incorrectly named place with the right latitude and longitude or to its parent place is a really important feature of Family Tree that people need to understand properly.
The database is slowly improving, but it is going to take a very long time just to fix all the places in Norway. And this is not the only country that has the same problem missing place names. But with the design of Family Tree, we do have the ability to put place names in properly and people can learn why those place names are correct.
0 -
I guess I'm more optimistic that the average user can easily understand place names in Family Tree and see the value in a tool that may not always be needed but is great to have when they do need it.
None of which is affected by this change. Remember, we're only talking about the removal of an icon indicating whether the user-facing text and standardized location are the same. This change adds zero functionality, it only takes away the ability for editors to instantly compare the user-facing location text to the standardized location, a feature many clearly found essential.
And ironically the argument for the change was that average users won't ever easily understand the way place names and standardization work, and they'll kept overwriting more precise information for standardized information. Honestly I still see no evidence that this behavior is a major site-wide problem and not a niche complaint. People are upset because it really does adversely affect their ability to work quickly. I mean, all due respect to the Norwegians, but they've never represented more than 0.15% of the world population. Sorry, but if that level of precision is really that critical here, they might have to spend a few hours adding locations.
0 -
@RTorchia, the errors and omissions in the Places database affect a whole lot more than just Norway. That's just a handy example.
And the problem with the icon was very widespread. Many, many people spent a large chunk of their time on FS chasing it, leaving a trail of destruction behind. Well-intentioned destruction, but that just made it worse, and made the icon's retirement one of the best things the new layout did.
The reason so many people misunderstood the icon is that the logical fallacy of denying the antecedent (if A, then B; not A, therefore not B) is basically automatic in human thinking. There was an icon that appeared on some subset of standardized entries, so people concluded, correctly, that the icon indicated standardization, but also, incorrectly, that lack of the icon meant lack of standardization.
I suppose an icon for "text matches database label" may be less problematic if there were also an explicit icon (rather than the absence of an error message) for plain-old "standardized", but people would still misunderstand.
1 -
Then just give users the option of displaying both fields!
It's unbelievable how many times this was brought up here and in the New Person Page group and smugly dismissed, as if editors were wrong and dumb for saying that they value and want this feature. I can't recall a single time when somebody overwrote valid data just to standardize a location, but I've seen hundreds of cases where the location was standardized to someplace different from the user-facing text, and I've seen hints and duplicate suggestions start to appear once that mismatch was fixed.
We've got more than a decade records tainted by bad indexing or buggy source linking functionality or shoddy third-party apps that change the location field without changing an old standardization. There is damage and we need to see it to fix it. I don't care if anybody hates the standardization system or the location databases -- until it's replaced, it's what we have to work with. I don't care about the stupid icon. When editors say they need to know what the standardized value is without opening a dialog or hovering a cursor over a value for a few seconds, accept that and stop trivializing their concerns!
1 -
I posted about this a couple of days ago since they are moving in this direction. In the data view popup you can easily see both the free-form user entered text and is linked value.
Here is what I've suggested: https://community.familysearch.org/en/discussion/142771/a-plea-for-proper-place-presentation-and-procedures#latest
But they need to find some way to stress that the correct place name and the linked value do not need to be the same and that there is potentially great value in not having them the same.
1 -
"I've seen hundreds of cases where the location was standardized to someplace different from the user-facing text"
I think this is a really important point but it's being lost because people are just saying "I can't tell whether it's Standardised or not" or "We want the icon back".
People need to be explicit that the issue is now about knowing whether it's been standardised to the right value, and not about whether it's standardised. And no, I'm not being condescending - computers and software engineers deal in absolutes - if the absolute issue isn't documented, it'll never be fixed.
Just to indulge myself, there are 3 basic questions about standarisation...
- Is it Standardised? (i.e. is it linked to an entry in the database of standard places?)
- Is it Standardised to a place with the correct type, in the correct physical place on the globe? (i.e. has London been standardised to the one in Ontario or England? Or has a settlement been standardised to a settlement or a county of the same name?)
- Is it Standardised to a placename (rather than physical place on the globe) with a date appropriate name?
Those are in increasing order of accuracy. There may be other shades of meaning as well.
4 -
One of the common concerns in Family Tree are incorrect merges of people that superficially look the same by users who don't take the care they should in evaluating profiles by leaving detail view off, by not looking at all the sources, and ignoring notes. The best way to prevent wrong merges it to put as much information as possible in the most obvious places.
Of the following two groups of women, all of whom have their birth place correctly "standardized," which is most likely to be incorrectly merged?
This group:
Or this group?
@RTorchia In the old pages, the top three would all have had map pins and the bottom three would not have had map pins even though all six are correctly "standardized." In your efforts to use your method of standardization, would you remove the information from the lower three women that makes it obvious they are three different people? Would you be willing to post a few IDs of some of the corrections you have made on place names for other's to comment as to whether the correction was indicated or not?
@Adrian Bruce1, you stated "People need to be explicit that the issue is now about knowing whether it's been standardised to the right value, and not about whether it's standardised."
That was perfectly phrased. The roadblock in these discussions has always been getting people to understand that those map pins never had anything to do with answering that question except for the most basic, common, low level place names that are fully entered in the Places database and which are a minority of all the place names in the world.
1 -
@Gordon Collett Say "map pins" one more time...
The examples are nonsense. Let's start with the obvious problems: NYC wasn't consolidated in 1845. The first would have been in Kings county, the third in Queens county (thank you, Run-D.M.C.), and the middle one doesn't exist, and there's no sources or contextual information provided. Plus it looks like somebody may have entered a residence for birthplace. Or are you claiming these were all born at home? Or is one or more of those a hospital address? Do none of them have middle names, or... I don't know, parents?
But all that aside... A situation like that is only going to occur two ways:
A) The pages were created from redundant records for the same individual that had different locations indexed for whatever reason -- it happens a lot. What are the sources for these three separate addresses? If there are none, how do we know one or two of those just aren't wrong, either in the location, name or date? What other uniquely identifying information is there? What are the conflicts proving these are different people, and how strong is the evidence?
B) Somebody added that information specifically to distinguish three different people. If they put in that much effort into that, would they not also call it out in other ways? Add an alert? Set the inevitable duplicate suggestions that this would trigger as "Not a Match" with an explanation why? Add these to their Watch list since they're the one-in-a-million situation that's especially prone to confusion?
And do you honestly believe three different street addresses attached to the same person with the same name and no other sources or relationships is going to prevent anybody the fine unvetted public invited to make changes on this site from editing these "wrong" -- attaching the relationships, sources, death records for other Mary/Maria Smith/Smyth/Smythe/Schmidts from vaguely the same area and time, etc.? Merging them together along with a few other Mary Smiths born the same year?
And if you have enough faith in your fellow editors that just posting a street address in a residency field will prevent that kind of bad editing, why would you not have enough faith that they could handle being shown both the standardized location and user-facing location by default?
Would you be willing to post a few IDs of some of the corrections you have made on place names for other's to comment as to whether the correction was indicated or not?
I'd have to dig them up. The ones that come to mind are for English christening locations in major cities (mainly London, Liverpool, Birmingham and Manchester), where the standardization was for the post-1801 name of the city rather than for the actual church or parish, even though those exist in the database. Most of those came from people merging together a few dozen people named James Wright who were born somewhere in England in the 18th Century -- if only they had street addresses, that surely wouldn't have happened.
I could probably dig up examples. How about you also share a few of the examples you're talking about, so we can check the edit histories and see how often the problem you're describing actually happens, whether it warrants the kind of clearly unpopular site-wide changes that were made, and whether those changes have any impact whatsoever on that problem?
0 -
"The ones that come to mind are for English christening locations in major cities (mainly London, Liverpool, Birmingham and Manchester), where the standardization was for the post-1801 name of the city rather than for the actual church or parish, even though those exist in the database"
For info: I don't doubt your description is correct for the point at which you amended things, but adding churches to the standard place-names for England & Wales is a comparatively recent addition. Not only that but in a rare display of pragmatic sense, the word "Church" seems to appear in the examples that I've seen. Originally where the church was entered for some reason, it just had the dedication and you had to know that "St Mary Nantwich" was a church but "Chalfont St Giles" was a place, and not a church named St. Giles in a place named Chalfont.
Anyway, the point is that when those examples that you altered (sensibly) were entered, they were probably standardised as closely as possible at the time.
"Most of those came from people merging together a few dozen people named James Wright who were born somewhere in England in the 18th Century -- if only they had street addresses, that surely wouldn't have happened."
Street addresses simply didn't exist in the 18th century in England for the vast majority of the population - only those who lived in major towns. And the demerges that I've had to do show, that people won't even read the visible county, never mind the (probably non-existent) street address - e.g. Samuel Windsor of Devon merged with Samuel Windsor of Cheshire.
Anyway, I've long since lost the point of this thread, which appears to be in danger of confusing
(1) the laudable issue of seeing whether the place has been standardised correctly by physical place and date
and (2) the recent changes to map pins, that have proved unpopular because people imagine that they can no longer easily see whether a place has been standardised at all, when the reverse is true.
0 -
For info: I don't doubt your description is correct for the point at which you amended things, but adding churches to the standard place-names for England & Wales is a comparatively recent addition.
Not just churches, but also parishes. And in the case of either, it's often just the word order that needs to be finagled. For example, up until I added the alternate name, it wouldn't standardize Cathedral, Manchester to Manchester Cathedral. Similarly, standardization would get hung up on things like whether the city name was included before the church name (e.g. Liverpool St. Mary), whether or not the name had an apostrophe-s, whether "church" was included in the title, etc. Things that the standardization system should have been robust enough to handle but didn't, and now it's too late to retroactively fix -- (not really too late, they just won't do it). St. Giles without Cripplegate comes to mind (probably because the name sounds so awkward), but there were a few Westminster churches and parishes that didn't resolve correctly. Bury St Mary was another.
Another issue was the consolidation of some areas into larger cities, greater London for example. The old records that were indexed and auto-standardized at some point -- the ones that have a "location (original)" -- often standardized to the most modern name, but didn't sort the parish or church right, so just ended up standardized to the generic "London, England, United Kingdom" regardless of the original location field. At some point a ton of people pages were generated from these records, and IIRC, these are at least some of the ones that have a standardized location that doesn't match the user-facing location and isn't as specific as its source.
0
