* 'Export Gedcom File' to TNG and geocoded PLACes

[B0b]

Hi, I am using FH as my master database for my Cumberbatch One-Name Study. I use it to manage all of my data. I use TNG to share what I have online but I do not use it for editing the data uploaded.

FH6 now supports geocoding of places and I'd like to be able to manage and upload the geocodes in FH to my TNG site so that I can share maps of places.

TNG does not recognise the places in files exported by FH. I tried the 'Export Gedcom File' plugin and had an email with Darrin, the writer of TNG. He is happy to change the TNG import utility if the 'Export Gedcom File' can change the way PLACes are represented. He suggests:

"I think the problem is that the first line is not what TNG is expecting for a Place. You have this:
0 @P1@ _PLAC Pott Shrigley, Cheshire, England

but TNG is expecting this:
0 _PLAC Pott Shrigley, Cheshire, England

There really isn't a standard for place records, but if FH wants to use a place ID, they should probably represent it something like this:
0 @P1@ _PLAC
1 _PLAC Pott Shrigley, Cheshire, England

I could easily tweak the TNG code to handle that..."

Would it be possible to export the places as suggested above?

Finally, co-ordinates seem to be stored by FH as, for example:
1 MAP
2 LATI N53.32105
2 LONG W2.07664

FH does not seem to provide an option to change this stored coordinate format. I do not know if this is an issue for TNG, but I know that +/- to represent N-E/S-W definitely works. So, for Gedcom lines containing LATI and LONG an 'N' or 'E' can be deleted and 'S' and 'W' can be replaced by '-'. This would be for the case IF TNG does not recognise the N,E,S,W prefix on coordinates or there is no way in FH to change how coordinates are stored in the Gedcom file.

[I will check with Darrin if N/E/S/W will be imported and recognised as coordinate prefixes.]

An alternative might be to strip the PLAC id for the TNG upload, so remove @Pnnnn@ but I do not know my Gedcom well enough to be sure this is compliant or if it might break something else.

many thanks Bob

[tatewise]

I am happy to make those changes Bob, when you have an answer from Darrin regarding Lat/Longitude.

I prefer the 2nd Place Record format as it is more GEDCOM compliant, but different programs have so many non-compliant formats it does not really matter.

[NickWalker]

Yes in some ways the format used by Family Historian does look odd:

0 @P1@ _PLAC Pott Shrigley, Cheshire, England

But thinking about it, this is a similar to the format used for a standard GEDCOM note:

0 @N1@ NOTE This is a note

[B0b]

Hi Mike,

Here is what Darrin says:

If you can get FH to strip the @Pnnnn@ ID, that should work. I think the coordinates prefixed with the directional letters should work too.

I tried inputting the co-ordinates directly into TNG and they did NOT work with N/E/S/W prefixes, such as:
N53.32105
W2.07664

However,removing the 'N' and changing the 'W' to '-' works ok.
Latitude: 53.32105, Longitude: -2.07664

I believe that the conversion rule is N[orth] or E[ast] is positive and can simply be deleted; whereas W[est] or S[outh] need to be changed to a '-' [minus/negative].

Google maps shows one more character for the same place and I think the more digits means greater accuracy. 53.321050, -2.076640.

So someone with a handheld GPS device to geotag a place might have even more digits and feed them into FH. Here is a quote on accuracy:

If Latitude value is reported as -6.3572375290155 or -63.572375290155 then you could round-off and store up to 6 decimal places to be accurate to 10 cm. Likewise, same with longitude except longitudinal distance between whole degrees is constant around the globe.
If need mm accuracy then can represent lat/lon with 8 decimal places in decimal degrees format, but since most applications don't need that level of precision 6 places is sufficient for most.

It seems some places have 5 decimal places and others six and this is how they seem to be stored in FH.

Many thanks Bob

[Valkrider]

Bob

