Standardized date or place icon missing

This is actually a nice improvement. See a full discussion about this topic here: https://community.familysearch.org/en/discussion/133396/map-dots-and-calendar-markings

The lack of a map pin never was suppose to mean the place name needed to be corrected. The presence of a map pin never was suppose to mean the place name was accurate, complete, or the best possible place name.

If you are interested in knowing the actual meaning of those map pins and why so often the best place name did not have a map pin, please see: https://youtu.be/veP6UcEkHaA

Oh, I forgot to mention the third never:

The map pin never was supposed to indicate whether a place name was standardized or not. That was the job of the red exclamation point. If one was present, the data was not standardized. If there was no red exclamation point, then the place name was standardized whether there was a map pin there or not.

No, this is a mistake. It's a shortsighted and excessive response to a minor problem.

The pin notified editors that the location they saw was definitely the same as what the system saw. It was the only thing that conveys any sense of what the system understands as location on the main profile page. This is important functionality. Without it, all you know is that the system has something standardized, but you have no idea what. It could be the wrong location with a similar name or just a generic high-level region.

The examples given on the other thread are cherry-picked, and overlook many common cases where this is useful and needed. My hometown is one of three with the same name in the state. If you enter it and "California", rather than the 225k person suburb, it standardizes to an unincorporated community in the central value whose population is fish. It's hardly the location name like it. There are a ton of cities, towns and villages with the same names in counties in the same states, as well as cities and counties with the same names in the same states. The pin being in the wrong location in these cases won't be as obvious as the ridiculous example of a German place name resolving to China.

If the town is misspelled or placed in the wrong county, the system may only standardize to a vague high-level region. This happens a lot with churches in England, simply because the words are out of order on the record. And it won't be apparent because the pin telling them that the entered location and standardized location aren't synced isn't there, so these situations looks no different than locations that have been properly placed. People thinking that a location not being standardized "isn't right" isn't as big a problem as them not knowing the system parsed the location incorrectly or incompletely -- thinking that the system is telling them it is right.

Yes, the location database will never cover absolutely every place name ever, but it covers millions, and is completely sufficient for most cases. In the same vein, lack of this notification means people may not notice when a location should be added.

If people didn't understand it, that's a documentation issue, not a functionality issue. This killed useful, arguably necessary functionality over concerns some users didn't understand it or wouldn't use it correctly. If that's the bar, very little on this site clears it. Possible duplicates? The Life Sketch? The suffix field? I've seen "Sr." entered in Titles of Nobility more than I've actually seen titles of nobility entered there, so when are we burying that?

It's sad such a hasty decision was made, because there are plenty of other solutions for the concern that more specific data would be erased to standardize the field. 1) We could add an option to dismiss the warning on the field, so that after ensuring standardization was correct, other editors wouldn't be tempted to overwrite more specific non-standardized information. 2) We could make whether or not to display this warning a user-configurable setting, defaulted to off so that most new users won't encounter it, but experienced users who want it can enable it. 3) We could have an option to have the profile display both the location and its standardized form when it mismatches, similar to what appears in the Edit dialog when they're not matched -- this could also be an opt-in setting. Or 3a) Allow editors to change the main profile page to just show the standardized locations.

Otherwise I'm hard-pressed to understand, if standardized locations are so unimportant that we can just bury them like this, why do we have them at all?

@RTorchia, Thank you for your eloquent and comprehensive counter argument on the matter of map pins and standards. Your first sentence nicely gets to the heart of the disagreement. “The pin notified editors that the location they saw was definitely the same as what the system saw.” This is completely true. However, the problem is that the place that we see does not need to be what the system sees but some users have concluded that they must be the same based on the unfounded assumption that a map pin marks a place name as correct and the absence of a map pin marks it as incorrect. This false notion leads them to make sure every place name shows a map pin even if this means removing correct information. 

Yes, there have been documentation issues. Correct documentation would have made sure that people understood that many full place names would never have a map pin. It would have stressed the proper use of the dropdown “quick entry” place name menu and the need for careful proof-reading when entering a place name. You stated, that your “hometown is one of three with the same name in the state. If you enter it and "California", rather than the 225k person suburb, it standardizes to an unincorporated community.…” Correct documentation would have made it clear that you should have written: “My hometown is one of three with the same name in the state. If I enter it and "California", rather than the 225k person suburb and I standardize it to an unincorporated community….” Because we pick the “standard,” have full control over it, and have just as much responsibility for proof-reading it as we do the actual place name.

You ask “why do we have [standards] at all?” Actually, we don’t. Family Tree is designed to let us enter data in the best possible way without limiting us to artificial forms. Unfortunately, in my view, a tremendous error was made at the very start of Family Tree when someone decided to use the word “standardize” in reference to Family Tree’s process of entering place names in which we enter a place name however it needs to be entered for accuracy and precision and then link our entered place name to a search parameter which is basically the geocode for the center of the geographic circle the program should use for comparing two people or finding more information about a person. 

