Handling what goes in "Place" with FS enabled.

[DanCornett]

v4.17.3.21

This location (2026) fills fields badly.
Dowling Cemetery, Dowling, Baltimore Township, Barry, Michigan, United States

[DanCornett]

Another string which fills fields badly:
Mount Blanchard,Hancock, Ohio, United States

[DanCornett]

This string actually behaves as programmed; just not semantically quite correct.
Skyway Memorial Gardens, Palmetto, Manatee, Florida, United States

Maybe need to add check for Gardens - similar to Cemetery? Might be too broad; "Memorial Garden" might work (with appropriate pre-checks for abbreviations of that).

Does "cemetery" check currently also accommodate mauseleum (and spelling variations!)?

[DanCornett]

Another 'bad' example:

[stbodie]

Fixed the Dowling/Monroeville "Township" case (7884c81) - confirmed directly against the live FamilySearch API on both your examples: a civil township (type 378) wasn't recognized as a settlement-type ancestor, so it consumed the County slot and pushed the real county into State, with the real state falling through as orphaned Place leftover text (which is how it surfaced at all rather than silently vanishing). Now folded into City the same way a neighborhood or NYC borough already is.

Also added "mausoleum" as a burial-venue keyword - it just wasn't in the list at all, unlike "cemetery." Left "garden(s)"/"memorial garden(s)" alone for now since you flagged that one yourself as possibly too broad - happy to add it once there's a confirmed case to build the exact rule from, same as how "fort" got walked back after it turned out to match real city names.

Bundled into v4.17.3.22.

[DanCornett]

I'm thinking we need to handle this Township case better.
When the original location string does not have Twp or Township in it, maybe don't add the type 378 to the City location -- unless there is nothing else to put there.

"Kalamazoo, Kalamazoo, Michigan, United States" is an example. It is now returning the City => "Charter Township of Kalamazoo" ... and that doesn't "sit right". I also noted a number of cities getting their Township added ... when it seemed unnecessary AND it wasn't referenced in the original string.

(I expect we'll have more of these types of situations once there is more non-U.S. usage ... but hopefully not too many!)

[DanCornett]

On the whole, when Township is explicitly in the source location, this is handled nicely.

[DanCornett]

v...23: I'm not seeing at lot of improvement so far on this version;
"Kalamazoo, Kalamazoo, Michigan, United States" still has "Charter Township..."

"Woodland, Woodland Township, Barry, Michigan, United States" pushes city value into Places.
adding a cemetery in front of it still keeps the city after the cemetery name
On the other hand, "Middleville, Thornapple Township, Barry, Michigan, United States" does exactly what one wants.
Maybe something about having the same name city & township?
(3 screen grabs of those 3 cases)

I shifted the Place field so one can see the "Woodland" after the cemetery name:

[DanCornett]

Same (as expected) in v...24
"Jackson, Jackson, Michigan, United States"

Seems to be some consistency in "same names".

[DanCornett]

Looked at FS interactive for "Grand Rapids, Kent, Michigan, United States"
date 1831->today for the city
date 1834->today for the township ("Charter Township of Grand Rapids, ...")

If the original string does not have "Township" (as in this case), and dates allow, then don't add (or use) Township when there is City (I may have suggested this elsewhere?).

Grand Rapids is being handled properly (w/ v...24); as are most other cases. ("Woodland" is common in the family I'm looking at, and consistently is not handled like the others.)

[DanCornett]

A German location not handled well:
"Simmersfeld, Oberamt Nagold, Württemberg, Germany" 1833
... which is probably because Oberamt Nagold did not exist (according to FS) until some years after 1833.
"Simmersfeld, Landkreis Calw, ..." exists for dates on both sides of those for Oberamt Nagold.
However, SC is not handling that real well; it didn't cleanly put in "Landkreis Calw" (just the Calw).

Screen grab for: https://www.familysearch.org/en/tree/person/details/93NJ-M3J

This may be the kind of situation which ought to be flagged with the "location warning" status. i.e.: location not precisely known for that date.

In this example, I could put in dates further outside the "valid range" for Oberamt Nagold (e.g. 1980), and SC actually put in Oberamt Nagold and Württemberg ... which is not valid. Again, a reason to 'flag' the location with a warning.

It's not an out-right error, as in the town/village of Simmersfeld existed throughout those dates, and the GPS coordinates don't change. It's just the "name for that time period" isn't correct. Hence, warning, not error.

[DanCornett]

I just found out a bit more ... related to dates used in lookup.
I first thought I found inconsistency: death & burial locations treated differently for:
"Woodland, Woodland Township, Barry, Michigan, United States"

Then I realized I was using 'modern name' for burial. Using earlier date for burial gave result consistent with death date!
I can't see why that would be happening, as the interactive lookup only returns one value for:
"Woodland, Woodland Township, Barry, Michigan, United States" or
"Woodland, Woodland, Barry, Michigan, United States"

"Woodland, Barry, Michigan, United States" returns both the city and the township instances, which have slightly different inception dates.

Which makes me wonder ... (enhancement) ... carry along a 'reason for warning' string with the warning flag so that the a hover or click on the warning symbol would show the specific reason for warning (e.g. location name not correct for the date of xxxx).

[DanCornett]

Ah ha! If one puts in 2025 for year, "Woodland, Woodland Township, Barry, Michigan, United States" is handled properly.

So maybe some comparison to "today" vs. 2026 is wonky...

[DanCornett]

This date-factor probably also affects strings such as
"Kaufman, Kaufman, Texas, United States" with a date of 1836 ... which did not exist at that time. Kaufman does appear as an alternate name for earlier dates. (e.g. just using "Kaufman, Texas" ... in 1840 that location was known as Kingsboro up till 1848 ... no FS name for a town earlier); hence -- warning flag.

With appropriate warning messages, Geni users might start feeding FS request to expand on such location names (grin).

[DanCornett]

"Ruggles Township, Ashland, Ohio, United States" 1840 gives wonky field filling; changing date to within valid range of 1846 (for that location, then it is handled nicely.

Thus, probably need a nicely-handled fall-back for this kind of thing, but definitely flag as a warning. Even though it will "look correct".