One thing you may want to feedback to Darren is that FH is formatting the Lat and Long in the gedcom as per the 5.5.1 (and possibly the 5.5 I don't have a copy of it to hand) standard which is with the NSEW letters, he may want to look at updating his programme to be compliant?

PLACE_LATITUDE:= {Size=5:8}
The value specifying the latitudinal coordinate of the place name. The latitude coordinate is the
direction North or South from the equator in degrees and fraction of degrees carried out to give the
desired accuracy. For example: 18 degrees, 9 minutes, and 3.4 seconds North would be formatted as
N18.150944. Minutes and seconds are converted by dividing the minutes value by 60 and the seconds
value by 3600 and adding the results together. This sum becomes the fractional part of the degree’s
value.

[B0b]

Darrin has corrected me:

You can't enter them directly into TNG like that [using prefixes], but you can import them (TNG just translates). If you enter them directly, use the negative signs.

Thanks Colin.

So there is no need to alter the format of the co-ordinates. Just removing the @Pnnnn@ should do the trick. Currently I use the standard Export Gedcom option in FamilyHistorian.

[tatewise]

I should be able to come up with a modified Export Gedcom File Plugin for the TNG style Place records within a few days.

However, I would much rather retain the Record Id, as was suggested earlier, as it is more GEDCOM compliant, like this:
0 @P1@ _PLAC
1 _PLAC Pott Shrigley, Cheshire, England

[tatewise]

While we are reviewing Place records for TNG can you please check with Darrin how all the other tags are handled, and whether any should be removed.

Example of full Place record tag structure:

0 @P69@ _PLAC Santiago, Chilie
1 STAN Standardized
1 MAP
2 LATI S33.4111595
2 LONG W70.6280861
1 STAT tentative or no geocode status
1 OBJE @O34@
2 _ASID 2
1 NOTE Note 1 text
2 CONT continuation
2 CONC concatenation
1 NOTE Note 2 text
1 CHAN
2 DATE 13 DEC 2014
3 TIME 15:35:54
2 NOTE @N1@
3 SOUR @S20@
2 NOTE Last Change Notes
3 SOUR @S2@

I plan to change the first line to:

0 @P69@ _PLAC
1 _PLAC Santiago, Chilie

The OBJE link will be handled by the Multimedia conversion rules:

1 OBJE @O34@
2 _ASID 2

but what else needs changing, if anything?

[B0b]

Hi Mike,

Thank you very much indeed. I will ask Darrin and let you know.

[B0b]

Hi Mike, Darrin would prefer you to remove/delete the @Pnnnn@ and here are his comments.

..he *should* strip out the @P69@ (see below [above]). What you've got here should still work though. I should mention, however, that TNG might not be able to handle multiple notes attached to a place (it might just take the last one), and it cannot handle notes attached to the change date (much less source citations attached to notes on the change date), so that much won't work either.

[tatewise]

OK, looks like all I really need to do is remove the @P9999@ record id.

The multiple Notes, and Change Notes are very rarely used by anyone, so I won't do anything about them.

If say the STAN or STAT need removing later on then that would be easy.

[B0b]

Hi Mike,

I just did a test successful test. I manually edited FH6 Gedcom export output from:

0 @P2696@ _PLAC 1 Abbey Terrace, Northampton, Northamptonshire, England
1 STAN 52°14'21.47"N, 0°54'57.55"W
1 MAP
2 LATI N52.2392977
2 LONG W0.9159849
1 NOTE Thought to be in the St James, Dallington area of Northampton. Abbey Street is nearby. Manually setup.
1 CHAN
2 DATE 13 DEC 2014
3 TIME 18:23:46

to

0 _PLAC 1 Abbey Terrace, Northampton, Northamptonshire, England
1 STAN 52°14'21.47"N, 0°54'57.55"W
1 MAP
2 LATI N52.2392977
2 LONG W0.9159849
1 NOTE Thought to be in the St James, Dallington area of Northampton. Abbey Street is nearby. Manually setup.
1 CHAN
2 DATE 13 DEC 2014
3 TIME 18:23:46

This imported the place, imported and converted the coordinates, with prefixes, and successfully mapped this location.

So just dropping the @Pnnnn@ would do the trick for what I need.

thanks bob

[tatewise]

OK, that's quite straightforward, so try the attached Plugin V1.7 and see if works for you.

[B0b]

Hi Mike,

This seems to do the trick of removing the @Pnnnn@. Thank you very much for doing this so quickly. I have only looked at the contents of a Gedcom Export and not performed a full import to TNG. Over the next few days I will try a complete upload of everything and I'll let you know how it goes.

Basic Options

Setting for Basic Options.
My site uses UTF-8
Chose RFILE: "Relative links also keep Multimedia records, and is the default for Family Historian 5 export mode"

Gedcom Export File Plugin - Basic Options ver 1.7.png (59.76 KiB) Viewed 9899 times

Extra Options

Note the 'Delete Record Ident (TNG)' selected under 'Place Record 0 @P%d+@'

Gedcom Export File Plugin - Extra Options ver 1.7.png (68.1 KiB) Viewed 9899 times

[B0b]

Hi Mike,

Thank you so very much indeed. I used the plug-in configured as above and completely replaced every entry in my TNG database. The result was a fabulous success.

For other TNG users: Here are my import stats:
Without the plugin [no location co-ordinates are loaded]

• People: 9251
  Families: 2865
  Sources: 8173
  Notes: 12318
  Media: 9222
  Places: 3720

With the plugin [location co-ordinates are loaded]

• People: 9251
  Families: 2865
  Sources: 8173
  Notes: 16069 [some records are created by the export]
  Media: 9222
  Places: 7470[?? Not sure what this count represents. TNG shows 3738 Places]

I made sure that FH had geocoded each location and made some corrections. I now must start the task of checking each entry.

Thank you very much, Bob

[tatewise]

That all looks very good.

How does the TNG Places statistic relate to the FH Places statistic (look at File > Statistics or the largest Place Record Id)?

Presumably TNG is counting every Note whether a local Note part of a record, or a separate Note Record?

[B0b]

Hi Mike,

Here are the FH counts:

Record Counts...
Individual Records:9251
Family Records: 2865
Note Records: 573
Source Records: 8173
Repository Records: 73
Submitter Records: 1
Submission Records: 0
Media Records: 4660
Place Records: 3751

[tatewise]

Looks like TNG is not counting consistent data types.
The first 3 look like Record counts for Individuals, Families & Sources.
The rest look like field or link counts, which are much greater than the number of Records.