Pins indicating standardized place
I must respectfully disagree with Adrian Bruce concerning the "pins" which indicate a standardized place name. I find it is much easier to standardize a place name whin I can see at a glance that one is not standardized.
Comments
-
Pins do not signify if a place is standardized or not. Only the red exclamation point on the old pages or the red text notification on the new pages indicate if a place is standardized or not.
This complete misunderstanding of the map pins is why it is best they are gone.
2 -
Or don't forget this good Idea:
Such would allow you to place a pin on a non-Standardized location - thus allowing a pin to appear for such easy glance... (which means it would be standardized - at least Provisionally?!)
On a related note - where I resided growing up - the address changed three/four times over 25 years - while the parent place/municipality did not (probably quite common here in the USA - though I wouldn't necessarily be informed as to municipality boundary changes). The point is you could fine tune placenames to be very fine-grained timespans or just include the current address/location ... which is probably more likely to be understood/accepted. Either way - there should be such capability and final display placenames - such that people can know/understand the place on the map.
0 -
Which is still a good idea, but in the meantime we need to keep educating people on the difference between non-standardized place names (will have data error flag), correctly standardized place names with or without additional information and/or language changes (may or may not have a map pin), and incorrectly standardized places (may or may not have a map pin) and continually repeating: Map pins have never had anything to do with standardization!
1 -
Map pins have never had anything to do with standardization!
@Gordon Collett Excepting where such map pins do exist for standardized places? Obviously a standardized place (area or map pin) does exist somewhere on the map and for a particular timespan.
0 -
He is not referring to map pins on the map. He is referring to map pins on the Detail page.
All standardized places will have a map pin on the map that will indicate the location of the standard linked to the place name. This may be the place itself or the parent or grandparent of the place. That has not changed.
Some standardized places had a map pin on the Detail page that indicated that the displayed place name text coincidentally was identical to the standard linked to it. The lack of a map pin on the detail page has never meant the place name was incorrectly entered or that it was not standardized. The pervasive misunderstanding that no map pin meant the place was entered incorrectly is why it is very good that the map pins on the Detail page have been discontinued.
2 -
(I don't recall seeing Adrian Bruce around since the GetSat days; what ancient post have you revived to see his name?)
Quoth @ecrasband:
"I find it is much easier to standardize a place name when I can see at a glance that one is not standardized."
You can still see this, exactly the same as before: if it is not standardized, it is marked with a red error message. You can't get any more at-a-glance than that, I think.
0 -
I did't have time before to get to the educational phase of this discussion so here it is. Here are three examples of place names that would never have had a map pin on the Detail page but will have a correctly placed map pin on the timeline map.
All three of these are correctly entered. All three are correctly standardized. All three will never have a map pin on the Detail page and the only way to force a map pin is to degrade the data by doing away with correct data. All three of these function just the way they should in all Family Tree routines including Possible Duplicates, Hints, and Find. None of these need to be changed and should not be changed.
The first has additional information correctly added to the place name. The second uses the correct historical spelling for English version of the place at the time of the event (English uses the Norwegian form when there is no English equivalent). The third uses the correct place name in the language of the place where the event occurred as viewed when the site is set to use English.
The second biggest problem with the map pins, the first being the degradation of data in pursuit of them, is reinforcing the totally obsolete notion that we are limited to only using a fixed "standard" because we are on a paper form that only has a three inch line for the place name and are using a typewriter that does not have a single non-English character or because the information has to be stored on a computer with a fraction of the memory of the cheapest cellphone currently on the market. We are instead completely free to enter complete, comprehensive, accurate and precise place information that we can then link to a specific latitude and longitude to show where on the map that place is. Don't limit yourself to the tiny limits of a very incomplete and very rigid database of standards which are just text representations of geographic co-ordinates.
1 -
I agree with @ecrasband; for me the pins in the event date and place fields are meaningful information.
For the record, I make a lot of use of the Family Tree mobile app, which works a little differently than the web interface. On the mobile app it is much easier to select standards in the date and place fields rather than in the separate "shadow" menus. Also, as I have discussed before on this topic, selecting a standard in a field has significant positive impacts on the quality of Research Hints and Find results.
0 -
Yes, selecting the proper standard does have "significant positive impacts on the quality of Research Hints and Find results" and all three of my examples have proper standards selected and all of them will have the same positive impact on Research Hints and Finds. Whether the map pin is on the detail page or not has absolutely no influence on Hints or Find as long as the proper standard is linked to the displayed place name.
2 -
@dontiknowyou, you think the pin is meaningful information, but it does not mean what you think it means.
Really.
Whether the label's chosen sequence of characters happens to occur verbatim in the current subset of the database or not has absolutely no bearing on the correctness of the label.
If a record says an event occurred in "Washington, Amerika", and the user entering the conclusion accepts the offered standard of "Washington, United States" instead of keeping his typing, then you and other people using FS's English interface will see a map pin on the old person page. It will very likely be wrong, because that "Washington, Amerika" is 99% certain to actually mean Washington, D.C., but the pin will be there.
If the user keeps "Washington, Amerika" as the display value, there will not be a map pin in any language, but if said user then clicks the down arrow and changes the associated standard to "Washington, District of Columbia, United States", then that guaranteed-pinless display value will very likely be correctly standardized.
In other words, the pin tells you exactly nothing of use.
0 -
it does not mean what you think it means.
Perhaps, perhaps not. When intelligent, articulate, experienced, and very proficient users of a tool disagree significantly about how it works, that worries me. I hope it also worries the engineering team.
I make a point of checking the events to compare what is in the text field and what is in the standard field to what is in the attached sources. If I found "Washington, Amerika" in the text field alone or text field and sources, then I would explicitly select the standard "None of the above" and set a red flag, or I would explicitly select "United States" and leave in the Reason statement "Washington, United States, but which one?"
0
