* Map Life Facts plugin with Bing Maps support

[BillH]

Mike,

Those two websites work as you describe in Chrome and Firefox.

Using the sample project, I get the following when I try to switch from Leaflet Maps to Bing Maps for the Plugin Map Pane and I also get the Map Action Sync Failed message.

image6.jpg (18.41 KiB) Viewed 2022 times

Bill

[BillH]

15 minutes later it seemed to be working fine with the sample project. I was no longer getting the script error or the Map Action Sync Failed message and the map was displaying.

Now however I am getting the Map Action Sync Failed error and no map.

Bill

[tatewise]

Thank you Bill. There is clearly some marginal effect that sometimes prevents the script from running.
If I could repeat the symptoms it would be easier to investigate.

Do you have another PC on which FH V7 is running that you could try sometime when convenient.

[BillH]

Mike,

No, I just have this one.

I did just try to go to the first website you listed earlier and got this error.

image7.jpg (17.25 KiB) Viewed 2018 times

Clicking on reload resulted in the web site showing without an error.

Now that I think about it I have been getting this error on other websites occasionally when I'm in my browser. I've never been able to determine why I'm getting it. It doesn't happen on all websites. Maybe whatever is causing this error is causing the error in the plugin?

Bill

[tatewise]

When I Google searched the Script error on Line: 0 Char: 0 the popular reason was poor web access.
It seems you may be onto something. Is there anyone local or a computer shop that might be able to investigate?
Perhaps it is a WiFi problem if you use that, or a network adapter fault, or router fault, or ... ?

[BillH]

I am hardwired to my router. It started happening very occasionally about two months ago. I haven't changed anything other than Windows updates. Interestingly it never happens in the plugin with Leaflet Maps and never happened when there was the Google Maps option. I wonder why Bing maps seems to have a problem. I can just stick to Leaflet maps in the plugin for now.

If no one else has any problems then it must be something in my system somewhere.

Bill

[tatewise]

Windows Updates are known to sometimes upset device drivers.
So possibly your Internet Network Adapter needs checking.
You could also try the Network Troubleshooter.
However, it is too complex a topic to get deeply into on this thread.
I cannot explain why Bing Maps is having a problem and the others are not, except that you have been focussing on Bing Maps and maybe have not used Leaflet Maps or Google Maps much in recent months.

[JoopvB]

Mike,

For me the plugin (your latest version) is working fine. I have it set to Plot Geocoder: Google Maps and the plugin and Web Page Maps to Bing.

One thing: when I press Geocode Plot This Location it finds the location (coordinates), but doesn't show the map. When I press it again (for the same location) it shows the map and correct location. Any idea why?

Cheers, Joop

[tatewise]

Thank you for that feedback. I have been waiting to see if anybody other than BillH had given it a trial run.

When you say you've set Web Page Maps to Bing Maps, I guess you have also set Plugin Map Page to Bing Maps.

I suspect you are seeing one of the "display issues with zooming and centring single plots" that I mentioned.
When you say it "doesn't show the map" do you really mean there is no map or that the map does not zoom to and show the marker pin in the centre?
If you zoom out using the minus button does the marker pin eventually appear at its location?

I think I have found and fixed that problem but I'm working on getting the marker pins to cascade down and bounce as they do in Google Maps and Leaflet Maps before posting another prototype version.

[JoopvB]

About not showing the map... what happens is that the correct coordinates are found but the map shows some place in the desert of Algeria (all zoomed in). When I then Geocode Plot This Location again, the coordinates stay the same and the map shows the correct location.

I've tried all combinations of Bing and Google settings and they all work, although Google Plot Geocoder seems to find more locations than Bing.

[tatewise]

Please find attached Map Life Facts plugin Version 5.2.4 Date 20 Apr 2023.

This version should fix the map display issues discussed earlier.

It also adds the Cascade and Synchro animations when adding Bing markers.
That took longer than expected because unlike Google and Leaflet the animations are not built-in but had to be coded in JavaScript which led to performance issues that are now hopefully resolved.

Previous versions of Bing Maps automatically hid the names of places that were behind the markers.
That often meant it was difficult to see what place name the marker was marking.
This version no longer hides place names (which is similar to Google and Leaflet maps).
It also has a performance benefit when animating the markers.

It does seem that the Bing Maps geocoding may need some place names to be 'tweaked' to obtain the correct plot.
I think that is sometimes necessary for Google Maps geocoding too, but maybe not so much.
However, manual plotting is supported via right-click and dragging markers.
Obtaining a Bing Maps API Key is far simpler than Google Maps.

[JoopvB]

Working perfect!
Indeed Google geocoder is for some places somewhat better than Bing. I have both API's so I use Google.
Thanks for a great job!

[Gary_G]

Mike;

The new plugin (using Bing) is apparently working well.
It geocoded all 280 of my locations (mostly French) without missing any.
I was a bit surprised as I wasn't sure that it would recognize the names of some places in France that had eluded other programs.

