* Map Life Facts questions.

For users to report plugin bugs and request plugin enhancements; and for authors to test new/new versions of plugins, and to discuss plugin development (in the Programming Technicalities sub-forum). If you want advice on choosing or using a plugin, please ask in General Usage or an appropriate sub-forum.
Post Reply
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Map Life Facts questions.

Post by Ron Melby »

Since I haven't gotten feedback on my issue with Mater-Pater, I have done some other 'upgrade' coding.

I am now saving my lat/long to the @_PLAC records and thats working out well, for several of my plugins.

I need to have for certain classes of records, (the immediate need) the address of the cemetery lat/long.

Mike, to be sure I do this correctly how do I keep an address file updated, and separate from matessing untowardly with my place file, and what is the name and layout of the address record file (address.dat?) , when loaded into the table?

what I hope to do, is retrieve the address of cemeteries and their lat/long so I can sort them by lat/long (a rough equivalent to a route-- from me) because one of these fine days, I will hope to map out a road trip to these places where I can, and see what is what in the ground there.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

You are discovering the same as others that geocoding Address fields is not as easy as Place fields.
The reason is that Address fields do NOT have associated records, whereas Place fields link to Place records.
Place records have Lat/Long entries to hold the geocoding, but there are no such entries for Address fields.

So you have a decision to make about which workaround you prefer to use...

1) Map Life Facts Location Data
I suspect you would only be visiting a few cemeteries on each trip.
So you could use the Map Life Facts Plugin to geocode just the Address & Place fields for those cemeteries and make a note of their Lat/Long position from the Plugin window.
There is a ...\Plugin Data\Map Life Facts.loc file that holds those details, but it would be difficult to select the few details you wanted, and would need another Plugin or a new feature in the Map Life Facts Plugin to printout just the cemetery details you needed.

2) Move Address into Place
Some users choose to ignore the Address field and combine all such location data into the Place field.
So in your case the cemetery address would be included in the Place field and geocoding would be easy.
For consistency, all such address details would migrate to the Place field and every Address field would become empty.
However, there would be a lot more Place records than you have now.
There is a Plugin that can arrange the Address to Place migration.

3) Facts Address Source Records
The Map Life Facts Plugin allows Lat/Long details to be held in Source records with the same Title as the Address fields so they perform a similar role as Place records do for Place fields.
The Source record Type is Facts Address and the Note field contains such as:
Map Life Facts Address Location
Substitute =
Latitude = 51.5771069
Longitude = -0.4290474
Plot Mode =

You could then print such Source records when planning a cemetery visit.
However, I have just experimented with the Plugin Set Preference Options > Location Plot Options and switching between Place Fields only in Place Records and Address Fields only in Source Records has revealed a small bug, but after fixing that it works fine.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

it would seem that option 3 would be the best for me at present. Thank you.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

OK, try Attachment Map Life Facts Plugin Version 4.6.1 Date 26 Nov 2019 ZIP file that must be extracted before installing into FH (it exceeds the Forums attachment size limit).
[ EDIT Attachment deleted as now updated in Plugin Store. ]

In the Plugin Set Preference Options > Location Plot Options tab I presume you currently have:
Locations From: Place Fields only Database In: Place Records

To work with Address data change that setting to:
Locations From: Address Fields only Database In: Source Records

Swap between those by changing just the Locations From: setting to Place Fields only or Address Fields only.
The Database In: setting will automatically swap at the same time.

Let me know if you have any problems.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

a question, although I will find out, does it attach the source record it creates to those addresses?

then its a simpler matter to revamp my code, otherwise have to come up with code to attach to address, so I would look for (in my case) @S1944@ FaG in my matGRV module, and then grab the source of the address and print out the combined on my report... otherwise, a more complex situation arises, but not undoable.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

As it says in plugins:help:map_life_facts:4_set_preference_options|> Map Life Facts ~ Set Preference Options for Location Plot Options:
If Source Records are chosen then Source Citations can be added to the associated Facts to supplement the Address details. You may then add further information or multimedia images to these records.
In other words you have to link the Facts to the Source record with a matching Address title.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

I may have misunderstood. this is how I set the preferences.
Untitled.png
it added both place records and address records as sources.
created a list and deleted the 1842 place sources.

