* PLACe, ADDRess structure, level use-Lat/ Long from TMG

[jimlad68]

OK, I've bought the full product so I'm deciding how to structure my data in FH, so that I can "tidy" up my data in TMG prior to conversion. I have always been concerned with data portability, hence one of the reasons I have chosen FH and its GEDCOM structure.

The first thing I am looking at is PLACe (and ADDRess) information. I want to get this right as it makes a big difference regarding Diagrams/ Reports and increasingly GEO Latitude and Longitude external applications.

Please excuse this longish list, but I have had a good look around the excellent helpful site but still have some questions:

<><> PLACe and/or/not ADDRess.

[] LEVELS - TMG uses 10 place levels that are nicely exported to GEDCOM separated by a comma into a PLAC record; it does not seem to use ADDRess records. It seems that the GEDCOM norm, and used by at least FH and RootsMagic is to start the PLAC record with Town/City and use ADDR for street or other detail.

- Is there a "standard" or "most popular for Genealogy software" for what goes in each comma separated level of PLAC and ADDR? I note FH has max of 10 levels for ADDR and PLAC and seems to start PLAC with Town/City, County, State, Country. TMG uses position 9 for Lat/Long and 10 for Temple (n.b TMG Town/City starts at level 3).

- Is there a routine to manage/swap levels of the PLAC and/or ADDR?

<><> Diagrams/ Reports.

[] It looks quite easy to "declutter" PLAC info for reports with the Short, Medium, Tidy and Full options. However, in TMG you can select any number of the 10 levels which is very useful. Is it possible to do that in FH, say by Editing the "Text Scheme Dialog"?

Likewise is it possible to select levels from the ADDR?


<><> Latitude and Longitude.

[] TMG uses box 9 of 10 for Lat/Long.

[] As far as I can see RootsMagic has a "3.5 million name place database and can add a standardized place name as well as the latitude and longitude...."
Is the FH equivalent the Map Life Facts?

[] I note Map Life Facts and Map Geo-code Maintenance uses Latitude and Longitude, but where does it store them?