[Gary_G]

Mike;

Just for a laugh, I ran a reverse geocoding of my coordinates using the website; https://www.geoapify.com/reverse-geocoding-api.
While it has an API interface, I just uploaded a file of my coordinates and ran using the websites interactive mode.
Most places were a few tens of metres off at most. However; one was way off and placed Lanigan, Saskatchewan, Canada in the middle of the Atlantic. That's not a big issue and I know that's beyond your control. So; all-in-all, it did pretty well for the 284 locations In my Place list.

I have noticed with French records that the Bing algorithm must not to use the exact place given. That is; one gets the same coordinates for "Fresnoy-en-Thelle, Département de l'Oise, Picardie, France" and the newest name of "Fresnoy-en-Thelle, Oise, Hauts-de-France, France". If it just uses something like "Fresnoy-en-Thelle, France" to search, then for other places in France it could get incorrect coordinates. In France there can be many communes with the same name and the department is needed to find the correct one.

==> That leads to my actual question; Does Bing give any feedback on the match it has found? If only in a log file, It would be helpful to know the plugin search parameter and the corresponding place found and used for coordinates. Is that even possible? Maybe the plugin already does this and I'm not aware of it?

[tatewise]

I'm not sure how you come to the conclusion "that the Bing algorithm must not use the exact place given".
With my limited knowledge of French places, it seems that both Fresnoy-en-Thelle, Département de l'Oise, Picardie, France and Fresnoy-en-Thelle, Oise, Hauts-de-France, France are exactly the same location in the same département.
Google and Bing geocode them both to the same coordinates 49.2009649, 2.2691710 and 49.2013168, 2.2705519 respectively which are only about 100m apart.
With a name like Fresnoy-en-Thelle which is unique worldwide, it is not possible to tell what parts of the place name are actually used in the geocoding.

It is only with a place such as Wellington that exists in the UK, USA, Canada, South Africa, India, Australia, New Zealand, etc, that it is clear that the country plays a part in the geocoding and if the place does not exist the geocoder usually plots in the centre of the country or its capital city.

The plugin just submits the full place name, with whatever Smart Geocoding changes are appropriate, to the Google/Bing API which returns the coordinates. I'm not aware of whether there are any logs or other feedback that indicates which parts of the place name were used/ignored. The documentation of the Google/Bing API dialogue is freely available and provides details of what can be submitted and what is returned. You are welcome to investigate its options.

[AdrianBruce]

... which parts of the place name were used / ignored. ...

While many others - starting with Mike - will have got close-up to the APIs of geocoding, I'm not sure that I've yet been convinced that "parts of the place name" play a completely logical role in geocoding algorithms. The idea that a place-name of "A, B, C, D" is analysed in that (or the reverse?) order is totally logical. But is it how it's done? It's like expecting Google to actually parse my sentence when I make an enquiry of it. So far as I understand it, it doesn't - it might look like it does that, but that may simply be due to the way sentences are entered in web-sites.

I've seen odd geocoding by the Google engine which is often apparently attributable to there being a street name involving the right town - if it were analysing place-names logically, it wouldn't be looking for the place-name in the position of a street-name. That suggests to me that the geocoding algorithms may use the names as if they were free text without any embedded meaning. Maybe....

[Gary_G]

I'm not sure how you come to the conclusion "that the Bing algorithm must not use the exact place given".
With my limited knowledge of French places, it seems that both Fresnoy-en-Thelle, Département de l'Oise, Picardie, France and Fresnoy-en-Thelle, Oise, Hauts-de-France, France are exactly the same location in the same département.

Mike;
Seems posts result in not being able to get across what I'm trying to say. Let me try and explain where I was going with my line of thinking...

While the commune and country are the same, the department is not exactly the same and the region name is markedly different. The latter variation is the most recent official name for the same place. That is; Picardie region no longer officially exists. You say it found both very distinct variants about 100m apart. So; Bing must recognize "historical" names for it to actually find and geocode both unique name strings and return slightly different coordinates. This is important to know, since it would imply that one might be able to use an historic place name and still get a valid result. That would remove the need to worry about whether one chooses to record the name at the time of the event or the current name. Whether to use a modern or historic name has been the subject of many genealogical posts and webinars. So; I'll definitely give this a try with even older variants and see if Bing can geocode them correctly. If it works, I can then use just the historic (fully-qualified) name in my records and still have it correctly geocoded.

France is a challenging country for place-names. While Fresnoy-en-Thelle is relatively unique in France and was chosen to illustrate a particular point, it is quite common to have the same commune name occur in multiple departments and regions at the same point in time. It is also common to have the department and region names change over time, even for the same commune. So; is actually very important to specify the whole name string and check that it is finding the correct one.

