Locations & SmartCopy

This location: "Toronto, Wdsn, Knss"
ends up in Toronto, Canada
instead of the intended Woodson County, Kansas, USA

Another thing to watch out for: City with the same name as County.

Most historical (U.S.) records only record the 'county'. So when there is a non-modern record such as:

"Harlan, KY" it should typically be expanded to ONLY
"Harlan County, Kentucky, United States" ... and *not* include the city of Harlan.

Even if the source-text had "Orange,Orange,VA", but the associated date was, for example, a marriage in the late 1700's or early 1800's, I'd assume that it was really simply Orange County, not the city (and that somewhere along the way a 'lookup' had done a similar "assumption" of the city name).

If other, more detailed/reliable records have the city, great! But probably a false assumption to make ... and one that SmartCopy (because of the way the location parsing works) tends to contribute to.

So, blank out the duplicated city name before 'Submit' for copying ... unless you're pretty sure the city is actually correct.

Not sure there is much that can be done on "Toronto, Wdsn, Knss", but we might be able to do more with the City / County thing. I could check to see if the City name exists in the County name. If so, check the original string to see if the name appears twice. If it doesn't, then remove the city. But of course, the source may actually intent to say the city (as often they don't list county). So, not sure what the best solution is, but it may be something we can improve on.

Today is the 181st birthday of the City of Toronto. It was actually founded on August 27, 1793 as York, Upper Canada. So depending on when the event occurs, you have two different names for the same place.

Kevin

Or half a dozen:

http://www.geni.com/projects/Jonqui%C3%A8re-Qu%C3%A9bec-Canada/18815

Common location error is for "Ontario". If only Ontario is listed with neither city/county or country, then SC enters Ontario, San Bernardino County, California, United States not Ontario, Canada.

Other kinds of errors can come from missing punctuation:

"Parker Co TX" gets parsed by the API as
"Parker, Collin County, Texas, United States"

FYI: ambiguous City with no other info... I've observed that the Google API can return different things at different times, depending (probably) on what was recently searched and thus 'cached' in Google's location-lookup server that was connected to by the API.

"Hancock, Hancock, Ohio, United States" ... because there is no town of Hancock, Ohio, this gets interpreted as Hancock, Michigan (several hundred miles off!)

Garbage in -> Garbage out :)

But prettified, authentic-looking garbage!

So much more dangerous than the original garbage.....

(I've had unqualified village names in Norway matched with villages in Gambia.....)

I came across yet another reason to expand details and scan the locations ... the 'source' page had also put in the date as the location! That generated a location via the 'lookup' which was a continent far away.

This is another example which may help refine the location parsing:
Reger Chapel Cem, Buckhannon Dist, Upshur Co, West Virginia

Currently gets the cemetery, state, county, but not the county (nor District, which may be o.k.)

I could easily look for location parts that end in " Dist," or " Co," and just remove it, so the location would be sent to Google as "Reger Chapel Cem, Buckhannon, Upshur, West Virginia", which I expect would resolve it.

Private User Could you make it possible possible to select which picture to use when there are multiples?

I'll put it on the wish list Eldon, though I have higher priority things I'd like to add first. Not sure when I'll get to looking at it as it will involve a bit of work. :)

Once again Jeff, thanks for all your effort.

If curators start using smartcopy for profiles in a language other than their own, the results can be startling. It makes a mess of the tree.

Albert Joseph Barnes
Daphney Jane Climo

Elaine, what mess and how is SC responsible?

Looks like good info and images were added.

Sjedinjene Države?
Engleska,?
Ujedinjeno Kraljevstvo?
Novi Zeland?

Not sure why it produced that - I query the english site and I can't reproduce it by changing my language on MyHeritage.

The language on Geni, i think, translates the location lookup to that language equivalent.

Elaine ... it is possible those two examples came from a merge, not from SmartCopy. (See Daphney Jane's revisions) ... I sent a message to the 'merger' to look at this.

Geni and My Heritage is by me on English language,why Smart copy transferred places and states on Croatian languages I dont know.When I merge profile I did not look how it is written.My mistake
But we are from around the world and I did not make problem when I had to change on 3000 profiles Croatia on Hrvatska.

I will look all my profiles and change

While SmartCopy may 'bring in' the English form of a location, that is not necessarily the case for the Geni "Google lookup" of a location -- I think *that* lookup (e.g.: when editing the the Geni profile) brings the location values in the user's native language ... or perhaps based on the "apparent" user's location, rather than the Geni language setting? I can't test that (without doing some significant travel! <grin>).

Merging two profiles with different alphabets used for locations will 'choose' one or the other, based on the rather complicated rules for designating one of the profiles as "primary" during the merge.

I'm wondered if it could be a Google cookie. Lets say for example, if Lara had her language set on her Google account. I wonder if the location API would pick it up and try to return it in her language.

I just tried this, specifying the language, and it returned in Slovenian.
http://maps.googleapis.com/maps/api/geocode/json?address=Lowestoft,...

So, I'm going to update SC to add language=en to the maps query. Maybe that will fix it.

I've pushed out update 1.52.1, which adds the language specification and tries to address the " Dist,", " Co,", and "Temple" stuff.