* Map Life Facts

Writing and using plugins for Version 5 and above.
avatar
Denis
Gold
Posts: 13
Joined: 06 Sep 2014 13:54
Family Historian: V7
Location: Co. Cork, Ireland

Map Life Facts

Post by Denis » 17 Dec 2020 12:23

Hi Mike

Thanks for all the work you and others put into the plug-ins. I've installed the new version of Map Life Facts, but unfortunately get the following error when trying to run it:
Screenshot 2020-12-17 121412.jpg
Screenshot 2020-12-17 121412.jpg (16.52 KiB) Viewed 867 times
I gather I've run into this because of not having a Google Maps API key recorded (I peeked into your code at line 6943), so you might not have come up against this yourself.

Thanks,
Denis

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 17 Dec 2020 12:38

Sorry, that is my mistake and will be fixed ASAP.
It is due to the change from using Knowledge Base Help files to Plugin Store Help files and I have not caught all the cases. :oops:
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

avatar
Denis
Gold
Posts: 13
Joined: 06 Sep 2014 13:54
Family Historian: V7
Location: Co. Cork, Ireland

Re: Map Life Facts

Post by Denis » 17 Dec 2020 12:58

Shows that you're dedicated and hard-working, rather than merely superhuman! :lol:

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 17 Dec 2020 13:39

The revised plugin is awaiting approval in the Plugin Store and should reappear before too long.
[ Edit: Version 4.8 is now approved. ]
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 13 Feb 2021 16:37

I didn't want to start a new thread, trying to keep the issues with each plugin sort of together, figuring that the big plugin authors out here are inundated enough. However if this should be broken off please do so. And accept my apology in advance.

Situation:
1) FH 6.7.2

2) MLF =
@Title: Map Life Facts
@Type: Standard
@Author: Mike Tate
@Contributors:
@Version: 4.8
@Keywords:
@LastUpdated: 17 Dec 2020

3) Addresses are in source records
4) I have not created any new sources otherwise.

when I update new addresses, it updates those, and keeps updating many addresses that are already in source records.

lets say I create 5 new addresses, save my work and then MLF
it will say there is 78 addresses not on file.
2 I notice that keep repeating are
Williamstown Cemetery in AUS (but I check before update in the loc file and it has the GPS) and after update same GPS
Golders Green London is another same situation.
prior to update of MLF it never did this. Whether or not it worked correctly prior is unknown. And I am unsure if it is working correctly now. For instance, if the linked list is having to insert in the middle of the same old addresses in source every time, which is undoubtful given the regularity.