If you say that Bing doesn't return the name that it says is a match or provide a log file to the plugin, that's all I really asked or expected.

[Gary_G]

Adrian;

I think I get what you mean. But it's very odd that Mike's queries returned two set of coordinates differing by 100 metres or so. If Bing only picked up the key words; Fresnoy-en-Thelle + OIse + France, it should have returned the exact same coordinates. The rest of the string is different. Sounds like there's more at work than just picking keywords from the name-strings.

I should note that I tried just "Fresnoy-en-Thelle, France" and I got a totally erroneous set of coordinates. So it seems to need the rest of the string to get it correct.

[tatewise]

Gary, sorry, you misunderstand what I said about the two geocodings.
Google geocoded both place names at 49.2009649, 2.2691710.
Bing geocoded both place names at 49.2013168, 2.2705519.
They are only 100 metres apart, i.e. the next street, and well within the boundary of Fresnoy-en-Thelle.
So for all practical purposes, Google and Bing produce identical geocodes.

In general, you can only expect modern place names to be geocoded.
If some historic names are so popular that they are still in regular use then maybe some geocoders will recognise them.

Adrian, I get the feeling that sometimes Google gives 'popularity' greater weight than some place name fields.
i.e. Washington, USA is going to be a more 'popular' search than say Washington, UK.
However, I have only noticed that effect when the country and county are omitted.
If a street name matches a town name in the same county & country then I'm not surprised Google may get them confused.
It does not know which name parts belong to a street, town, county, or country but I believe it does follow the hierarchy and having narrowed the search down to a specific county may then use 'popularity' to choose between a street name and a synonymous town name. Rather like the general Google Search often puts popular 'hits' above less popular ones.

[Gary_G]

Mike;

Thanks for explaining.

My biggest concern, I guess, is that it sounds as if one almost needs to validate every geolocation to be sure that any of the automated systems "gets it right". That is essentially what I was doing by using the reverse geocoding app/API to see if I got the original place. It's very much the same technique as one uses when doing translations; translate it one way and translate it back, then see if they are close. Maybe when I get up and running and have the time to learn the programming language for plugins, I'll be able to automate the process I recently used to test my coordinates.

By the way; I ran Fresnoy-en-Thelle through the stock FH7 geocoder and got some very interesting results. In the following image, take a look of the first of the four combinations. I can't see why it would be the only one so far out. Perhaps as you say there is a "popularity"-factor in some of the geocoder suggestions.

Fresnoy-en-Thelle Coord Check.jpg (70.45 KiB) Viewed 1391 times

[tatewise]

The mystery deepens because I get the following coordinates using the FH Mapping tool that differ from yours:

Mapping UK.png (21.47 KiB) Viewed 1350 times

[AdrianBruce]

... Adrian, I get the feeling that sometimes Google gives 'popularity' greater weight than some place name fields. i.e. Washington, USA is going to be a more 'popular' search than say Washington, UK. ...

That would be a good way of putting it, I suspect.

[AdrianBruce]

The mystery deepens because I get the following coordinates using the FH Mapping tool that differ from yours ...

I am not convinced that the "native" FH Geocoder behaves consistently. A couple of days ago I did some experiments about geocoding semi-garbage placenames which I mention in the post on viewtopic.php?f=32&t=21833#p136810

I did my usual trick of a quick run through, followed by resetting the data and doing it "properly" with screen shots and / or data capture. As far as I remember, my semi-garbage placenames in Cheshire geocoded differently the first time compared to the second run. Because I didn't do proper captures the first time, I could be wrong. When I reset the test places today, the resulting geocodes in the "native" FH Geocoder were, so far as I could see, identical to the 2nd run. So I can't actually prove anything - but Mike and Gary's results do differ...

[Gary_G]

Mike and Adrian;
I can't say why they differ, but it does appear to be somewhat random.
Will have to investigate further, because this not a good thing.

[Gary_G]

Mike and Adrian;

I submitted the test set of 4 versions of Fresnoy-en-Thelle to https://www.geoapify.com/tools/geocoding-online and downloaded the resulting .CSV file. This tool also shows what it interpreted the place-name to be and its confidence level in having correctly geocoded what was submitted.
In the case of Fresnoy-en-Thelle, the last two of the four had a 100% confidence level and both geocoded as 49.2011423, 2.2695508 (latitude,longitude). It also showed that it correctly recognized them as a general reference to the town as a whole. Strangely; the data for both came from OpenStreetMap. This test was a bit of an eye-opener. I've attached the CSV file for whoever is interested.

With the GEOAPIFY API it would be possible to geocode and set the FH7 flags based upon the returned confidence levels. That could be helpful for those who have been finding that some services return coordinates that are not valid. I also noted that they also provide code and examples for functions to access their API services and I believe the first 3,000 queries/per day are free.

[For others that are reading this, they also have an online reverse geocode app and an associated API.]

I hope someone finds the above to be useful.