Googlemaps: choose best available coords

[Scott Barnes]

When creating a map, Googlemaps currently extracts coordinates for the lowest-level segment of the place name. If the name exists in the place hierarchy, but the location is undefined, a bogus map pointer over the Atlantic Ocean (latitude=0, longitude=0) is shown. If the name doesn't exist in the place hierarchy, no map pointer is shown. I believe this logic creates barriers to usage of Googlemaps, especially for those who choose to extend the place hierarchy below the city/town/village level.

The attached patch changes the manner in which Googlemaps selects coordinates for a given place name: at each step of the place hierarchy, the coordinates are evaluated. If the coordinates are not at the defaults (0,0), that place ID is remembered as the best available so far. When the hierarchical search terminates (due to everything matching or due to a name segment not being matched), the coordinates of the best available place ID are retrieved. If nothing in the hierarchy matches, no map pointer is shown.

The philosophy of this patch is that a less-accurate map pointer is better than none at all. Also, bogus map pointers over the Atlantic Ocean should never be shown under any circumstances.

[windmillway (windmillway)]

Scott, I totally agree with your philosophy.
Give me a day or so to test this out, and then I will post it to svn.
OK?
And thankyou for the patch ;-))

Brian

[Scott Barnes (s-barnes)]

Brian - I found that my test for an invalid coordinate was too strict. As discussed in the forums yesterday, longitude and latitude don't necessarily begin with a direction letter. I have revised the patch to accept anything except literally (0,0) as a valid coordinate.

[kiwi (kiwi3685-deactivatedaccount)]

I don't believe this is necessary.

The only time coordinates of 0,0 are included is when the "Import from GEDCOM" feature is used. It, incorrectly in my view, adds 0,0 if no coordinates exist with the PLAC tag. However, in the past some (PGV) users insisted that 0,0 was easier to notice and therefore correct than blank! I disagree, and think we should simply change the Import code (very simple to do) to leave the coordinates blank.

Then webtrees normal rules of using the next level up when there are no coordinates is all that is required.

However, I do also strongly disagree with the statement "a less-accurate map pointer is better than none at all". Thats is totally contradicting all good genealogical practice. If you don't know a fact, you should not include it as one. By all means included it as a note or something, but not as something that appears to be a fact.

[windmillway (windmillway)]

Scott,

I have to agree with kiwi.
Using your code or not makes no difference, with the exception of when a place has been imported from the GEDCOM as kiwi says.
This is also where I believe the code should be fixed. (and I will endeavor to do that after consultation with other developers)

However I did find that when a non defined place is found on the "place check" admin window (item is in red with red x's)
that if you click this red location to define the place, then a red marker did appear at location (0, 0)
I have now fixed this, and the marker will be postioned at the parent level location.
All that remains to be done now (as before), is to either:
a) do a "search on this level" to provide any possibilities with yellow markers which can be clicked and the click "Use this value" in the info-window.
OR
b) Drag the red marker to the position you want
OR
c) Click the map to position the red marker where you want.

The only other thing that happens that is misleading, is on the place hierarchy page.
If a location is not defined, and there are no other places at this level below the parent, then the parent map, (which normally shows the "child locations"), is blank, with no markers shown, indicating that a place check should be run to verify this.
(This is logical)
However the parent map is centered at (0, 0)
(This is not logical. it should be centered at the parent location.)
This I am in the process of fixing now.

Both fixes I will post to svn shortly when done.

Brian

[Scott Barnes (s-barnes)]

If the "normal rules" regarding use of parent coordinates apply to all parts of the application, then get_lati_long_placelocation() is deficient and should be fixed. Parent coordinates are not selected, regardless of whether the missing coordinates are marked as (0,0) or (blank, blank). My patch allows grandparent and higher coordinates to be selected, but it could be made to work only for the parent level also. The point is that the current code isn't even reading the coordinates from the database when it should be.

Once this patch (or one like it) is in place, administrators will not be forced to fill in temporary coordinates in Place Check just to make Googlemaps happy. The maps can depict places at the "fifth level" (below city/town/village) by using the city coordinates. Yes, the Place Check problem list will not be empty, but that's OK. The problem list becomes a running to-do list instead.

[windmillway (windmillway)]

Scott,

Thanks for your reply.
Would you please allow me a few days to understand/fix what I see as possible inconsistencies in presentation.
i.e.
(1) Whether a map marker should be present on the map or not
     (and maybe what colour it should be if there are missing definitions, so as to readily highlight inconsistencies)
(2) What should be the center point of the map (or if there should be a map at all) for a non existant place.
(3) Whether a place should be listed in the google map side bar list or not.
(4) How (1) to (3) should be presented in the Place-hierarchy Map, and the Edit geographic locations edit map.
(5) How all of the above should affect the Street-view imaging that I added

Only then will I be able to answer your statements with a knowledgeable premise.
The conversion from v2 to v3 I accomplished by using, as best I could, the premises and logic of the existing code.

I hope you will bear with me, and if necessary take this up after.
At the moment, I do not see a bug per se, rather than a request for coding improvement.

I realise I am leaving myself open to a ton of suggestions, but with respect, I would rather do what I see is necessary now, and then pick up on and reply to any suggestions later. Fair enough?

I will leave this open, but mark as triaged.

Brian

[fisharebest (fisharebest)]

<<The only time coordinates of 0,0 are included is when the "Import from GEDCOM" feature is used. It, incorrectly in my view, adds 0,0 if no coordinates exist with the PLAC tag. >>

I don't see this behaviour. Importing from GEDCOM creates NULL / empty co-ordinates.

Is this bug still present in the latest code?

[kiwi (kiwi3685-deactivatedaccount)]

<< Is this bug still present in the latest code? >>

This was never a bug in the first place.