* Rearrange Address and Place Parts Plugin

[jbtapscott]

I am getting a strange result when running the above.

By way of background, I am working towards using the new GenSite product for generation of my website - this is all going very well even though (as I expected) I need to make minor changes to my data in FH before using the Export Gedcom File. One area that I need to consider significant change (in FH data) is my use of Address and Place data as only the latter gets used in GedSite. As such, I decided to try (on a backup Project!), merging my address and place data.

Before running the Rearrange plugin, I extended the Columns on the Place records from five to eight (I have three columns in the Address records). I then used the plugin to right align the Place data - this worked fine. I then setup the plugin such that Input Column Part (in the lower segment of window) was set to Address 1, Output Column Part to Place 1, Address 2 to Place 2 and Address 3 to Place 3 - the remaining column parts stayed at their defaults (Place 4 to Place 4, etc). I did not touch the Address to Address column part entries in the upper segment of the window.

After running the plugin, I checked my data and found that things had worked as expected - the Address data was merged correctly to the relevant Place record, with new records created where I had multiple Addresses to link with a single Place (eg multiple Street names in Address records for a single Place). However, what I also found was some "code" had been added to the start of Column 1 in the Place records - this is shown on both the resulting RecordSet and the actual Place record:

"{AA0}, , , , , Highbridge, Somerset, England"
"{AA1}, , , , , Highbridge, Somerset, England"
"{AA2}The Pack Horse Hotel, Mark, , , , Highbridge, Somerset, England"
"{AB0}, , , , , Napier, Hawkes Bay, New Zealand"
"{AB1}, , , , , Napier, Hawkes Bay, New Zealand"
"{AB2}Park View Rest Home, , , , , Napier, Hawkes Bay, New Zealand"

When I looked at the Place data (via Tools / Work with Data), I found (using the above examples) that AA0 had zero links to it, AA1 had six links and AA2 had three links.

Any thoughts would be welcome (Mike - sorry about the length of this, but thought it best that you had the "full" story!)

[tatewise]

Do you mean the new fhugdownloads:contents:utility_gedsite|> Utility ~ GedSite by John Cardinal ? ? ?

There are several issues here, so please check all my comments.

Regarding the Rearrange Address and Place Parts Plugin, you appear not to have consulted its Help & Advice that I spend a great deal of time creating to pre-empt questions such as yours.
See plugins:help:rearrange_address_and_place_parts:result_set|> Rearrange Address and Place Parts ~ Result Set under Divergent Cloned Place Names that explains the purpose of those prefixes.

Regarding the Export Gedcom File Plugin, I am in discussion with John Cardinal in the Export Fact Definitions to GEDCOM (14340) thread and by E-mail. He has said that in general, the more similar the export is to what FH uses natively, the better. He also claims to support both Gedcom Release 5.5 and Draft 5.5.1 that both require ADDRess fields. So if GedSite does not support the ADDRess field, then E-mail John and request that it should for the reasons above.
Anyway, the Export Gedcom File Plugin moves the ADDRess into the NOTE field for products that do not support it, so you do not need to move your ADDRess data into PLACe records.

I am somewhat surprised that GedSite does not support ADDRess fields, because it claims to support Legacy and RootsMagic that like FH also support the ADDRess field. So we are in good company

[jbtapscott]

Thanks Mike

[tatewise]

Brent, I have discussed this further with John Cardinal, and GedSite definitely supports the ADDRess field.
It is not included in the default sentences, but can be customised using the [L:Address] code, which is not yet documented on the http://www.gedsite.com/en/sentences.htm page.
However, the Export Gedcom File Plugin will supply your FH Sentence Templates to GedSite that will turn {address} codes into[L:Address] codes automatically, and similarly for {cause} and {age} codes, etc.
So, just wait for the Plugin to be published in the Plugin Store and GedSite to be updated in the next week or so, and it will all happen automatically.

[jbtapscott]

Thanks Mike - John advised me of the [L:Address] and this gave me the data I was looking for on the website. I'll wait on a revised Plugin (and updated GedSite) before proceeding further but at the moment the out put is looking very good!

[tatewise]

Brent, bear in mind that for GedSite to display Fact Address data, then it must use [L:Address] in its Sentence Templates.

To get that to happen automatically when FH Sentence Templates are exported & imported, you must use the {address} code in the Tools > Fact Types > Edit > Sentence Template wherever required, or even better use the < at {address}> code.

[jbtapscott]

Thanks Mike. I'm planning to use the GedSite sentences rather than the FH Sentences initially as this will give me an "independence" from FH in my website generation. For the record though, I have absolutely no plans to move away from FH having spent a considerable amount of time modifying data, etc., when I moved over from TMG, but by building my sentences within GedSite (which has been very easy) it would reduce the pain if I did have to move to another genealogy package (a case of "once bitten, twice shy"!). It's also very easy to "flick the switch" to move from GedSite sentences to those imported from FH.

[tatewise]

Understood, but I believe most of the other products supported by GedSite also import Sentence Templates.