For example, a page in the 1950 census I have in front of me has twelve different households in it. As the residence for each household, I can enter the full street address as well as the city, state, and country. Linking those to just the city name is sufficient for searching and matching. However, displaying the full address more uniquely identifies the person than just the city does. Replying, “but we are not suppose to enter the address” would again just point out the confusion the map pins have caused. The program is designed for the inclusion of such an address and there are no instructions anywhere stating we should not. The entire point of there being two place name data fields for every place name we enter and the standardization process is to allow entering those addresses that will never be in the Places database of “standards.” 

I completely agree that there are solutions which are much better solutions than having the map pin. I have, in fact, suggested various styles of potential methods of displaying place names various times through the years, one of which is basically your suggestion number 3. A further modification of what I have previously suggested would incorporate a little of bit of documentation to help people understand how the program works:

Multiple people are saying what the purpose of the pin was, but was anybody here actually on the design team that defined their purpose? Because the available documentation sure seems to contradict these opinions about the intentions of these features. The documentation makes it clear that a standardized location is preferred, here and here, and in this training video (from about the 50m mark). Data consistency is cited as a goal. The idea that the location field was always intended to be completely freeform seems more like an opinion rather than an intentional design goal, otherwise the standardization system would have been designed differently. And a handful of exceptions doesn't overrule the fact that standardized locations are generally preferred, that this functionality helped editors ensure that locations were parsed into their standardized forms correctly, and that the problems cited here only affected a few cases where there is detail beyond what the fields typically contain.

Deleted info can be restored if somebody overwrites it, but you can't correct something you don't know is wrong. I just can't see a genealogically advantageous reason for kneecapping the ability to ensure data is correct at a city or neighborhood level, just because a few people are worried about whether the front page displays one specific superfluous detail. I mean, in another thread the suggestion of allowing an exact time in the date field was scoffed at, yet here we're removing useful functionality because we're worried about street addresses?

@Julia Szent-Györgyi

• "The reason the pin was so bad is that, unlike misuses of title fields and other such errors, it caused actively destructive behavior,"

Possible Duplicates falls into the exact same category, and its effects are worse and takes much longer to repair, but there's absolutely no reason we should get rid of it either.

• "As for the examples being cherry-picked: are you aware that you can make all of a profile's pins go away by simply changing the interface language?"

That's just a bug (and how many users are routinely changing the site interface language?). The system should check the field against all languages and not indicate the mismatch if it fits any of them. Or even better: changing the language should automatically display the locations in that language, something that won't ever happen if the fields aren't standardized.

@Gordon Collett

• "This is completely true. However, the problem is that the place that we see does not need to be what the system sees"

There are exceptions, but usually it's better if it does. Only in the relatively unusual cases where there's more detailed information than what's in the standardized place database is it advantageous for it not to, but for locations that are only neighborhood or city level, which we want to ensure is being parsed correctly, it does. Even if we just want to make sure the location is just cosmetically correct and complete, it does.

• "Replying, “but we are not suppose to enter the address” would again just point out the confusion the map pins have caused. The program is designed for the inclusion of such an address and there are no instructions anywhere stating we should not."

I've cited two official documents and a training video that emphasize standardization. Can you show me one that shows the intent of these fields was to include a full street address? Shrugging off an obvious counterargument before it's made doesn't negate it, and the facts that it can't be used in searches and that it defeats standardization aren't trivial.