[] Having stored the Latitude and Longitude, is it in some "standard" place that external programs can readily understand (I've seen mention of Map My Family Tree Links and Family Atlas and Google Maps).

Hope that is not too much, the answers might even help other users.

Cheers, Jim Orrell

[tatewise]

I applaud your objective of structuring your data at this early stage.
Although much of the GEDCOM Specification is quite firmly defined, the PLACe and ADDRess fields are a weak spot.
See the glossary:places|> Glossary > Places and Addresses for a summary.

Is there a "standard" or "most popular for Genealogy software" for what goes in each comma separated level of PLAC and ADDR?

I am not aware of any such de facto standard. The general rule is to assign a specific content to each comma separated column, and leave the column blank if that content is unknown. See next answer.

Is there a routine to manage/swap levels of the PLAC and/or ADDR?

The FH Tools > Work with Data > Places/Addresses offers some management capability.
See also glossary:work_with_data|> Glossary > Work with Data.

Likewise is it possible to select levels from the ADDR?

Unfortunately not at present, not even with FH Functions, but Calico Pie are aware that FH needs the ability to flexibly select/display any columns from any comma separated field.

Is the FH equivalent the Map Life Facts?

Actually Map Geo Code Maintenance works with Map Life Events, whereas Map Life Facts is self contained regarding Lat/Long adjustments, and offers many more features.
See plugins:help:map_life_facts:map_life_facts|> Plugin Help and Advice > Map Life Facts for details.

I note Map Life Facts and Map Geo-code Maintenance uses Latitude and Longitude, but where does it store them?

By default they both store them in the Project Plugin Data folder that sits alongside the Media folder within the Project .fh_data folder.
But Map Life Facts also offers to option to store them in GEDCOM Source Records &/or Repository Records.
These allow you to how_to:create_locations_database_details|> Create a Locations Database of Place & Address Details.

Having stored the Latitude and Longitude, is it in some "standard" place that external programs can readily understand (I've seen mention of Map My Family Tree Links and Family Atlas and Google Maps).

I am afraid I am not familiar with these programs so cannot comment.

[jimlad68]

Thanks tatewise again for your responses, even though they were not very good news, but hope for the future with "but Calico Pie are aware that FH needs the ability to flexibly select/display any columns from any comma separated field."! And apologies for my delay in replying, you had me off at a tangent with Sources.

After some tidying up in TMG I tried a direct import from TMG v7 project files (I think I saw somewhere there are problems with later versions), this worked without a hitch, except nothing was added to the ADDRess fileds, all to the PLAC fields, and if there was a place with no town, say just England, it placed England in the first column, not paralel with the England of say Wigan, England, and 2 columns out from say Any Street, Wigan, England. These are all separate fields in TMG, so it should not be a problem. So not as good as exporting via comma separated GEDCOM PLAC tags. Should I flag that as an issue with FH? As much as I am liking FH, I think I will have a long list of bugs/ limitations/ wish list. It would be nice to have some import options for say how to treat comma separated PLACe tags.

So, for the short term, unless I can think of an automated way to strip the 1st 2 columns of my GEDCOM PLAC into ADDR tags I think this will be the quickest:

- Just export 10 comma separated PLAC fields from TMG in GEDCOM, import to FH and for the present ignore ADDR.

- If I need a less cluttered Diagram/Tree to print or PDF, I could copy my FH GEDCOM, word(as text) or notepad simple macro to "squash" the data (e.g. leave out some counties, use state and country abbreviations etc) and create the diagram from that. I would hope in the longer term comma separated value selection will be introduced.

- In the longer term I would like to include GEO lat/long details, the obvious place to store this would be in the comma separated PLAC tag as that makes it GEDCOM portable. TMG uses field 9, not sure what anyone else uses. From what you said before, the FH plugins store them in the Project Plugin Data folders, so I would not have thought very portable to other applications. But, that Map Life Facts also offers to option to store them in GEDCOM Source Records..... I have had a look and it seems very complicated. Something else to study for the future.

I would hope that Calico Pie will come up with a 100% GEDCOM "fix" for Lat/Long external interoperabilty, as they seem to be an up to date tech Savvy company, Rootsmagic and FTM are ahead of the game in this area.

Cheers
JimO

[tatewise]

You may find these threads of interest:
Moving Place data to Address Field (10124)
How to handle places (11051)
Location box required (11101)
Some of these suggest ways Plugins may be used to resolve some of the issues.

It does no harm to flag any suggestions to Calico Pie, or add them to the FHUG Wish List.

I am not as confident as you that putting Lat/Long in the PLACe field makes them any more GEDCOM portable than any other GEDCOM field.
As you have discovered, the weak semantics of the PLACe & ADDRess fields make import & export unreliable for any positional data.
At present the only structured positional data is the sub-fields of the ADDRess field, as mentioned in How to handle places above.

Calico Pie on its own cannot come up with a 100% GEDCOM "fix" for Lat/Long external interoperability, because they do not govern the GEDCOM Specification. It would just be another proprietary customisation of the GEDCOM tags. However, Calico Pie are represented on http://fhiso.org/ that will hopefully come up with a better GEDCOM.

[jimlad68]

tatewise, your Plugin in Moving Place data to Address Field (10124) looked very useful, I don't suppose you know if it was developed further, jayef does not seem to be around any longer, at least not under that name.

But your plugin is a good starting point. A little against the norm, but I could keep the PLAC with full place detail, and use ADDR as an abbreviated list for diagrams or where space is at a premium, but this still lacks the flexibility of selecting each level (in TMG I used abbreviations in later fields).

But then again... in How to handle places (11051), your "subsidiary Address fields available" looks very interesting., at least for diagrams.

[tatewise]

I am not aware of the Plugin being developed at all.

However, it would be an interesting exercise for you to cut your teeth on!

An extension of that idea has occurred to me that would allow column parts to be handled, until FH offered better features.
Let us assume you have managed to transfer 10 column PLAC fields from TMG.
The Plugin could be adapted to transfer the PLAC field to the ADDR field, but replace commas with newlines, which are allowed in ADDR fields.
So now the ADDR field holds 10 lines also known as paragraphs.
Each line/paragraph can be extracted using the function =GetParagraph(%INDI.BIRT.ADDR%,2), where the 1st parameter is the ADDR field of interest, and the 2nd parameter is the line/paragraph/part number.
Thus any chosen ADDR part can be displayed in Diagrams, conditionally tested, etc.

If you did not want the entire 10 parts repeated in the PLAC field, then that could be reduced to perhaps just Town, County, Country, making the PLAC qualifiers Short & Medium more useful.

Note that in Reports any multi-line ADDR field is automatically converted to one line with commas in place of newlines.

[tatewise]

Sorry, I have just realised there may be a way of handling PLAC parts in the same way as ADDR parts above.

Unlike the ADDR field, the PLAC field has a subsidiary NOTE field, which allows multi-line text.
So each comma separated PLAC part can be copied to its NOTE field on a separate line (using the Plugin method).
Then =GetParagraph(%INDI.BIRT.PLAC.NOTE2%,2) can extract any part for Diagrams.

You just need to run the Plugin from time to time to ensure the NOTE field matches the PLAC field.

[July 2014 EDIT]
The Copy Place to Note Lines ATTACHMENTS Plugin below will do the job.

There are variations on this theme.
You could choose to adopt the popular convention of a fixed number of PLAC part columns (e.g. Town, County, Country) and a fixed number of ADDR part columns (e.g. House name/number, Street, District, Postcode, Latitude, Longitude).
Then the PLAC field NOTE would have a line dedicated to each PLAC and ADDR part comma separated column.

The advantages of this are that the PLAC and ADDR fields would have their conventional usage and appearance in Reports, etc, while the NOTE field parts can be used in Diagrams, etc, but otherwise are almost invisible.
The PLAC and ADDR fields would be managed using Tools > Work with Data as usual.

A variant of the Plugin would ensure all the data is synchronised and report for example if the number of PLAC or ADDR columns is wrong.

[jimlad68]

thanks for those very interesting foods for thought, I had never considered or worked with the NOTE part of PLAC, with work they sound even more useful than simple selection of the comma separated fields, I feel experiments coming on. However by the time I sorted it out FH might have a new system!

For the short term and to get things moving I think I will export 10 comma separated PLAC fields from TMG in GEDCOM, import to FH and for the present ignore ADDR, that should then give me a stable starting point for future work.

[jimlad68]

I could not resist a quick play with this but got limited results:

I created ADDRess 20 text lines (paragraphs) manually via the facts tab for birth > address RHS tab > Edit Address.
- This showed up as 1st line with the ADDR, then 19 CONT lines in the GEDCOM.
- went to diagrams > options > text tab > edit text scheme > edit birth > added to exitsing template to make:
=GetParagraph(%INDI.BIRT.ADDR%,2)
- this gave nothing.
- if I then reduced the line to
%INDI.BIRT.ADDR%
it showed all 20 lines of the ADDRess.

I tried various options to no avail. I am missing something obvious.

- I tried similar with the PLAC but I could not find a way to enter text paragraphs manually, so I directly edited the GEDCOM to mirror the ADDR statements. But I could not get anything with
=GetParagraph(%INDI.BIRT.PLAC.NOTE2%,2) or %INDI.BIRT.PLAC.NOTE2%
However with %INDI.BIRT[1].PLAC.CONT[1]% (the <<select showed CONT showed as a non-standard field), IT RETURNED THE 1ST PARAGRAPH only.
- I tried =GetParagraph(%INDI.BIRT.PLAC.CONT%,2), but no results.

Perhaps diagrams are not designed to generate paragraphs?

[tatewise]

It seems there is problem with ADDR fields not being supported by the =GetParagraph() function, which I shall report to Calico Pie. (I will also check all the other multi-line long-text fields.)

I have no problem with the PLAC.NOTE2 fields.
Perhaps you have not entered the CONT fields correctly in the GEDCOM file.
To do so, use All tab of Property Box, right-click Place field, then choose Add Note > Add Note to this Record.
In the Note field, click its text box and the [...] button to the right to open the Note edit window and enter multi-line text.
Then =GetParagraph(%INDI.BIRT.PLAC.NOTE2%,2) will work OK.

I suspect on the All tab you'll find CONT fields as Uncategorised Data Fields (UDF) marked with star-burst bullets.
This is supported by the fact that you were allowed to create illegal %INDI.BIRT[1].PLAC.CONT[1]% using the Data Reference Assistant.

[jimlad68]

It's a cracker, works a treat now with your PLAC NOTE input method.

I noticed in the GEDCOM file, created by FH it goes:
2 ADDR address, ad , etc
3 CONT note line/para 1
3 CONT note line/para 2

whereas for PLAC with your All > note creation method via FH:
2 PLAC Kirkcaldy, Fife, Scotland, SCT
3 NOTE note line/para 1
4 CONT note line/para 2
4 CONT note line/para 3
i.e. PLAC has a NOTE then CONT, ADDR just has CONTs

I just have to think of the best way to use it, and the ADDR if it gets fixed, and maintain it, your " Plugin code will copy every PLAC field to its associated ADDR" looks promising.

As an aside, I cannot find reference in the manual or on the FH or FHUG website regarding the method you advised me to enter the PLAC NOTE paragraphs, is this notated anywhere?

Anyway, I still have a lot of reading/ tutorials but for the present I've only a few more queries before I import in earnest, so I might be a bit quieter on the forum after that, in addition 2 grandchildren are arriving from Texas next week for 3 weeks, so that should keep me alternatively occupied.

thanks again.

[tatewise]

The CONT tag is used to define CONTinuation lines in any long-text fields such as ADDRess, and all NOTE fields.
That is why CONT is a sub-tag of ADDR and also a sub-tag of NOTE.
You annotation for ADDR is a little incorrect and should be as follows (c.f. NOTE).
2 ADDR address line/para 1
3 CONT address line/para 2
3 CONT address line/para 3

The FH Help pages that cover low-level editing are:
Using Family Historian > Main Windows > Records Window especially Browsing & Low-level Editing
Using Family Historian > Dialogue Boxes > Property Box > Property Box: All Tab
In the Book: Getting the Most from Family Historian 5 search for low-level editing and there are several refs to Records Window and All tab.

Remember that FH is 100% GEDCOM compatible and uses GEDCOM as its database.
The low-level editing allows direct access to all the GEDCOM structures, primarily for advanced users.
To use all structures correctly, you need to understand the glossary:gedcom|> GEDCOM Standard 5.5.

The other FH dialogue windows provide more convenient access to the most popular structures.

I understand the grandchildren diversion, as I have two of my own!

[jimlad68]

tatewise,

Your copy PLAC to ADDR plugin works a treat, I can then use (I think your excellent) search+replace with full stop in LAU pattern mode on fact 2address fields only2 to delete them. I was surprised that it removed the ADDR tags from the GEDCOM, I thought it would just have left them blank, but it did the job for me.
It is then easy to delete ADDR and refresh at will. After TMG, it never fails to amaze me how fast FH is. One day I will check out the program database etc (I'm assuming it reads the GEDCOM in each time to its own internal temporary database.

But then I hit a problem:
for a diagram and using the << Insert to create a template
%INDI.BIRT[1].ADDR% gives all fields of the ADDRess, no problem.
%INDI.BIRT[1].ADDR.CITY% (ADR1,2 etc also) gives me "no data" (I ticked the "no data Text" box and made it "no data")

Is this a variation on a theme of the earlier problem you noted 07 Jun 2014 19:21 -

"It seems there is problem with ADDR fields not being supported by the =GetParagraph() function, which I shall report to Calico Pie. (I will also check all the other multi-line long-text fields.)"

Anyway, assuming I can get the ADDR.ADR1 etc to work. My short term plan is:
- Use PLAC for all my master place details, inc my own abbreviations fields (I like a fairly simple standard master record and this also helps with any export/sharing I do)
- use Search/replace to remove all ADDR
- use your plugin to copy PLAC to ADDR
- use ADDR.CITY etc when I need to truncate or use abbreviations.
- If the ADDR.ADR1 problem is not fixed, use and editor macro on a copied GEDCOM to abbreviate certain place text.

cheers

[tatewise]

You don't actually have to use the Search and Replace Plugin to delete ADDRess fields (or most other fields).
Just clone a custom copy of View > Standard Query > All Facts and on the Columns tab add the Address field.
Then in the Result Set use Alt + click on Address column heading to reverse sort the Address fields.
Select all the Address fields with text, using click & drag, or usual Shft key select, and then hit the Delete key.

BTW: The Plugin does not delete the ADDRess fields, but FH purges them when saved and reopened. If you check the All tab immediately after using the Plugin you will find the empty ADDRess fields are still present.

The %INDI.BIRT.ADDR.CITY% (ADR1,2 etc.) sub-fields must be individually populated by you. They are NOT some automatic way of extracting text from the %INDI.BIRT.ADDR% field. (Nothing to do with =GetParagraph() function.)

BTW: I have reported =GetParagraph() and similarly =GetLabelledText() to Calico Pie, as their documentation explicitly says they should support Address fields, but they don't. They do support all other long text fields.

The Plugin can be adjusted to perform most if not all of your planned tasks. e.g.
(1)
Instead of skipping the ADDR field unless it's empty, compare its value with the PLAC value and update if different, thus avoiding the manual deletion of ADDR fields.
i.e.
if fhGetItemText(ptrFact,'~.ADDR') ~= fhGetItemText(ptrFact,'~.PLAC') then
(2)
The Plugin can translate any standard PLAC values to abbreviations.
i.e.
local strPLAC = fhGetItemText(ptrFact,'~.PLAC')
strPLAC = strPLAC:gsub("Warwickshire","Warks")
This can be driven in a loop from a table of translation pairs, so only the table needs modifying to adjust the translations.
(The gsub() function is defined in http://www.lua.org/manual/5.1/ and supports LUA Patterns.)
(3)
If you have standard column designations, then the Plugin can split the ADDR or PLAC field on commas, and assign any of the sub-strings to any ADDR.CITY (ADR1,2 etc.) sub-fields.
See plugins:code_snippets:split_a_line_using_a_separator|> Plugins > Split a Line using a Separator (code snippet).
It can similarly assign any such sub-strings to the PLAC.NOTE2 lines/paras for use by =GetParagraph().

FYI: Please consider the advice in glossary:places|> Places and Addresses regarding the conventions of what should go in which field to aid portability, that I believe you are concerned about.

[ I can hear you saying the learning curve is getting steeper instead of shallower ]

[jimlad68]

tatewise,

I'm not sure if I need to spend a week or 2 background reading first, but I am having a problem inserting into your original plugin your:

local strPLAC = fhGetItemText(ptrFact,'~.PLAC')
strPLAC = strPLAC:gsub("Warwickshire","Warks")

I tried a few variations and at best I managed the gSUB OK (on "step into" it showed the replacement in the "variable window") but then gave message:
Line 17: bad argument #2 to 'fhSetValue_Copy' (fh.PITEM expected, got string) for line
isOK = fhSetValue_Copy(ptrAddr,ptrItem) -- Set Address as copy of Place.

Looked everywhere for reference to PITEM as opposed to string but found nothing, suspect it is FH specific.

Any hints?

Your amended code I used:

Code: Select all

tblTypes = {'INDI','FAM'} -- Scan both Family and Individual Record Types
ptrItem = fhNewItemPtr()
ptrFact = fhNewItemPtr()

for intType, strType in ipairs(tblTypes) do
   ptrItem:MoveToFirstRecord(strType)
   while ptrItem:IsNotNull() do
      if fhGetTag(ptrItem) == 'PLAC' then               -- Search items until Place field found
         ptrFact:MoveToParentItem(ptrItem)
         if fhGetItemText(ptrFact,'~.ADDR') == '' then   -- Check Address is empty
            ptrAddr = fhCreateItem('ADDR',ptrFact,true)  -- Ensure field exists
            if ptrAddr:IsNotNull() then

ptrItem = fhGetItemText(ptrFact,'~.PLAC') 	     -- Jim inserted
ptrItem = ptrItem:gsub("a","zzzzzzz")            -- Jim inserted

             isOK = fhSetValue_Copy(ptrAddr,ptrItem)  -- Set Address as copy of Place
            end
         end
      end
      ptrItem:MoveNextSpecial()
   end
end

[tatewise]

I don't know how programming literate you are, but here goes.

It is a matter of understanding different data types and the behaviour of functions.

In the FH Plugins window maybe use How to Write Plugins > How to Write Plugins and Introduction to Lua.

ptrItem = fhNewItemPtr() defines an item pointer to a field in the GEDCOM file.

strPlac = fhGetItemText(ptrFact,'~.PLAC') defines a string of text got from the GEDCOM file.

In the FH Plugins window use How to Write Plugins > The Family Historian API > Functions Index > fhGetItemText. This says its parameters are an item pointer e.g. ptrFact and a Data Ref string, e.g. '~.PLAC' and it returns a string e.g. strPLAC.

The function fhSetValue_Copy(ptrAddr,ptrItem) has two item pointer parameters, and copies one field to the other in the GEDCOM file.

To set a field use the fhSetValueAsText function that has an item pointer and string parameter.
isOK = fhSetValueAsText(ptrAddr,strPlac) sets the field pointed to by ptrAddr to the string of text in strPlac.

Your inserted code is altering ptrItem which is the while loop pointer to GEDCOM items and would disrupt the looping.
It is actually being set to a string value, which is invalid as the 2nd parameter of fhSetValue_Copy.
The error message says bad argument #2 where 'argument' is another name for 'parameter'.

Can I leave it as an exercise for you to correct your two inserted lines and the following line of code as discussed above, because doing is better than copying, but I can give you further tips if necessary.

[jimlad68]

Cheers, we have lift off, no problem with 2 items either, just have to work out the pattern matching for when there is a - (dash/minus sign) in the text, but I'm hoping that is easy (otherwise simply change them). I'm happy I have now proved my data setup in practice and I see many happy hours playing with Lua, but first I will have to get the lawn cut, sweep the paths, mop the floors (too late for the windows) in preparation for the Texans. I suppose it does one good to have visitors!

My IT experience: First 26 years mostly in IBM Mainframe Operations, so lots of butchering JCL (Job Control Language) in the middle of the night (fix it any way and quick!) and automating thereof with CLISTs (Command List). After that Systems testing so "Jack of all trades, master of none". Mostly butchering more JCL CLISTS + IBM DB2 SQL, ACCESS, EXCEL. Problem is I never got to the bottom of programming structure, but its fun if you have the time. So now I must take time to wade through the suggested reading and examples.

Thanks again, and bye for probably 3 weeks. Jim.

The code that worked:

Code: Select all

tblTypes = {'INDI','FAM'} -- Scan both Family and Individual Record Types
ptrItem = fhNewItemPtr()
ptrFact = fhNewItemPtr()

for intType, strType in ipairs(tblTypes) do
   ptrItem:MoveToFirstRecord(strType)
   while ptrItem:IsNotNull() do
      if fhGetTag(ptrItem) == 'PLAC' then               -- Search items until Place field found
         ptrFact:MoveToParentItem(ptrItem)
         if fhGetItemText(ptrFact,'~.ADDR') == '' then   -- Check Address is empty
            ptrAddr = fhCreateItem('ADDR',ptrFact,true)  -- Ensure field exists
            if ptrAddr:IsNotNull() then

local strPLAC = fhGetItemText(ptrFact,'~.PLAC')
strPLAC = strPLAC:gsub("Wigan, Lancashire, England","Wigan")
strPLAC = strPLAC:gsub("Standish, Lancashire, England","Standish")

             isOK = fhSetValueAsText(ptrAddr,strPLAC)  -- Set Address as copy of Place
             -- isOK = fhSetValue_Copy(ptrAddr,ptrItem)  -- Set Address as copy of Place -- orig
            end
         end
      end
      ptrItem:MoveNextSpecial()
   end
end

[tatewise]

I know not to expect a reply for some weeks but here are some pointers.

(1)
gsub() patterns are similar to Regular Expressions and have 'magic' characters such as ^ $ ( ) % . [ ] * + - ? which must be 'escaped' using % so non-magic hyphen is %- and non-magic plus is %+ etc.
See plugins:understanding_lua_patterns|> Understanding Lua Patterns for details including the Examples and Reference Links.
Among the Examples is the plugins:code_snippets:plain_text_substitution|> Plain Text Substitution (code snippet) which can be inserted at the top of your Plugin.
This offers replace() that is a substitute for gsub() but automatically ignores the 'magic' characters.

(2)
If you anticipate a significant number of abbreviation translations, then a table driven loop is more elegant:

Code: Select all

local tblTranslate =
{
 Wigan    = "Wigan, Lancashire, England",
 Standish = "Standish, Lancashire, England",
 Warks    = "Warwickshire, England",
}
for strNew, strOld in pairs ( tblTranslate ) do
  strPlac = strPlac:replace(strOld,strNew)
end

The abbreviations on the left of the table must be simple alphabetic text (but there also is a technique for any text).
The for loop works through each tblTranslate pair and performs each replacement.
To add translations simply needs extra assignment rows in tblTranslate.

[jimlad68]

tatewise,

thanks for those extras, I am now happy I can convert my data and structure it so I can do what I reasonably want with it. So in my spare moments I will be moving to FH and coming back to refining the plugin later with at least a preemptive delete of all the ADDRs. The initial tranche of address data should be easy by exporting spreadsheet columns (an old system testing technique). I like you suggestion of elegance, I have seen and admired so much "neat" coding, but elegance is usually the last thing on my mind, perhaps why I managed the trouble shooting bit! In the meantime I am sure there will be more general FH queries as I use in anger.

[tatewise]

The =GetParagraph() with ADDR problem has been acknowledged by Calico Pie and they say will be fixed, along with some related cases of =GetLabelledText() and the equivalent Plugin API functions.