there are 0 links for these sources.

If I understand you correctly, I will have to write a plugin to go thru burial and cremation records, and link them, not sure where to start. I will give it a think.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

With those settings the Plugin should only create/update one Source record per Address field value.
The Type is Facts Address and the Note field contains the Lat/Long details.
The Source records in your screenshot all look like Addresses and NOT Places but are rather obscured.
( It would have been better if you had move the Plugin window further to the right. )

It should NOT have created Source records for Place names.

The Place records that you previously created with Locations From: Place Fields only Database In: Place Records should not have been affected. ( You did use Database In: Place Records and not Source Records? )

Not sure what you mean by created a list ?
What 1842 place sources were deleted ?
There should not have been any Source records with Place names at all.

We can deal with a plugin to go thru burial and cremation records and link them to Sources later.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

when I ran the plugin with those settings, it showed addresses but created source records for place and for address. numerically, it created all the place records first, so as I looked at the sources from the records window, the places were grouped together before the address records, they were type Facts Place and Facts Address respectively, so I selected from the first Facts Place to the last Facts Place, copied them in a named list, and deleted the records.

The reason you see only address on the screen was that had already occurred, when; as I wrote the post, I thought you might want a gander at the settings. so I went back into the plugin, and took the screen shot.

I can write the loop to get CREM and BURI, I can write a chunk to load Facts Address sources, I can write a comparison for my address against the Facts Address table, in my burial/cremation records S1944 is always first if there is one (thats FaG) if it exists I want to put it after that source, so it is second, (I know there is some posititioning FH command, but dont remember what it is), otherwise, (in rare cases) put it first in source. I then want to change the type to Cemetery, for easier down the line processing. The place records were previously in place records never in source.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

You must have set Locations From: Place Fields only Database In: Source Records at some stage, and that would create the Source records of Type Facts Place.

Can you see the symmetry with Locations From: Address Fields only Database In: Source Records creating the Source records of Type Facts Address.

From now on for Place names you should use Locations From: Place Fields only Database In: Place Records.

Switch between those two modes by just changing Locations From: setting.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

tblSOUR => (table .940)
948 10th Avenue NE, Rochester, MN, 55906, USA => (table .2)
NOTE => "Map Life Facts Address Location Substitute = Latitude = 44.0341514 Longitude = -92.4497144 Plot Mode = "
SRC (item) => Source: 948 10th Avenue NE, Rochester, MN, 55906, USA
Mueller Motor Company, Staples, MN, 56479, USA => (table .2)
NOTE => "Map Life Facts Address Location Substitute = Latitude = 46.3554617 Longitude = -94.7988628 Plot Mode = "
SRC (item) => Source: Mueller Motor Company, Staples, MN, 56479, USA
St. Sepulchers West, Holborn Viaduct, Smithfield, London, EC1A 2DQ, GBR => (table .2)
NOTE => "Map Life Facts Address Location Substitute = Latitude = 51.5166654 Longitude = -0.1021791 Plote Mode = "
SRC (item) => Source: St. Sepulchers West, Holborn Viaduct, Smithfield, London, EC1A 2DQ, GBR
Arlington Cemetery, Arlington, SD, 57212, USA => (table .2)
NOTE => "Map Life Facts Address Location Substitute = Latitude = 44.3518243 Longitude = -97.1275252 Plot Mode = "
SRC (item) => Source: Arlington Cemetery, Arlington, SD, 57212, USA
Calvary Cemetery, 4820 Howard Gnesen Road, Duluth, MN, 55803, USA => (table .2)
NOTE => "Map Life Facts Address Location Substitute = Latitude = 46.86099 Longitude = -92.108504 Plot Mode = "
SRC (item) => Source: Calvary Cemetery, 4820 Howard Gnesen Road, Duluth, MN, 55803, USA


so I have the key of address, to retrieve the record, from the BURI.ADDR or CREM.ADDR and am hoping that you will assist me in hacking up the NOTE field into its constituent parts. I will make that bit a function and try to generalize it at some point.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

