Why are there wildly different places on this document?

@HeidiSchreiner - I don't have the complete explanation for what you (and lots of us) are seeing when you click the arrow to reveal the multiple placenames, but it's clearly something to do with the need to go from the placename on the original source (a cemetery here, namely Riverside Cemetery) to the finalised Event Place - which needs to be a placename from the list of Standardised Placenames.

So, you're not far off when you said it was a list of all Riverside Cemeteries.

So far as anyone knows, the only one of that list that means anything for search purposes is the top one. You personally can ignore the rest - we think that the rest of the list is there for debugging purposes to help FS tune the algorithm to go from the abbreviated placename to the full Standardised Placename.

The appearance of a list behind an arrowhead (the icon reveals or conceals the list) can mean that the value has been edited and this is the list of previous values. However, that is clearly not the case here for places (or for date standardisation lists either).

Basically, you can click the arrowhead, make the list go away and forget about the list. Unless you're like me.

Note that I am not an engineer for FS, though I was an IT professional. I'm just trying to explain and reduce puzzlement. I'm not 100% certain of all the details but, despite appearances, computers do behave logically so one can try to reverse engineer potential explanations.

If anyone thinks that this reply is speculation that we shouldn't indulge in, then I invite you to permanently document this feature so that no explanation would be needed.

I've had a look at the relevant data via my analysis database.

The example above has the following place-related metadata:

The _ORIG ones, as usual, will be the information provided by Find a Grave. The EVENT_PLACE ones will be FS' interpretation of the place.

The FS-interpreted ones split into 2: the (correct) non-cemetery place, which has not been modified since initial take-on, and the Riverside Cemetery entries, none of which are in anything resembling the right area.

I suspect that FS has simply looked up the cemetery like this: q=name:"Riverside Cemetery" and taken the 1st 5 entries as they then were (the Stamford location now seems to be absent from the Places database).

If you put the Find a Grave supplied cemetery, city, county, state, and country together and look that up, you get a single entry representing what is clearly the correct cemetery in the correct location:

q=name:"Riverside Cemetery, Moorhead, Clay, Minnesota, United States of America" gives just

Riverside Cemetery, Moorhead, Clay, Minnesota, United States.

I looked into this further using 20705 US Find a Grave entries in my analysis database.

Of these, 269 have FS-interpreted places with 'Cemetery' in the placename; these 269 appear to demonstrate the above behaviour of having a non-cemetery FS place added at take-on time, with additional interpreted cemetery place(s) added later.

As far as I can see, all but 67 of these 269 have at least one FS-interpreted cemetery place present that is in the wrong state; it looks to me as if everything except the cemetery name has been ignored in doing the placename lookup. Several entries have more than 60 FS-interpreted placenames, and one (https://www.familysearch.org/ark:/61903/1:1:QVLR-SSHF?lang=en) has 100.

I have done my own placename lookups, using the Find a Grave supplied cemetery, city, county, state, and country, for many of the other 202 entries (which obviously include the Riverside one discussed above).

In almost all cases I get a single, clearly correct, place listed as in the Riverside example above. I have never seen more than two placenames returned; where there are two, the ones I've seen consist of a non-cemetery placename plus what is clearly the correct standardised cemetery placename. (I am happy to do further testing if useful.)

For the example mentioned above with 100 placenames currently showing,

q.name:"Cedar Hill Cemetery, Big Clifty, Big Clifty, Grayson, Kentucky, United States of America" gives:

Big Clifty, Grayson, Kentucky, United States and
Cedar Hill Cemetery, Clarkson, Grayson, Kentucky, United States

It is not clear why so few of the 20705 entries have FS-interpreted cemetery placenames on them at all. I don't think those cemeteries can all be missing from the Places database (certainly the ones I have tried all seemed to be present). Perhaps there is a new project to add them (which would make sense to me). Whatever, I don't honestly think that the way the FS-interpreted cemetery placenames appear to be working at present is fit for purpose.