Family Historian User Group

I was talking to the Derek Heritage group this evening and tried to show the Place Exceptions plugin

It worked fine on small projects so I tried on the Halstead study database which as 25,000 place names and it errored with the following message

Sorry John, it is caused by a Place name that contains an unmatched opening parenthesis.
i.e. East ( London, England

The attached prototype plugin version should work around that issue.

Mike
Thanks that fixed the problem
However, all the entries with a "(" have a closing one ")"
But I did notice this one
, , , at sea (Sulawesa Tengah, Indonesia)
and wondered if the "," in the middle would throw it out?

Yes, that is the problem entry because the Place name is primarily split on the comma separators.
So it treats at sea (Sulawesa Tengah and Indonesia) as two separate place parts.

I wonder if a 'better' solution is for the plugin to ignore commas enclosed by any form of bracket pairs.
However, I think not, as FH does NOT ignore such commas, so the plugin should mimic FH just as it does now.

Mike
Thanks for the explanation.
I have changed it to at sea (Sulawesa Tengah; Indonesia)
Something I picked on in a comment of Simon's somewhere which means it fits a single part in the place name

Hi Mike

I have run 1.1 and the amended 1.1.1 version in this thread, but both give this error:

Sorry about that Neil.

It is in the section looking at Places with similar names to find Lat/Longitude outliers, i.e. potential faulty plots.
There must be some unusual boundary condition that the plugin does not cater for.
I have added a diagnostic report to the attached Place Exceptions plugin Version 1.1.2 Date 7 Jan 2023.

Please run this version and post the report so I can analyse the details.

This is what resulted in the output Mike

Thanks Neil.
The -nan(ind) indicates the Lat/Longitude calculations to find outliers are malfunctioning for some reason.
Could you please supply the Lat/Longitude values for those three Place records in Enville Street, Stourbridge.
Then I can recreate and debug the calculations then hopefully fix the error.

Hi Mike,

Here they are:
Enville Street, Stourbridge 52°26'56.28"N, 2°10'9.23"W
41, Enville Street, Stourbridge 52°26'56.28"N, 2°10'9.23"W
112, Enville Street, Stourbridge 52°26'56.28"N, 2°10'9.23"W

...which all seem to be the same.
From memory, these would be from a Gedcom sent to me some time ago for my wife's ancestors (I don't know from what program), and seem to be split across Parts 1 & 2 of the Place differently

With those details, I get exactly the same error symptoms. So now to analyse why they cause a problem.

Thanks Mike,

If I correct those 3 places to be consistent with other 'Places' and re-run the plugin, I then get a whole bunch more erroring.
Interestingly, all in Bromsgrove as before, so again, all from the data sent to me for my wife's paternal grandmothers line

What exactly do you correct to be consistent?

My analysis so far suggests the problem is where 3 or more similar Place names have exactly the same Lat/Longitude.
i.e. There is 0 distance between all the plots.
The distance between plots calculation involves complex maths to determine the great circle segment between them and 0 seems to upset things.

tatewise wrote: ↑

07 Jan 2023 21:08

What exactly do you correct to be consistent?

My analysis so far suggests the problem is where 3 or more similar Place names have exactly the same Lat/Longitude.
i.e. There is 0 distance between all the plots.
The distance between plots calculation involves complex maths to determine the great circle segment between them and 0 seems to upset things.

I changed the entry so that Part 1 is the street number/address, Part 2 the town/city, Part 3 the county as per other entries, which it the way I try to enter places.

Please post the three entries Place names and Lat/Longitude as you did before.
I don't understand how the changes you describe would fix the problem unless they were auto-geocoded with new Lat/Long.

The entries now read like this, but the Lat/Lon are the same

Enville Street, Stourbridge, Worcestershire, England 52°26'56.28"N, 2°10'9.23"W
41 Enville Street, Stourbridge, Worcestershire, England 52°26'56.28"N, 2°10'9.23"W
112 Enville Street, Stourbridge, Worcestershire, England 52°26'56.28"N, 2°10'9.23"W

I guess there are other Place records also in Worcestershire, England or in Stourbridge, Worcestershire, England.
i.e. The condition that 3 or more similar Place names have exactly the same Lat/Longitude no longer applies because those problem 3 are now in a larger group that have different Lat/Longitude values.

It would be helpful to me if you could keep your 'problem' database in its original state so that when I fix the plugin it can be tested against your database. Otherwise, how will I know if your original problem really is fixed?

OK, will do Mike.
As I mentioned before, I still get errors, so I will not change those entries.

Interesting aside, I just checked the Lat/Lon of the 3 entries we began with, and it is just over a mile from Enville Street in Stourbridge.

neil40 wrote: ↑

07 Jan 2023 22:03

Interesting aside, I just checked the Lat/Lon of the 3 entries we began with, and it is just over a mile from Enville Street in Stourbridge.

I'm not sure if you think that is good or bad.

The problem I've found is in the formula for calculating distance & bearing of each plot from the centre of multiple plots.
When the plots and the centre are all in the same location then the formula gives irrational results due to the limited ability of computers to hold numbers accurately. Anyway, I have adjusted the formula to cope with such problems.

So try the attached Place Exceptions plugin Version 1.1.3 Date 8 Jan 2023 and let me know your results.

tatewise wrote: ↑

08 Jan 2023 14:56

neil40 wrote: ↑

07 Jan 2023 22:03

Interesting aside, I just checked the Lat/Lon of the 3 entries we began with, and it is just over a mile from Enville Street in Stourbridge.

I'm not sure if you think that is good or bad.

Bad! I was quite surprised it was this far from the co-ordinates.

tatewise wrote: The problem I've found is in the formula for calculating distance & bearing of each plot from the centre of multiple plots.
When the plots and the centre are all in the same location then the formula gives irrational results due to the limited ability of computers to hold numbers accurately. Anyway, I have adjusted the formula to cope with such problems.

So try the attached Place Exceptions plugin Version 1.1.3 Date 8 Jan 2023 and let me know your results.

Happy to report that it has run perfectly with this amendment. Many thanks.

neil40 wrote: ↑

08 Jan 2023 20:03

tatewise wrote: ↑

08 Jan 2023 14:56

neil40 wrote: ↑

07 Jan 2023 22:03

Interesting aside, I just checked the Lat/Lon of the 3 entries we began with, and it is just over a mile from Enville Street in Stourbridge.

I'm not sure if you think that is good or bad.

Bad! I was quite surprised it was this far from the co-ordinates.

I recall you said the co-ordinates were supplied in a GEDCOM sent to you.
So whatever or whoever set those values got them wrong.
If you auto-plot those Place records in FH then they usually plot exactly on the street
Although the house number may confuse things. I found that they either plot on the street away from where the number exists, or sometimes they plot somewhere else entirely.

However, such success cannot be guaranteed down to street level (or even village/town level) for auto-plotting places everywhere in the world.

Place Exceptions plugin Version 1.2 Date 13 Jan 2023 is now in the Plugin Store.

Mike, had you considered adding capitalisation validation?

Something else I'm helping with came a cropper because of a place like East ham, Essex, England.

Sorry John, I can't read your mind! You'll have to explain more preferably with examples as my crystal ball is on the blink!

East ham should be East Ham.

FH thinks they are two different places!