Use the strValue, bExists = fhGetLabelledText( ptr, strLabel ) Plugin API Function.
e.g.
strLatitude, bExists = fhGetLabelledText( ptrNote, "Latitude = " )
strLongitude, bExists = fhGetLabelledText( ptrNote, "Longitude = " )

That is why the Map Life Facts Plugin uses that labelled text format, because it is so easy to extract the values.
This is the 'standard' way of creating psuedo/meta fields within the GEDCOM rules.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

Cor Blimey!
That was harmless, worked the first time in only a few lines of code.
I thought I was in for long torturous weeks of confusion.

thanks.
FH V.6.2.7 Win 10 64 bit
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

function rtvElemCount(eptr)
-- Count instances of TAG
local elem = 0
tblelem = tblelem or {}
local src = src or {} -- cope with first src


while eptr:IsNotNull() do
elem = elem + 1
table.insert(src, eptr)
eptr:MoveNext('SAME_TAG')
end
return elem
end -- fn rtvElemCount

I am horridly turned round here on something that should be simple for me now.
I realize this only returns count of certain tags right now.
eptr contains a pointer to either BURI.SOUR or CREM.SOUR
I have a global ptrINDI
what I want tblelem to be when done is
tblelem[ptrINDI] {src1, src2, src3...} BECAUSE:

@FaG@ needs to be first if there is any source, the @GRAVE ADDRESS SOURCE@ from my address table needs to be second, then sources can come in any order. if no @FaG@ then @GAS@ could be first or (tba ... lol) so I think I need this table for further processing to move @FaG@ if necessary and add @GAS@
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

You did not explain what the problem is, but I guess it is that the src table does not hold the desired pointers?

Remember when saving pointers in a table for future reference you must clone them, otherwise they all become the same.
e.g. table.insert( src, eptr:Clone() )
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

Code: Select all


tblelem = {}

function rtvElemCount(eptr) 
  -- Count instances of TAG
  local elem = 0
  local src = {}      -- cope with first src

  while eptr:IsNotNull() do
    elem = elem + 1
    table.insert(src, eptr:Clone())
    eptr:MoveNext('SAME_TAG')
  end
  tblelem[ptrINDI] = tblelem[ptrINDI] or {SRC = src}
  return elem
end -- fn rtvElemCount

yes my initial problem was the :Clone() . however I face a new problem. My tblelem seems to be new every record instead of additive which is what I desire.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

It is the same Clone() problem, but with ptrINDI this time instead of eptr.

So try:
local ptrIndi = ptrINDI:Clone()
tblelem[ptrIndi] = tblelem[ptrIndi] or {SRC = src}
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

the only cavil I have with the program is that (as you say, who knows commas) but I use commas and a space for placekeepers, and when you strip them out to do the api so that:

Golders Green, 62 Hoop Street, London, , EN, GBR

cant find the postal code, and LondonNW 11 doesnt fit into my scheme, but one hopes one could catch on if going for a look see at the joint...without the NW11 when asking the cabbie for a ride around....becomes:

Golders Green, 62 Hoop Street, London, EN, GBR

he api, instead of the original is set in the TITL, therefore: I fail the tblsrc[ADDR] entry to pick up my LAT LONG.
it isn't millionsof records, but I am fixing by hand...

minor annoyance, and there may be some reason you do it, but....its my data, innit? LOL.

Just reran it, it sees the 33 changes I made as unplotted locations, and means I would have to fix them every time I want to do updates.
Last edited by Ron Melby on 02 Dec 2019 15:01, edited 1 time in total.
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

When the Plugin sends the address for geocoding it tidies up and removes redundant comma spaces.
So what gets sent to the Google API is Golders Green, 62 Hoop Street, London, EN, GBR

The reason you cannot find a postcode is perhaps that Hoop Street does not exist and I suspect you meant:
Golders Green Cemetery, 62 Hoop Lane, London, EN, GBR
Which is at London NW11 7NL

I don't understand your comments about tblsrc[ADDR] ~ sorry!

Did my advice fix all your Clone() problems?
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

it tidies them up for the api, and uses the 'tidied up' field as the address when it plunks them in source records, so when I make a table of them to get my LAT LONG I do not have the API addresses in my file. I have the API version in the source records, and never the twain shall meet, for a key comparison.
FH V.6.2.7 Win 10 64 bit
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

