* Map Life Facts 3.7 error

[NigelBrown]

Today I have run the Map Life Facts (v3.7) plugin for the first time on a Project directly imported from TMG. It stops every time after a few seconds, at 1%, with the error message as per the attached. I use "Places" not "Addresses" for holding place details. I have followed tatewise's advice on settings e.g. I set Map Life Facts to use Locations From: Place Fields Only and Database In: Place Records, etc.

Does anyone have an idea what this means? Is it my data?

Thank you in advance for any guidance.

Nigel Brown

[tatewise]

Sorry about that Nigel.
When you say Plugin stops after a few secs at 1%, I guess you mean after clicking Geocode Plot All Locations button?

Something is going wrong with the geocoding status from Google and upsetting the Plugin logic.
To get some feedback could you please install the ATTACHMENT below and run it the same way.
It should produce a Family Historian diagnostic popup window giving Loc=... Lat=... Lng=... Ans=... XML=...
Please paste that message window into your reply.

Having done that, click OK, and the same Error Message as before should arise.

[EDIT: ATTACHMENT deleted]

[NigelBrown]

Mike,

Thank you for your assistance. Yes, MLF stopped seconds after clicking Geocode Plot All Locations.

I ran MLF last night after a "tidying" session with my Places List (via Tools/Work With Data/Places), and I carried on with that after my MLF problems. I have now used your new version 3.7.2 and it runs for quite a bit longer, but then stops again, and with your new error reporting I can identify the place name that it stumbles over. In this case it was an address "8 Beecher Road, Cradley", in my home town.

Having closed MLF I then ran it again, declining to include the 586 already Defined Plot Locations. This time it runs further, but stops again. In looking in the Places List at the latest place name over which it stumbles in the Places List I noticed that "8 Beecher Road, Cradley" has now been geocoded in the second run.

I am attaching the Beecher Road errors. MLF is geocoding far more partial (vague) addresses than this one.

I hope you can work out what is causing the problem.

Thanks, Nigel

[tatewise]

Thanks for that diagnostic feedback which explains everything.
The Google GeocodeResonse of UNKNOWN_ERROR is not expected by the Plugin as it was not a documented response from Google last time I checked.
Note that as a result Lat & Lng have no value which leads to the Error Message.
I should be able to find a solution quite quickly.

[tatewise]

Nigel, please try the ATTACHMENT Map Life Facts Plugin V3.7.3 09 Oct 2015 that should fix the problem. [DELETED]

It appears that The Google Maps Geocoding API added the UNKNOWN_ERROR response status some time ago, and it has been causing problems with users of the API ever since, on the rare occasions that it arises.

The Google Maps Geocoding API says: "UNKNOWN_ERROR" indicates that the request could not be processed due to a server error. The request may succeed if you try again.

So the Plugin now detects that status, and for any error status tries geocoding the location again a few times at 1 sec intervals.

[NigelBrown]

Mike,

Map Life Facts Plugin V3.7.3 seems to work perfectly. I ran it late last night and it sailed through ... until it reached the "Daily Quota". So I have 1855 records "Defined" and 1282 with "No Data". I will wait patiently for my new quota to be avilable, and try to complete, but all looks well.

Thank you for your time and effort in resolving the issue.

Nigel

[tatewise]

That is good, and if no further problems arise, then I will publish the Plugin as V3.8 in the Plugin Store next week.

I believe TMG only supports Place details and not Address details, whereas FH & GEDCOM supports both.

You may wish to review your data in the light of glossary:places|> Places and Addresses and its Forum Posts on Places and Addresses. It is strongly advised that you adopt an organised Place/Address structure with one comma separated column part for each field such as Building, Number, Street, District, Town, County, Country, Postcode, etc.

In any case, data such as 8 Beecher Road, Cradley should be supplemented with County and Country, not only for completeness, but to assist geocoders such as in FH Maps and Google Maps, that operate in a global domain.

[NigelBrown]

I'll let you know if anything amiss arises over the next few days, but I'm not expecting it after my successful use last night (apart from exceeding the daily quota).

As for reviewing my place data in the light of Knowledge Base > Places and Addresses and Forum Posts, I have devoted many happy hours to reading and re-reading this stuff, and I find the conclusions and FH user practices to be bewilderingly varied, which is OK but perhaps not much help to a novice user looking for straightforward guidance. However, during 15 years of using TMG I developed my own 8-part Place Style comprising Building/No + Street/Village or Area/Town or City or Registration District/County/Postcode/State or Province/Country. This works for me, and I plan to carry it through into FH, although I might split house number and street if I could think of a good reason why.

Having said I have used this Place Style for many years, my usage has some exceptions (to prove the rule!) and omissions, which is what I am tidying up at present.

Anyway, I don't wish to re-open the place/address discussion and am grateful to you for sorting out Map Life Facts.

Nigel

[tatewise]

OK, so I presume the example of 8 Beecher Road, Cradley is an exception in not having all 8 parts.

I hope you have realised that it is standard practice to add extra commas with blank fields where necessary.

A reason for splitting House Number and Street is it allows Places/Addresses to be sorted more rationally in Tools > Work with Data. If House Number & Street are in one column, then that column sorts into House Number order regardless of Street, which is rarely useful. Whereas if split, all similar Street names sort together, particularly useful if Reverse Display Order is ticked.

There are certainly differing opinions on how best to format Place/Address fields.
This has not been assisted by FH Maps only geocoding Places.
That has tempted FH users to move Address details into the Place field.
The most important strategy is to be consistent throughout.

BTW: You may find the Rearrange Address and Place Parts Plugin useful.

[tatewise]

The corrected Map Life Facts Plugin V3.8 is now in the Plugin Store.