If I run it. close it, reopen it same session, the not found is 0
if I run it, close it, get out of fh, restart, the not found is 0
if I add one address it goes to 78 not found (and these are old old addresses that have been there and geocoded for a long time.
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 13 Feb 2021 23:25

Ron, what are the settings on the Set Preferences Options tab, Location Plot Options tab?
Without those, I have no idea what locations are being plotted.

What do you mean by "78 addresses not found"?
Are you talking about the Geocode Location Plots tab Statistics?
If so, then tell me exactly what all the Statistics numbers are.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 15 Feb 2021 13:11

More information, first, it appears that a close of the fh and reopen of the program is involved.

that is, if I run MLF and stay in FH and add a few addresses, and rerun MLF in the same session it appears to work correctly.

The number is now up to 86 non plots and that is about the new difference of new addresses I entered yesterday from the 78 I quoted at first.

I have three screens to show dont know if I can do it in one post.
this is an error stack that is in the background (it is eaten, and does not blow up the program)
eaten.png
eaten.png (23.56 KiB) Viewed 579 times
these are my settings (as stated originally it only happens to addresses, not to places)

plot.png
plot.png (82.8 KiB) Viewed 579 times
setting.png
setting.png (225.48 KiB) Viewed 579 times
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 15 Feb 2021 20:56

Thank you for the screenshots Ron. I am investigating the issues.

When does the plugin produce the Error Message?
That sort of error is fatal and the plugin cannot continue and must be aborted.
So, I am not sure what you mean by "it is eaten, and does not blow up the program".
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 15 Feb 2021 23:32

on first entry into fh and immediate entry into MLF with no intervening activities, and I have only done that once, and that was while getting you screens, I took the first alt prtsc of the 86 not plotted, tapped on the screen to show you I was selecting address gps to source records and that screen came up. I took a picture, clicked ok, and it took me to the address to sources screen (so that is what I mean by it didnt blow up) I then exited the plugin. using the upper right hand x.

I wasnt going to run it at that point. obviously error of some kind, and since the changes are not 'sticking' I am awaiting a fix.

they hold in session and I receive no other errors, then I exit fh and they are gone. since the update all for 86 records runs quickly, I cannot see all the records it updates, but the once I can see across the screen are familiar, from way way back when we were talking about Glenwood Cemetery, and correcting addresses, and I looked in the loc file, and they are already there. The only change I have made is to update my stuff against the store, and of course the problem has been occurring since that time. MLF is really the only plugin I use with regularity, because I have programs that run against the info in the source and place records.
FH V.6.2.7 Win 10 64 bit

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 16 Feb 2021 12:21

mike additional info. dont know why I never checked this before. I am extremely slow to thought these days.
I add to your fields on the source records after, but do not create or otherwise mess with your files, or source records.
browsing facts address type source records, there are some with two entries, and some with more, and a great deal of the over 1000 entries just one. Here is a singleton:

Map Life Facts Address Location
Substitute =
Latitude = 32.2002948
Longitude = -84.1303207
Plot Mode =
Region = USA
DriveTime = 77575
Distance = 1444.6743698336
Track = 144.13372779256
Dir = SEbS
Route = SE+

Now, it may be that you have a different method of deciding records to add, or change than I do.
however, here is how I decide to add and its rather simplistic:

ptrSOUR:MoveToFirstRecord('SOUR')
while ptrSOUR:IsNotNull() do
local TYPE = fhGetItemText(ptrSOUR, '~._TYPE') or ' '
if TYPE == 'Facts Address' then
ADR = fhGetItemText(ptrSOUR, '~.TITL')
srcID = fhGetRecordId(ptrSOUR)

ptrNOTE = fhGetItemPtr(ptrSOUR, '~.NOTE2') or ' '
LAT = tonumber((fhGetLabelledText(ptrNOTE, 'Latitude ='))) or ''
LNG = tonumber((fhGetLabelledText(ptrNOTE, 'Longitude ='))) or ''
--StrPlotLatLong = "%-?[0-9]+[%.,]-[0-9]-" tonumber?
RGN = fhGetLabelledText(ptrNOTE, 'Region =')
TIM = tonumber((fhGetLabelledText(ptrNOTE, 'DriveTime ='))) or ''
DST = tonumber((fhGetLabelledText(ptrNOTE, 'Distance ='))) or ''
TRK = tonumber((fhGetLabelledText(ptrNOTE, 'Track ='))) or ''
DIR = fhGetLabelledText(ptrNOTE, 'Dir =')
RTE = fhGetLabelledText(ptrNOTE, 'Route =')

if RGN == ''
or TIM == ''
or DST == ''
or TRK == ''
or DIR == ''
or RTE == '' then
local agps =
{
srcID = srcID,
LAT = LAT,
LNG = LNG
}
updADR(agps)
end
RGN = fhGetLabelledText(ptrNOTE, 'Region =')
TIM = tonumber((fhGetLabelledText(ptrNOTE, 'DriveTime ='))) or ''
DST = tonumber((fhGetLabelledText(ptrNOTE, 'Distance ='))) or ''
TRK = tonumber((fhGetLabelledText(ptrNOTE, 'Track ='))) or ''
DIR = fhGetLabelledText(ptrNOTE, 'Dir =')
RTE = fhGetLabelledText(ptrNOTE, 'Route =')
end

tbladr[ADR] =
{
LOC = '',
LAT = LAT,
LNG = LNG,
RGN = RGN,
srcID = srcID,
TIM = TIM,
DST = DST,
TRK = TRK,
DIR = DIR,
RTE = RTE
}
ptrSOUR:MoveNext('SAME_TAG')
end
return
end

local function updADR(agps)

local ptrSOUR = fhNewItemPtr()
local ptrNOTE = fhNewItemPtr()

ptrSOUR:MoveToRecordById('SOUR', agps.srcID)
LOC = fhGetItemText(ptrSOUR, '~.TITL')
ptrNOTE = fhGetItemPtr(ptrSOUR, '~.NOTE2')

RGN = matREGION(LOC)
fhSetLabelledText(ptrNOTE, 'Region =', RGN)

TIM, DST = matDISTANCE(__blati, __blong, agps.LAT, agps.LNG)
if DST == '' then
TIM = ''
DST = matHAVERSINE(__blati, __blong, agps.LAT, agps.LNG)
end
fhSetLabelledText(ptrNOTE, 'DriveTime =', TIM)
fhSetLabelledText(ptrNOTE, 'Distance =', DST)

TRK = matBEARING(__blati, __blong, agps.LAT, agps.LNG)
fhSetLabelledText(ptrNOTE, 'Track =', TRK)

DIR, RTE = matAZIMUTH(TRK)
fhSetLabelledText(ptrNOTE, 'Dir =', DIR)
fhSetLabelledText(ptrNOTE, 'Route =', RTE)
return agps
end

local ptrSOUR = fhNewItemPtr()
local ptrNOTE = fhNewItemPtr()

ptrSOUR:MoveToFirstRecord('SOUR')
while ptrSOUR:IsNotNull() do
local TYPE = fhGetItemText(ptrSOUR, '~._TYPE') or ' '
if TYPE == 'Facts Address' then
ADR = fhGetItemText(ptrSOUR, '~.TITL')
srcID = fhGetRecordId(ptrSOUR)

ptrNOTE = fhGetItemPtr(ptrSOUR, '~.NOTE2') or ' '
LAT = tonumber((fhGetLabelledText(ptrNOTE, 'Latitude ='))) or ''
LNG = tonumber((fhGetLabelledText(ptrNOTE, 'Longitude ='))) or ''
--StrPlotLatLong = "%-?[0-9]+[%.,]-[0-9]-" tonumber?
RGN = fhGetLabelledText(ptrNOTE, 'Region =')
TIM = tonumber((fhGetLabelledText(ptrNOTE, 'DriveTime ='))) or ''
DST = tonumber((fhGetLabelledText(ptrNOTE, 'Distance ='))) or ''
TRK = tonumber((fhGetLabelledText(ptrNOTE, 'Track ='))) or ''
DIR = fhGetLabelledText(ptrNOTE, 'Dir =')
RTE = fhGetLabelledText(ptrNOTE, 'Route =')

if RGN == ''
or TIM == ''
or DST == ''
or TRK == ''
or DIR == ''
or RTE == '' then
local agps =
{
srcID = srcID,
LAT = LAT,
LNG = LNG
}
updADR(agps)
end
RGN = fhGetLabelledText(ptrNOTE, 'Region =')
TIM = tonumber((fhGetLabelledText(ptrNOTE, 'DriveTime ='))) or ''
DST = tonumber((fhGetLabelledText(ptrNOTE, 'Distance ='))) or ''
TRK = tonumber((fhGetLabelledText(ptrNOTE, 'Track ='))) or ''
DIR = fhGetLabelledText(ptrNOTE, 'Dir =')
RTE = fhGetLabelledText(ptrNOTE, 'Route =')
end

tbladr[ADR] =
{
LOC = '',
LAT = LAT,
LNG = LNG,
RGN = RGN,
srcID = srcID,
TIM = TIM,
DST = DST,
TRK = TRK,
DIR = DIR,
RTE = RTE
}
ptrSOUR:MoveNext('SAME_TAG')
end
return
end

However, I do not create source address records that do not exist. That is all I do, if I run across one that doesnt have my information in it, I update that information from yours already in the record. Now, part of the issue for me is that if my info is not there, I mindlessly update not checking if yours is there. One of the issues being that I may not have run MLF when I have new address records, that uses my _STD_GPS require, but the resultant output has indications that I need to run MLF, and it has never before done this multiple record thing, it has always worked. But that is my problem. I suppose I could wipe out ALL facts address records, and rerun map life facts and see if it

At one time, this Golders Green record was filled out. And like Sean Connery in the Highlander, there can be only one. (and there was only one). Dont know if this additional information helps track down the issue, nevertheless...
GoldersGreen.png
GoldersGreen.png (82.75 KiB) Viewed 484 times

this is the record from the loc file
["Golders Green, London, London, GBR ~ London, , London, EN, GBR"]={2347},

-- Table: {2347}
{
["sub"]="",
["lng"]=-0.198171,
["lat"]=51.575666,
["mod"]="",
},

it is unique, and there are no variations of that record (ie, some other form of Golders Green) such as Golder's Green, or anything keyed with Gol*
there are 7 Golders Green facts address source records, each a little different text information, from blank to filled out with no information in the fields.
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 16 Feb 2021 13:22

I think you have solved your own problem.
The Plugin is set with Database in: Source Records so the Source records hold the location data and NOT the loc file.
Those Source records are the Plugin locations database so their structure must not be disrupted.

If those Source records are upset in any way so they do not hold the labelled text for at least:

Map Life Facts Address Location
Substitute =
Latitude =
Longitude =
Plot Mode =

then my Plugin will create a new Source record for any such Address and classify it as No Data.

So your plugin script must take greater care not to disrupt those Source records and labels.
If your script creates new Source records for new Addresses they must include those labels even if left blank.
Otherwise, my Plugin will ignore your Source records and create its own.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 16 Feb 2021 13:29

As I stated outright, I create NO source records, Mike.
It must exist before I do anything with it.

Problem is not solved.
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 16 Feb 2021 13:53

Your screenshot shows something is creating lots of Source records for Golders Green, 62 Hoop Lane, London, EN, GBR
Many of them have no Note at all and only one seems to have a Map Life Facts database compatible Note starting with:
Map Life Facts Address Location
Substitute =
Latitude =
Longitude =
Plot Mode =

Several of them have a Note starting with your labels Region = DriveTime = etc...

Have you any explanation for so many Source records with the same Title but no Map Life Facts labelled Notes?
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 16 Feb 2021 15:11

yeah, FHUG timed out in my answering post. much work in the bit bucket.

somehow, you are creating the blank records, I do not create them.

rather than run thru my proof again, and risk the timeout....

run me thru how to delete all facts address records, if its your plugin, the quickest way, your plugin or a named list?
I will run MLF from scratch, and do my normal thing, and take some snapshots along the way.

I have just retrieved a memory from my cobwebs, just a maybe...
what are you going to do if my API Key is valid, but you get back the license needs renewing (whatever it actually says) message, and would that trip you up and still create source records without fields?
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 16 Feb 2021 15:45

The easiest way to delete any records in bulk is to select them, add them to a Named List and use the Delete Listed Records option.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 16 Feb 2021 15:50

already did that, and am now adding source records thru MLF. I will let you know what occurs in the next steps.
FH V.6.2.7 Win 10 64 bit

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 16 Feb 2021 19:24

it was me, in a piece of code that made all sorts of unexpected results, and has worked and was debugged long ago.
My 'umble apologies for doubting you, Guv.

local function updADR(agps)

local ptrSOUR = fhNewItemPtr()
local ptrNOTE = fhNewItemPtr()

ptrSOUR:MoveToRecordById('SOUR', agps.srcID)
LOC = fhGetItemText(ptrSOUR, '~.TITL')
ptrNOTE = fhGetItemPtr(ptrSOUR, '~.NOTE2')

RGN = matREGION(LOC)
fhSetLabelledText(ptrNOTE, 'Region =', RGN)

TIM, DST = matDISTANCE(__blati, __blong, agps.LAT, agps.LNG)
if DST == '' then
TIM = ''
DST = matHAVERSINE(__blati, __blong, agps.LAT, agps.LNG)
end
fhSetLabelledText(ptrNOTE, 'DriveTime =', TIM)
fhSetLabelledText(ptrNOTE, 'Distance =', DST)

TRK = matBEARING(__blati, __blong, agps.LAT, agps.LNG)
fhSetLabelledText(ptrNOTE, 'Track =', TRK)

DIR, RTE = matAZIMUTH(TRK) <<<< I will post about this in a separate thread.
fhSetLabelledText(ptrNOTE, 'Dir =', DIR) <<<< if Dir is nil, it nils the entire note2.
fhSetLabelledText(ptrNOTE, 'Route =', RTE) <<<< as a consequence, this is also nil and nils the entire note2.
return agps
end
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 16 Feb 2021 20:09

No problem. My investigation has revealed a change/bug with the GetLabelledText function in FH V7.
I've reported it to CP and will wait for the outcome. If I had not investigated FH V7 users would have had a problem.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 16 Feb 2021 23:47

well well.

then bills in the mail.

Thank you for your help Mike.

I still cant figure out why it quit working cuz that has been the code since the update just before 6.7.2 in my files, and I had to take the locals out so I had a default definition for those fields.

if you looked at it, I just grab any number in my file that is less than or equal to the azimuth I calculated subracting the address location from my location and keep filling the same fields from the table until it is less or equal to my azimuth, because my azimuths do not equal the fields in the table (very rarely do) so it is within like 4 degrees of my entry,98 entries divided into 360 and if i read one greater than, I boogie out and you are left with my last less than or equal to, that is 358 and some odd is close enough to pure N its going to return N. I have 32 major compass points divided into lets call it each point is N-, N, N+ for that number, so I cant do a lookup because calculating the point to a compass point every time is horrid nasty maths, and there is no getnearestnumber( '<=', Number ) really. I dont know a quicker way to do it than stepwise to failure, you got any whiz stuff thats fast?
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 17 Feb 2021 10:22

The Lua math library function math.floor(x) will "return the largest integral value smaller than or equal to x".
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 17 Feb 2021 11:55

right, I thought about it, but it doesnt save me any comparisons or anything I can see

for k v in ipairs do
is the only way I know to read a table,

I dont think I can do
DIR = routes.POINT[math.floor(azim)]

on the side, could you do a favor quick in v7?

make a throw away source record
fhsetlabelledtext some fields to note2
fhsetlabelledtext a nil field field at the end
does it wipe out the entire note 2 or are the other fields still there
because I think that is not correct behavior under 6.7.2 otherwise how do you get rid of that field if your structure changes, and if its the same in both versions I can report that, otherwise, I will just report under 6.7.2
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 17 Feb 2021 14:36

Why don't you think you can do: DIR = routes.POINT[math.floor(azim)]
That will read an entry in the routes.POINT array with integer index math.floor(azim)

So if azim is between 20.000 and 20.99999 then math.floor(azim) is 20 and will read routes.POINT[20]

I don't understand what you mean by "fhsetlabelledtext a nil field field at the end"
Please give an actual example of plugin script.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 17 Feb 2021 15:15

Code: Select all

routes =
{
 [1] = { POINT=  0.0000, DIR_32="N   ", WAY="N  ", },
 [2] = { POINT=  5.6250, DIR_32="N   ", WAY="N  ", },
 [3] = { POINT=  5.6251, DIR_32="NbE ", WAY="N+ ", },
 [4] = { POINT= 11.2500, DIR_32="NbE ", WAY="N+ ", },
 [5] = { POINT= 16.8749, DIR_32="NE  ", WAY="N+ ", },
 [6] = { POINT= 16.8750, DIR_32="NNE ", WAY="NNE", },
 [7] = { POINT= 22.5000, DIR_32="NNE ", WAY="NNE", },
 [8] = { POINT= 28.1250, DIR_32="NNE ", WAY="NNE", },
 [9] = { POINT= 28.1251, DIR_32="NEbN", WAY="NE-", },
[10] = { POINT= 33.7500, DIR_32="NEbN", WAY="NE-", },
[11] = { POINT= 39.3749, DIR_32="NEbN", WAY="NE-", },
[12] = { POINT= 39.3750, DIR_32="NE  ", WAY="NE ", },
[13] = { POINT= 45.0000, DIR_32="NE  ", WAY="NE ", },
[14] = { POINT= 50.6250, DIR_32="NE ",  WAY="NE ", },
[15] = { POINT= 50.6251, DIR_32="NEbE", WAY="NE+", },
[16] = { POINT= 56.2500, DIR_32="NEbE", WAY="NE+", },
[17] = { POINT= 61.8749, DIR_32="NEbE", WAY="NE+", },
[18] = { POINT= 61.8750, DIR_32="ENE ", WAY="ENE", },
[19] = { POINT= 67.5000, DIR_32="ENE ", WAY="ENE", },
[20] = { POINT= 73.1250, DIR_32="ENE ", WAY="ENE", },
[21] = { POINT= 73.1251, DIR_32="EbN ", WAY="E- ", },
[22] = { POINT= 78.7500, DIR_32="EbN ", WAY="E- ", },
[23] = { POINT= 84.3749, DIR_32="EbN ", WAY="E- ", },
[24] = { POINT= 84.3750, DIR_32="E   ", WAY="E  ", },
[25] = { POINT= 90.0000, DIR_32="E   ", WAY="E  ", },
[26] = { POINT= 95.6250, DIR_32="E   ", WAY="E  ", },
[27] = { POINT= 95.6251, DIR_32="EbS ", WAY="E+ ", },
[28] = { POINT=101.2500, DIR_32="EbS ", WAY="E+ ", },
[29] = { POINT=106.8749, DIR_32="EbS ", WAY="E+ ", },
[30] = { POINT=106.8750, DIR_32="ESE ", WAY="ESE", },
[31] = { POINT=112.5000, DIR_32="ESE ", WAY="ESE", },
[32] = { POINT=118.1250, DIR_32="ESE ", WAY="ESE", },
[33] = { POINT=118.1251, DIR_32="SEbE", WAY="SE-", },
[34] = { POINT=123.7500, DIR_32="SEbE", WAY="SE-", },
[35] = { POINT=129.3749, DIR_32="SEbE", WAY="SE-", },
[36] = { POINT=129.3750, DIR_32="SE  ", WAY="SE ", },
[37] = { POINT=135.0000, DIR_32="SE  ", WAY="SE ", },
[38] = { POINT=140.6250, DIR_32="SE  ", WAY="SE ", },
[39] = { POINT=140.6251, DIR_32="SEbS", WAY="SE+", },
[40] = { POINT=146.2500, DIR_32="SEbS", WAY="SE+", },
[41] = { POINT=151.8749, DIR_32="SEbS", WAY="SE+", },
[42] = { POINT=151.8750, DIR_32="SSE ", WAY="SSE", },
[43] = { POINT=157.5000, DIR_32="SSE ", WAY="SSE", },
[44] = { POINT=163.1250, DIR_32="SSE ", WAY="SSE", },
[45] = { POINT=163.1251, DIR_32="SbE ", WAY="S- ", },
[46] = { POINT=168.7500, DIR_32="SbE ", WAY="S- ", },
[47] = { POINT=174.3749, DIR_32="SbE ", WAY="S- ", },
[48] = { POINT=174.3750, DIR_32="S   ", WAY="S  ", },
[49] = { POINT=180.0000, DIR_32="S   ", WAY="S  ", },
[50] = { POINT=185.6250, DIR_32="S   ", WAY="S  ", },
[51] = { POINT=185.6251, DIR_32="SbW ", WAY="S+ ", },
[52] = { POINT=191.2500, DIR_32="SbW ", WAY="S+ ", },
[53] = { POINT=196.8749, DIR_32="SbW ", WAY="S+ ", },
[54] = { POINT=196.8750, DIR_32="SSW ", WAY="SSW", },
[55] = { POINT=202.5000, DIR_32="SSW ", WAY="SSW", },
[56] = { POINT=208.1250, DIR_32="SSW ", WAY="SSW", },
[57] = { POINT=208.1251, DIR_32="SWbS", WAY="SW-", },
[58] = { POINT=213.7500, DIR_32="SWbS", WAY="SW-", },
[59] = { POINT=219.3749, DIR_32="SWbS", WAY="SW-", },
[60] = { POINT=219.3750, DIR_32="SW  ", WAY="SW ", },
[61] = { POINT=225.0000, DIR_32="SW  ", WAY="SW ", },
[62] = { POINT=230.6250, DIR_32="SW  ", WAY="SW ", },
[63] = { POINT=230.6251, DIR_32="SWbW", WAY="SW+", },
[64] = { POINT=236.2500, DIR_32="SWbW", WAY="SW+", },
[65] = { POINT=241.8749, DIR_32="SWbW", WAY="SW+", },
[66] = { POINT=241.8750, DIR_32="WSW ", WAY="WSW", },
[67] = { POINT=247.5000, DIR_32="WSW ", WAY="WSW", },
[68] = { POINT=253.1250, DIR_32="WSW ", WAY="WSW", },
[69] = { POINT=253.1251, DIR_32="WbS ", WAY="W- ", },
[70] = { POINT=258.7500, DIR_32="WbS ", WAY="W- ", },
[71] = { POINT=264.3749, DIR_32="WbS ", WAY="W- ", },
[72] = { POINT=264.3750, DIR_32="W   ", WAY="W  ", },
[73] = { POINT=270.0000, DIR_32="W   ", WAY="W  ", },
[74] = { POINT=275.6250, DIR_32="W   ", WAY="W  ", },
[75] = { POINT=275.6251, DIR_32="WbN ", WAY="W+ ", },
[76] = { POINT=281.2500, DIR_32="WbN ", WAY="W+ ", },
[77] = { POINT=286.8749, DIR_32="WbN ", WAY="W+ ", },
[78] = { POINT=286.8750, DIR_32="WNW ", WAY="WNW", },
[89] = { POINT=292.5000, DIR_32="WNW ", WAY="WNW", },
[80] = { POINT=298.1250, DIR_32="WNW ", WAY="WNW", },
[81] = { POINT=298.1251, DIR_32="NWbW", WAY="NW-", },
[82] = { POINT=303.7500, DIR_32="NWbW", WAY="NW-", },
[83] = { POINT=309.3749, DIR_32="NWbW", WAY="NW-", },
[84]1251 = { POINT=309.3750, DIR_32="NW  ", WAY="NW ", },
[85] = { POINT=315.0000, DIR_32="NW  ", WAY="NW ", },
[86] = { POINT=320.6250, DIR_32="NW  ", WAY="NW ", },
[87] = { POINT=320.6251, DIR_32="NWbN", WAY="NW+", },
[88] = { POINT=326.2500, DIR_32="NWbN", WAY="NW+", },
[99] = { POINT=331.8749, DIR_32="NWbN", WAY="NW+", },
[90] = { POINT=331.8750, DIR_32="NNW ", WAY="NNW", },
[91] = { POINT=337.5000, DIR_32="NNW ", WAY="NNW", },
[92] = { POINT=343.1250, DIR_32="NNW ", WAY="NNW", },
[93] = { POINT=343.1251, DIR_32="NbW ", WAY="N- ", },
[94] = { POINT=348.7500, DIR_32="NbW ", WAY="N- ", },
[95] = { POINT=354.3749, DIR_32="NbW ", WAY="N -", },
[96] = { POINT=354.3750, DIR_32="N   ", WAY="N  ", },
[97] = { POINT=360.0000, DIR_32="N   ", WAY="N  ", },
}
let azim = 347.6813
I need the entry [93] which is <= azim at present
of course it would be nice to see which is closer to my azim the entry a little less or equal, or the one just over, but that maths to do easily and without adding a great deal of processing is beyond me, but would be more accurate.
I can remove the ordinal index and make POINT the index, but know of no granular cursor function in LUA that will set a cursor at the area of the key that does not exist, (between [93] and [94]) and read prev and read next
so at the moment I look from 1 to n and repeatedly stuff my variable with the current read that is less than or equal to azim, until I hit entry [93] and when I look at [94] its not less than or equal to, so I get out with [93] entries left in my variable.

I have somehow done something in zerobrane and deleted a plugin file that I must have, so I am running a recovery to retrieve it. as soon as that gets done (it nearly kills my system) I will write you up a test plugin to demonstrate the unexpected nil on 6.7.2 and see if it will do it on 7. I have most of the code on this thread right now, and annotated where it happened, where DIR was nil, and it trashed note2 rather than adding nothing to note2.
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 20571
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Map Life Facts

Post by tatewise » 17 Feb 2021 16:11

Divide azim by 3.75 and round down to nearest integer and start the search there.
e.g.

Code: Select all

local azim = 347.6813
local index = 0
local start = math.floor( azim / 3.75 )
for j = start+1, #routes do
   if azim < routes[j].POINT then break end
   index = j
end
local point = routes[index].POINT
That works for me with a variety of test values for azim.

I suspect with a bit more thought the number of routes table entries could be reduced to a third.
i.e. one for each DIR_32 and WAY value
Then local index = math.floor( (azim / 11.25) + 0.5 ) + 1 should give the index.
e.g.

Code: Select all

local routes =
{
 [1] = { POINT=  0.0000, DIR_32="N   ", WAY="N  ", },
 [2] = { POINT= 11.2500, DIR_32="NbE ", WAY="N+ ", },
 [3] = { POINT= 22.5000, DIR_32="NNE ", WAY="NNE", },
 [4] = { POINT= 33.7500, DIR_32="NEbN", WAY="NE-", },
 [5] = { POINT= 45.0000, DIR_32="NE  ", WAY="NE ", },
 [6] = { POINT= 56.2500, DIR_32="NEbE", WAY="NE+", },
 [7] = { POINT= 67.5000, DIR_32="ENE ", WAY="ENE", },
 [8] = { POINT= 78.7500, DIR_32="EbN ", WAY="E- ", },
 [9] = { POINT= 90.0000, DIR_32="E   ", WAY="E  ", },
[10] = { POINT=101.2500, DIR_32="EbS ", WAY="E+ ", },
[11] = { POINT=112.5000, DIR_32="ESE ", WAY="ESE", },
[12] = { POINT=123.7500, DIR_32="SEbE", WAY="SE-", },
[13] = { POINT=135.0000, DIR_32="SE  ", WAY="SE ", },
[14] = { POINT=146.2500, DIR_32="SEbS", WAY="SE+", },
[15] = { POINT=157.5000, DIR_32="SSE ", WAY="SSE", },
[16] = { POINT=168.7500, DIR_32="SbE ", WAY="S- ", },
[17] = { POINT=180.0000, DIR_32="S   ", WAY="S  ", },
[18] = { POINT=191.2500, DIR_32="SbW ", WAY="S+ ", },
[19] = { POINT=202.5000, DIR_32="SSW ", WAY="SSW", },
[20] = { POINT=213.7500, DIR_32="SWbS", WAY="SW-", },
[21] = { POINT=225.0000, DIR_32="SW  ", WAY="SW ", },
[22] = { POINT=236.2500, DIR_32="SWbW", WAY="SW+", },
[23] = { POINT=247.5000, DIR_32="WSW ", WAY="WSW", },
[24] = { POINT=258.7500, DIR_32="WbS ", WAY="W- ", },
[25] = { POINT=270.0000, DIR_32="W   ", WAY="W  ", },
[26] = { POINT=281.2500, DIR_32="WbN ", WAY="W+ ", },
[27] = { POINT=292.5000, DIR_32="WNW ", WAY="WNW", },
[28] = { POINT=303.7500, DIR_32="NWbW", WAY="NW-", },
[29] = { POINT=315.0000, DIR_32="NW  ", WAY="NW ", },
[30] = { POINT=326.2500, DIR_32="NWbN", WAY="NW+", },
[31] = { POINT=337.5000, DIR_32="NNW ", WAY="NNW", },
[32] = { POINT=348.7500, DIR_32="NbW ", WAY="N- ", },
[33] = { POINT=360.0000, DIR_32="N   ", WAY="N  ", },
}
local azim = 347.6813
local index = math.floor( (azim / 11.25) + 0.5 ) + 1
local point = routeb[index].POINT
local dir32 = routeb[index].DIR_32
print(index,point,dir32)
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 678
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Map Life Facts

Post by Ron Melby » 17 Feb 2021 21:00

it may be that a strict 32 point compass is enough. that would be done by removing entries with a b contained in the DIR_32 field (thats why it is that name, I started with a 32 point compass, that would reduce it by 2/3rds

I hope the page you are looking at is what I intend. London Zoomed out enough so you can see Chelmsford top right.

Let us assume you live in London. cozyed up in a little shack that you bought and paid for that, for now can be next door to the Tower or Big Ben.

You have a week or so free time, and a great deal of your relatives are buried in cemeteries from about west of you to about north of you in various and sundry locations.

now consider that there is an algorithm K-means (or some other) that will cluster points together that are in some sense similar, and you have some way to pick cluster centers. (I have some code, but consider this the blackboard cartoon and some miracle occurs here with that bit) remember the first IUP you helped me with was IUP.plot.

Now, lets say you have cemeteries in Hayes, Slough, Maidenhead, brill... a route like that is easy and doesnt even require a computer.
But you have cemeteries in Hounslow and Wembley.
Oh, also in High Wycombe, Hemel Hempstead, St. Albans, and Hatfield.
all sorts of places in between but not in a straight line.
Choosing centers or routes can be weighted by deviation off a straight line, (and more accurate for more compass positions, without dividing into points 360/360/360 or some such foolishness for your granularity.
already we are beyond our week, and may have to split your routes into a logical petal graph.
petalgraph.png
petalgraph.png (27.49 KiB) Viewed 243 times
all centering on your location. and travel a petal, and save the next route for another time available, on a route you made that doesnt have you going thru Croyden. Of course the petal graph would be considerably more raggedy.

I am unsure if 32 points is enough to keep it reasonable, since the further you go from your center, the greater the arc of deviation will be. that is, it may be that Cambridge and Nottingham outbound trip because there wouldnt be as much granularity, might appear to be an efficient route. I don't know, I am not great at maths algorithms. OBVS.
Last edited by Ron Melby on 17 Feb 2021 21:19, edited 2 times in total.
FH V.6.2.7 Win 10 64 bit

Post Reply