Golders Green, 62 Hoop Lane, London, EN, GBR is what you put in the SOUR.TITLE which I attempt to key on in my table.
Golders Green, 62 Hoop Lane, London, EN, , GBR as it appears in my file, and which I key on the address table from my file.
the lat long is in all the source records, my addresses are pretty good actually.

you put the api form in the source title, and not the original address form.

if I repair them all in the source record, (and I did) and then subsequently run the address in source because I may have some updates in cemeteries, or new cemeteries (et al) from MLF plugin, it sees my repairs as not ran thru the api yet, and re-breaks them.

so you have something like
apiaddr = tidyup(fileaddr)
lat, long = getapistuff(apiaddr)
fhcreatesourcerecord( apiaddr, lat, long) *****(I think it should be fileaddr, not apiaddr to work correctly, because you are stripping out nothings, and will continue to do so without harm to the api or your code, its just a matter of what you plug into your source and what you keep to check for changes, isn't it?)
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

OK, I understand now. Let me have a look for the best solution.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

Originally a long time ago the Plugin tidied all Address and Place names in all contexts.
It had to partly undo that to allow Place records added in FH V6 to match correctly.
I kept tidy Address text as it looks generally neater in Source record Titles, etc, etc.
It would be difficult to change that now as it would upset any existing users who have Source records for Addresses.

To synchronise Address field text with Source record Titles use fhCallBuiltInFunction with TextPart function.
e.g.
tidyAddr = fhCallBuiltInFunction( "TextPart", tblsrc[ADDR], 1, 0, "TIDY" )

Then tidyAddr should match the Source record Title.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Ron Melby
Megastar
Posts: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts questions.

Post by Ron Melby »

ok, how do I read these?

set pointer to '_PLAC'
while PLAC not null.
get text from pointer (PLAC, '~MAP.LATI)


it doesnt work

0 @P1@ _PLAC Salem, , Essex, MA, USA
1 MAP
2 LATI N42.51954
2 LONG W70.8967155
1 CHAN
2 DATE 11 AUG 2019
3 TIME 19:40:39
0 @P2@ _PLAC Preston, , New London, CT, USA
1 MAP
2 LATI N41.5224785
2 LONG W72.0112598
1 CHAN
2 DATE 11 AUG 2019
3 TIME 19:39:23
0 @P3@ _PLAC , , , VT, USA
1 MAP
2 LATI N44.5588028
2 LONG W72.5778415
1 CHAN
2 DATE 11 AUG 2019
3 TIME 19:43:24
0 @P4@ _PLAC Pepin, , Pepin, WI, USA
1 MAP
2 LATI N44.4410785
2 LONG W92.14795
1 CHAN
2 DATE 11 AUG 2019
3 TIME 19:38:37
FH V.6.2.7 Win 10 64 bit
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts questions.

Post by tatewise »

Yes, there is a trick to that.
Plugin data refs for Lat/Long do not use the GEDCOM tag structure, but the pseudo LATLONG tag.

Code: Select all

ptrPLAC = fhNewItemPtr()
ptrPLAC:MoveToFirstRecord( '_PLAC' )
while not ptrPLAC:IsNull() do
	local strLatLong = fhGetItemText( ptrPLAC, '~.LATLONG' )
	local strDMS     = fhGetItemText( ptrPLAC, '~.LATLONG:DMS' )
	local strDEGREES = fhGetItemText( ptrPLAC, '~.LATLONG:DEGREES' )
	local strNUMERIC = fhGetItemText( ptrPLAC, '~.LATLONG:NUMERIC' )
	ptrPLAC:MoveNext()
end
The default format of the returned value is:
51°4'7.63"N, 1°47'40.1"W
But that is governed by the Tools > Preferences > General > Latitude & Longitude Format setting.

Also there are several qualifiers that offer other formats.
e.g.
:DMS is 51°4'7.63"N, 1°47'40.1"W
:DEGREES is 51.068785N, 1.794472W
:NUMERIC is 51.068785, -1.794472

There are variants of those formats that allow just the Latitude or just the Longitude to be returned.
e.g.
:LAT_DEGREES or :LONG_NUMERIC
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
Post Reply