Instead, I'd suggest finding a better place for that information, such as the Description field in the Residence tag, which might be something that should be added to the vital info location fields. Or include it in the description for whatever source proves it's correct (which I assume is included wherever it's added, right?)

We should also be pushing for a faster and more painless way to add locations to the standardized DB. Besides here, I do a lot of work on MusicBrainz. When adding a release, if a label isn't in the database, you can add it through a pop-up window in a few minutes. There's no reason it shouldn't be that easy here: if you're adding a location to a record that should be in the standardized location DB, you should be able to trigger the addition from there.

• "These are all too close together to warrant a separate geocode, but it can be very helpful in differentiating the three different Anders all born the same year at the same farm to record which sub-farm they were born at."

Do you really believe that making such a distinction in the location field is going to be sufficient, especially when somebody searching for a person by name, year and location is only going to be shown the standardized location in the search result? And that Possible Duplicate suggestions are going to be based in part on that standardized location? What you're describing is something that would need to be called out in an alert.

I have no complaint with official documentation and training videos talking about the importance of standardization, other than the fact that often standardization is not clearly defined or explained.

I would state it stronger than that. I would agree with any documentation that states that standardization is critical and is, in fact, required. That is why we get an error message when dates and places are not standardized.

However, I will continue to protest that the best place for place name information is in the place name field, especially when the place name field is designed to contain it and when that additional information adds to the richness and completeness of a person's information and does not defeat standardization in the least.

The design of the date and place fields and their intended use are clear from examining it how it functions.

The root cause of the confusion about standardization is the poor choice of uniquely defined technological jargon to explain it rather than clear English. Instead of using the term "standardized" in a non-standard way, they should have stuck to the longer phrase "link to a reference" or something similar. All these debates could have been avoided.

Please study closely the following two sets of examples:

These places are not correctly standardized and there will be a data warning about them even though they look just like the equivalent standardized value. This clearly shows that as far as the programming is concerned, standardization is not about how a place name is typed, but whether or not it is properly linked to the desired reference value.

I realized that for completeness I should include the type of language changes that @Julia Szent-Györgyi refers to. Here is a third set of correctly entered and correctly standardized place names. In the first, because the entered place name matches its standardized version, only one data field is shown. However, when the website language is changed, the original user-entered place name is preserved unchanged while the standardized version is changed. This again shows that these are designed as two separate but linked, independent data fields that are designed to contain different information.

The intent and design of the program is clearly to preserve whatever the user enters for the place name, whether containing more, less, or the same information as the linked standard, and to use that linked reference value to show where on the globe the user declares that place to be, displaying that reference in the language of user who is viewing it.

When you order something from Amazon and it asks you where you want to ship it to and you type in an invalid location does it let you type in anything you feel like and then link that to a real location?

Listing nothing more detailed than a municipality as the prominent displayed location data field makes perfect sense. When someone asks you where you are from do most people just say the street address like 10 South Jefferson Street? ...or simply I am from Chicago.

I have already suggested adding a secondary location data line for Street Addresses that could be displayed in a smaller font directly under the main location. You can already do this with the Description of Residence field and I actually use this all the time.

@CESchultz, there are people who have to get packages shipped to a neighbor or a mailbox service because Amazon's database is incomplete or incorrect, and even in less-extreme situations, the need to choose what Amazon thinks is correct results in loss of information that then needs to be tacked on somewhere else, where chances are, the delivery person will not notice. (Such as "the front door is the other apartment, please come around the side to the door that actually says '123B'.")

In contrast, FamilySearch's system works regardless of the current state of the database, and you never need to lose any information to get your entry associated with a database entry.

By the way, you still have not provided any actual examples from Family Tree of people arguing over "gibberish."

I have run across various place names with problems. One type are the result of past standards that have come forward through various older versions of Family Tree. I think it was in the 1950s that one was required in submissions to FamilySearch to follow the genealogical standard of dropping as many vowels as possible in place names, such as spelling Salt Lake County as S-Lk. The other type are place names that users have entered via the Source Linker in which the place name in the index was horribly corrupted by the crowd-source indexer who could not read the handwriting in the record and had no idea what the place name really was and the user did not take the time to figure out what the place name should be and fix the Family Tree entry. I've never had anyone complain about me improving these.

Again, this has nothing to do with what I am talking about. You keep using the existence of a software bug as justification for not having standards and instead just having a free for all. The places database already has a method for adding and correcting locations.

There should be no "associating" anything, there should only be entries in the places database and entries that need to be added to or corrected in the places database.

@CESchultz ? I am still not sure I am getting your fine point. The Standardized locations are menu driven. The free-form entry line accommodates street + Standardized location (there could be several valid standardized locations - i.e. ecclesiastical vs. municipal). What is the problem? Yes a free-form entry can be submitted for standardization through the places app - but no, that is not initiated when free-form entering. Requiring a separate street entry could be done - but since the current free-form field accepts it - why another entry line?

You seem to be insisting that any place entered be an entry to the Standardized database. (fine) If this is going to be the case - then it will slow down data entry. It could be sped up if the workflow simply guided the user through the process. I don't think it would take too much to link that into the workflow - but users seem to be confused enough about entry of standardized places . The resulting benefit however, would be no need for a standardized place icon (they would all be standardized - at least provisionally - yes that means a submission for inclusion into the Places database NOT that it has/will achieve accepted status).

One point that is obvious but I am not sure has been mentioned: places mentioned in the record - or attaching tag/source to place - should be of priority over 'standardization' - or at least of equal value? The record gives (if any place is mentioned) the place as it was known at the time of the record (at least to the recorder). Research needs to locate that place, enter it on the map, and then standardize it (I think that would be the correct order?).

Check out my alternative Idea which would allow the user to specify Lat., Long. for free-form entry - this might be a quicker way to at least get a user-specified location on the Standardized map without going through the entire submission process (but yes would require the user to do that research). Attaching that location on the map should allow for easier Standardization.