Coordinates and mapping issues
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
1 Attachments
#2982 Coordinates and mapping issues
I have been playing around with how to represent where the grave site of an individual is to help my users find their relatives grave sites. Since the only place to enter map coordinates are under the burial place area, that is what I did (if there is a better place let me know). As an example of an individuals burial info, the resulting GEDCOM output extracted is:
1 BURI
2 CEME Springcreek Cemetery
2 PLAC Mississauga, Peel Regional Municipality, Ontario, Canada
3 MAP
4 LATI N43.52275
4 LONG W79.63508
2 ADDR Clarkson Road North, Mississauga, Ontario
2 SOUR @S305@
3 DATA
4 TEXT PLOT: L-42
5 CONT https://www.findagrave.com/memorial/13913448/donald-r.-terry
Issue 1: As seen in the screenshot it displays the Cemetery name below both the Place info and the Map info? I understand that PhpGedView runs GEDCOM 5.5.1 and while the CEME cemetery tag got deprecated since GEDCOM v5.4, it has been great to have this field in the Burial records for easy visibility of the Cemetery, but not sure why it is displayed below the other fields.
Issue 1b: Follow-on is that GEDCOM 5.5.2 extended the length of the LONG and LATI fields to make the GPS coordinates more precise. It looks like the existing LONG and LATI fields even in your 5.5.1 implimentation don't have length checks on them so I have tried adding extra digits without seeming limits - should there be a boundry check otherwise there a potential for an overwriting the end of an array?
Issue 2: Beside the longitude and latitude fields there is the Terraserver link (last icon). It should be removed beside the longitude and latitude info as that site has gone dark and the the URL no longer works.
Issue 3: The mapquest URL that is generated goes to the wrong location (ie the long and lati above generates http://www.mapquest.com/maps/map.adp?searchtype=address&formtype=latlong&latlongtype=decimal&latitude=43.52275&longitude=-79.63508 which then resolves to https://www.mapquest.com/us/california/oakland/94611-5378/3891-piedmont-ave-37.82505,-122.25467) which is wrong. If you instead paste the longitude and latitude info (N43.52275 W79.63508) into mapquest search bar you get https://www.mapquest.com/search/N43.52275%20%20W79.63508 which seems to work fine.
Issue 4: Looking at a burial record, if you click on the Plac field (Mississauga, Peel Regional Municipality, Ontario, Canada), then it generates a Place Heirarchy screen where the map shows "Oops..." . If I however go and do a Place Check for that same location, it generates a proper map (albeit with the "For development purposes only" info that I am ok with). It seems like the Place Heirarchy screen is using a different map display from the Place Check map display.
Issue 5: If you edit the burial record to add/view the coordinates, they are not visible until you click on the target icon. I would have expected that if you expand the burial place (+ under the place), then the coordinates should become visible as these are a GEDCOM substructure of the place and not independant of it, even though I am using them for the location of the grave not the general city where the cemetery is in. So if there are GPS coordinates already filled in when you edit they remain hidden, but should they be automatically shown, or minimally wait until when you expand the place info?
In general I have about 1100 graves that I have taken pictures of and therefore have GPS coordinates I want to fill in, but will wait until some of these issues are addressed otherwise my user community will start complaining to me.
I originally had several attachments - here they are again
I will look at these issues. But, sorry, not now. First I will finish
the upgrade of js libraries (this should address the issue 4).
The "developement only" issue is google api problem; actually their
current policy. If you buy access to google map api and provide proper
key - maps will be displayed correctly. It is the reason why I'd like to
migrate from google maps to OSM in the future.
T.B.
Thanks Tomasz.