Family Historian User Group

Hi,

Importing from FTM 2017 I get a lot of UDFs as shown in the attached screenshot.
I think that these are redundant and can be deleted. Does anyone see a problem with that?

I expect to use Geo-coding from FH MAP ALL PLACES or the plugin MAP LIFE FACTS ( may be both). I need to workout what to put in the PLACE, ADDRESS and STANDARDISED PLACE fields first.

I'm thinking for CENSUS and BMD facts PLACE should be the registration district (don't think I need to go to sub-district level. Standardised PLACE as a modern equivalent and Address would be as in the source.

However am open to advice and thoughts on this, as I'm still planning the import from FTM 2017 t oFH 6.2.5

Regards

David

A similar question arose with FH TMG Direct import issues following V6.0.1 (12162).
I wrote a one-off Plugin to move the Lat/Long values into the Place records.
The format in FTM 2017 is actually easier as it follows the GEDCOM Draft 5.5.1 standard like FH.
The difference is that FH uses non-standard Place records.
The Plugin could easily be adapted for the FTM 2017 format if you wish, rather than rely on FH Map geocoder.

Regarding Place names, in many cases you should aim to do better than Registration District that may have little to do with the actual Census or BMD place. If you only have a BMD Index entry then there is little choice, but BMD Certificates will give the actual place. The Registration District should be identified as such, see Event District/Place - What to enter? (15357) and GRO Birth Indexes and how to Cite against Birth Fact (15212).

Hi Mike,

Thank you.

Is that the Copy LatLong in Name to LatLong plugin.?
I gave that a try, but it had no effect on my FTM 2017 Gedcom; unsurprising as it probably wasn't designed for that task.

If the FTM geocoding can be preserved then I would certainly make use of an adapted plugin and would be very grateful for that. (I'm avoiding polishing up my coding skills at the moment, LUA looks very much like object orientated C/C++ coding I used to do a while back - I'll get entirely distracted if I start on that).

I've have a look at the suggestions regarding PLACE names and am going take that advice on board.

Regards

David

You are correct, that Plugin was not designed for this particular task.

Try the attached Move LatLong from Place field to Place record Plugin Version 0.1 Date 10 Dec 2017.

As usual beforehand use File > Backup/Restore > Small Backup just in case!

The Plugin finds those ...PLAC.MAP.LATI/LONG values, copies them to the Place record, and deletes original UDF.

Afterwards, check Result Set and if not OK then use Edit > Undo Plugin Updates before closing FH

Hey, thank you so much.

Just want to say thanks from me too. As the project manager for the RUBY One-Name Study, I'm needing to import quite a few files produced by FTM, many of which have been geo-coded, and this has answered my prayers!
Paul