* Place and Address - Appearance in Reports etc.

[Shiriki]

Hi

Have been sending myself slowly (or should that be rapidly) mad trying to work out what is best with regard to what information to put in the Place and Address fields of Facts.
There seems to be many different schools of thought about how information should be distributed across these fields.
Initially I had keyed in information with scant regard to using a coherent approach to comma separated values and hence when working with data the information within the columns resembled a ‘Pig’s Breakfast’.
Having looked at a number of posts on this subject I am currently attempting to use the following formats for the Place and Address fields:

Place – 4 columns:

Village, Town/City, County, Country

Address – 7 columns:

Building name, House/Flat number, Road/Street, Village, Town/ City, County, Postcode

However when reviewing data when generating reports (and diagrams?) such as Individual Summary and Narrative Reports it is difficult to avoid either insufficient location information being displayed or indeed a lot of part duplication, when Place is followed by Address information.
In light of this I am debating whether to use 8 columns for BOTH Place and Address fields and duplicating exactly the information contained in each as follows:

Place & Address – 8 columns:

Building name, House/Flat number, Road/Street, Village, Town/City, County, Postcode, Country

I have looked into the various reports and find I can configure them as follows when focussed on the required individual:

Publish>Individual Summary>(Highlight Individual Concerned then generate report)>Options then untick Address on the Contents tab.

This will then give you the report (using Place field data and suppress the Address data which would by default appear in smaller text below each event…..
One can adopt a similar approach when generating a Family Group Sheet.

When generating a Ancestors/ Descendants Report by Generation then:

Publish>Ancestors (or Descendants) by Generation>(Highlight individual concerned then generate report)>Options then untick Inc Event/Attr Addresses

Without a load of manipulation (outside of FH)this seems to me to be an acceptable way of obtaining reports with the detailed information I require to pass on to other relatives without a lot of duplication appearing.
Hopefully it will also allow discrimination when geocoding via Place data, albeit manually (if the amount of data in the Place field currently upsets Edina coding, but who knows in the future?).

I have had a brief play with some family tree apps available for the iPAD, namely:

Branches for iPAD (Sherwood Electronics Laboratories, Inc.)
Mobile Family Tree 7 (Synium Software GmbH)
Heredis (BSD Concept).

It seems that they all use the Place data and don’t seem to display the data held in the Address field…hence the detailed location data within the Place field of FH is used…..need to investigate further with regard to ease of use but Branches seems promising as one can zoom in and reveal addional relatives, data and so on…..

I guess a number of you will have differing views on this subject, but it seems that whichever approach one looks at there are pros and cons…..

In the event that there is some underlying reason why the Place/Address columns needs to be amended in the future, then if all the data has been column sorted, by using Working with Data and copying /pasting between Place and Address fields for individual facts it should be easier to modify one’s approach…although it may be somewhat laborious.

Any suggestions or potential pitfalls in my proposed approach would be welcome as well as feedback on iPAD Family Tree apps.

Many thanks in advance

Shiriki

[tatewise]

Here are a few comments to ponder.

The easiest way to avoid duplication in Reports, etc, is to eliminate duplication in the Place and Address fields.

You are correct that there are many temptations to put everything in the Place field. BUT if you choose to do that, then don't use the Address field at all.

At present, nothing can be done about duplication in Individual Summary Reports or Family Group Sheets, but Narrative Reports can have their Sentence Templates altered to eliminate the duplication. BUT it does involve editing every Fact Type and using the =TextPart() function.

[EDIT: Actually duplication can usually be eliminated in Reports by using [[privacy square brackets]] as explained later in this thread...]

[jimlad68]

Shiriki - Like you say: "There seems to be many different schools of thought". All I can advise is what my plan is and why, but that suits me and I recently adjusted it to fit in with Geocoding .

1. Keep all location details in the comma sepatated PLACe. I also feel that this is more portable, for instance, export from TMG only uses PLACe and you mention iPad apps, and I suspect for use in other geocoding programs (see topic mentioned in point 3 below).

[1] -"property name/detail/flat#" [2] house number [3] street
[4] small village if associated with nearby town/ area of town [5] Town or Large village [6] county
[7] state [8] country [9] post code if wanted
I keep house number in a separate field for sorting purposes.

2. I use ADDRess as an abbreviaited place, this is so that it uses less space in diagrams. I don't think you can use it as an alternative to PLACe in reports, only as an addition.
There are a couple of LUA routines detailed in this rather old topic.
PLACe, ADDRess structure, level use-Lat/ Long from TMG (11246)

This is my final version, but it needs manually updating for new locations.

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 (OR FIRST DELETE ALL VIA QUERY)
            ptrAddr = fhCreateItem('ADDR',ptrFact,true)  -- Ensure field exists
            if ptrAddr:IsNotNull() then

local strPLAC = fhGetItemText(ptrFact,'~.PLAC') -- REPEAT FROM PLACe TO ADDRess LINES AS REQUIRED
strPLAC = strPLAC:gsub("Wigan, Lancashire, , England","Wigan")
strPLAC = strPLAC:gsub("Standish, Lancashire, England","Standish")
strPLAC = strPLAC:gsub("£ & _ = {} : ; @ , ~ # < > / |","£ & _ = {} : ; @ , ~ # < > / | £ & _ = {} : ; @ , ~ # < > / |")

             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

3. Rather than FHs Maps, I use Plugin Map Life Facts to get my geocodes. How you store your PLACe/ ADDRess is very important, see this topic:
Best format of PLACe and ADDRess for Map Geocoding (11937)

As ever, Gedcom is the best portable device we have, but comes in different flavours etc, so you need to structure your data accordingly.

Best of luck!

[Shiriki]

Thanks for the quick replies....nothing is straight forward is it....

With all the location data using applicable CSVs in the Place field how do I edit the relevant sentence templates (for Narrative Reports) so that for example a Birth Fact would read 'he lived at <Place> or for an Occupation Fact say Project Engineer at <Place> as opposed to the sentence reading he lived in <Place> or Project Engineer in <Place>?

I have looked in the Fact Types and opened Edit to look at the templates etc. and have in the past made a few custom ones, but does the use of Place in a sentence template automatically assume it is prefixed with 'in' which cannot be overridden? I can't see a way to suppress this and have an 'at' instead.

There certainly is a lot to consider relating to Place and Address field usage and a lot about the features within FH I need to get to grips with before taking the plunge!

Thanks again for any advice...

Shiriki

[tatewise]

When editing the Sentence Template click the <<Insert Code button and there is an option for Place (with no prefix).

e.g. < at {_place}>

Also this is where you could use {=TextPart(%FACT.ADDR%,1,3)} to use say only the first 3 parts of an Address, or any combination of parts from Address and Place to avoid duplication.

[Shiriki]

Ah....so that's how you do it...

Many thanks Tatewise

Will go away and have a play and re think about a strategy.......

Cheers

[arthurk]

I'm currently considering FH as a replacement for RootsMagic, and I'm trying to work out the best way to deal with my current list of Places and Addresses.

Until fairly recently I kept all location data in a single Place field in RM, and most of it is still like that, but I've started to enter new information with separate Addresses. I'm not 100% convinced that this is the way to go (while looking at other programs I've found that using RM-style addresses can lead to loss of data in other parts of an Event, such as sources and notes), so I was interested to find this thread (and others) dealing with this issue.

The easiest way to avoid duplication in Reports, etc, is to eliminate duplication in the Place and Address fields.

It occurs to me that, as noted in the Addresses and Churchs (12220) topic, the Address list is likely to include multiple instances of e.g. St Mary's Church, and that there needs to be some way to distinguish them. The most obvious way is to use the town/parish name as part of the address - but that is then going to duplicate part of the Place field. So is there some way to suppress the town/parish in the Address? From what you say, I guess not:

You are correct that there are many temptations to put everything in the Place field. BUT if you choose to do that, then don't use the Address field at all.

At present, nothing can be done about duplication in Individual Summary Reports or Family Group Sheets, but Narrative Reports can have their Sentence Templates altered to eliminate the duplication. BUT it does involve editing every Fact Type and using the =TextPart() function.

This is a bit disappointing to me, as Individual Summary Reports and Family Group Sheets are the type of printed output that I use most - although since they are mainly for my own private use I can probably live with it. However...

While experimenting around this issue in another program I discovered that it was possible to include the town/parish as part of the address, but inside privacy brackets, and in that way it could be kept out of printed reports. Does anyone know if that would work in FH? (I'm still at an early stage of exploring, and haven't really got into reports yet.)

Depending on which way I decide to go on Places and Addresses (one field or two), does FH have any tools to convert them one way or the other, or must it all be done manually? (RM has a tool for splitting them, so it might be easiest to use that before I migrate, unless anyone knows better - but it would still mean adding the extra town information at some stage in order to maintain the distinction between churches of the same name in different towns.)

(Incidentally, on editing Places (with or without Addresses): am I right in thinking that making a change to something against a fact/event in the Property Box will change that occurrence only, but that to make a global change you need to use Tools > Work with Data? Or is there a better way of doing either of these?)

Finally, and I think this probably does still relate to the way places and addresses appear in reports, how important is it to have a set number of fields for Places and Addresses? I've so far resisted any programs' attempts to force my place list into this kind of conformity, because UK locations can be so variable, but would I be missing out on anything in FH if I continued my resistance?

Thanks for any help,

Arthur

[tatewise]

Arthur, thank you for thinking outside the box and talking about [[ bracketed ]] private Addresses.
Yes, to my amazement that works.
e.g.
If the Place is Cheltenham, Gloucestershire, England and the Address is St Mary's Church, [[Cheltenham]] then the bracketed [[Cheltenham]] is governed by the Report Option to Inc. [[private]] Notes.
In fact that Report Option governs [[private]] text in any long (multi-line) text field such as Note, Address, Text From Source, Author, Publication Info, etc, but NOT short text fields such as Place, Where Within Source, Individual Names, etc.

Unfortunately, the same is NOT the case for the Diagram Option to Inc. [[private]] Notes, which only appears to apply to actual Note fields, but Address fields are rarely included in Diagram Boxes.

Manipulating Address and Place fields is becoming such a hot topic that I am thinking of creating a Plugin to make rearranging any Address and Place columns easy, providing there is a consistent column assignment scheme.

Yes, editing the Property Box fields of Place or Address just change that one instance. But you don't have to use the Tools > Work with Data > Places/Addresses command to make global changes. Click the [...] button to right of Place or Address for a shortcut to Work with Data. In FH V6 you can also edit Place Records directly via the Records Window. Finally there is Find & Replace command and Search and Replace Plugin.

Having a consistent Address and Place columns regime is essential for the Plugin mentioned above, and to be able to answer Queries such as how many Facts mention the country India or the county Kent. Just searching for India or Kent in the entire Place field will be unreliable, because several of the search functions are case insensitive and not confined to whole words, so might match Indiana or Kentucky. Without a columns regime, the Work with Data > Places/Addresses sorting on Columns and the =TextPart() function are worthless.

[delwoodman]

Having a consistent Address and Place columns regime is essential ........ to be able to answer Queries such as how many Facts mention the country India or the county Kent.

Whilst there are undoubtedly tasks where a consistent column regime is essential, I think it is perhaps oversimplifying to say that such a regime is essential to answer Queries of the type mentioned. Like Arthur, I have resisted reformatting all my place and address data into a strict columns regime both for the reason he states and because the place data has been entered using a variety of programs over many years and I have not thought the time that would be spent in reformatting would be worthwhile. I use queries often and if I encounter in a particular case the type of issue alluded to by Mike (which hasn't been often for my particular dataset) then I simply tweak the query filter to suit.

Derek Woodman

[arthurk]

Thank you for your comments, Derek - what you describe, and what I seem to have been doing, may not in some senses be strictly "correct", but if it works for us, and if anyone else who looks at the data can work out what we mean, is it wrong?

Having a consistent Address and Place columns regime is essential for the Plugin mentioned above, and to be able to answer Queries such as how many Facts mention the country India or the county Kent. Just searching for India or Kent in the entire Place field will be unreliable, because several of the search functions are case insensitive and not confined to whole words, so might match Indiana or Kentucky. Without a columns regime, the Work with Data > Places/Addresses sorting on Columns and the =TextPart() function are worthless.

One thing that concerns me about using a strict scheme of columns is that addresses are so variable. To give an extreme example, I had a relative whose address was on the lines of Flat 3, Holly Croft, Tower Lane, Chapel Allerton, Leeds - 5 elements, though you might be able to combine the first two into one. (This is a mangled/adapted version of the real address.) Nearby, still in Chapel Allerton, you might find a (fictionalised) address of 23 Quebec Terrace - but since there are no other Quebec Terraces in Leeds, you might choose to go minimalist and record it as simply 23 Quebec Terrace, Leeds - 2 elements. It's this variability, and the question of what to do with the empty columns, that I'm struggling to get my head round.

Also, to be honest, I don't often want to know how many times a place or address is mentioned, just to be able to identify the instances where it is used, or the people it's attached to. For that, I've valued the "Find Everywhere" tool in RootsMagic, and it seems that FH's Find tool will do exactly the same - with the added bonus that I can restrict a search to just names, places, notes etc. Putting things in strict columns so as to be able to do deeper analysis is a further step that I don't feel I need to take at this stage, though it's useful to know that the tool is available within the program should I ever wish to move on to that kind of thing.

Arthur, thank you for thinking outside the box and talking about [[ bracketed ]] private Addresses.
Yes, to my amazement that works.
e.g.
If the Place is Cheltenham, Gloucestershire, England and the Address is St Mary's Church, [[Cheltenham]] then the bracketed [[Cheltenham]] is governed by the Report Option to Inc. [[private]] Notes.
In fact that Report Option governs [[private]] text in any long (multi-line) text field such as Note, Address, Text From Source, Author, Publication Info, etc, but NOT short text fields such as Place, Where Within Source, Individual Names, etc.

I'm glad to have been able to suggest something, and it makes me feel that separating out addresses might be a worthwhile thing to do - though I'm still a bit concerned at the way some programs deal (or fail to deal) with these.

Anyway, thanks for all the thoughts,

Arthur

[tatewise]

More on strict column regimes.

The extra commas and blank columns in many scenarios are not a problem because in most Reports and Diagrams they are tidily collapsed.

One big advantage of formal columns is the Tools > Work with Data > Places /Address window.
This allows sorting by column, which is useless if there is no formal regime.
But with a regime you can, taking your example, sort all the Leeds Addresses together.
e.g.

Code: Select all

Flat 3, Holly Croft, Tower Lane    , Chapel Allerton, Leeds
      , 23         , Quebec Terrace,                , Leeds

This allows you to review similar entries and check they are all entered consistently.
For example, to ensure that Quebec Terrace always omits (or includes) Chapel Allerton.

There are numerous other examples where having a regime is useful.

[setait]

I must be having a very thick day.

Mike wrote:

One big advantage of formal columns is the Tools > Work with Data > Places /Address window.
This allows sorting by column, which is useless if there is no formal regime.
But with a regime you can, taking your example, sort all the Leeds Addresses together.
e.g.
Code: Select all
Flat 3, Holly Croft, Tower Lane , Chapel Allerton, Leeds
, 23 , Quebec Terrace, , Leeds

I can only work with either Places OR Addresses, so I cannot get a display where I can work with the full "address" for an event as demonstrated above. Does this display come from a plugin, or am I missing something?

Sheena

[tatewise]

Sheena, I was using Tools > Work with Data as one example.
Yes, the Places and Addresses options only operate on those fields in isolation.

But with the new =TextPart() function it is possible to work on the complete Address & Place columns using a Query and potentially a Plugin.
(Although in V6.0.1 there is a bug preventing the use of =TextPart() in a Plugin, see TextPart fails via Plugin (12250). [EDIT: Bug fixed in V6.0.2])

As usual the starting point is View > Standard Queries > All Facts and from cog menu Save As Custom Query with a suitable Query Name.

On the Columns tab create as many Address and Place parts as required:
Heading Expression
Place 9 =TextPart(%FACT.PLAC%,9,1,STD) Sort: Ascending
et seq ...
Place 3 =TextPart(%FACT.PLAC%,3,1,STD) Sort: Ascending
Place 2 =TextPart(%FACT.PLAC%,2,1,STD) Sort: Ascending
Place 1 =TextPart(%FACT.PLAC%,1,1,STD) Sort: Ascending
Addr 9 =TextPart(%FACT.ADDR%,9,1,STD) Sort: Ascending
et seq ...
Addr 3 =TextPart(%FACT.ADDR%,3,1,STD) Sort: Ascending
Addr 2 =TextPart(%FACT.ADDR%,2,1,STD) Sort: Ascending
Addr 1 =TextPart(%FACT.ADDR%,1,1,STD) Sort: Ascending

Ensure those are the top/left-most Columns and the Result Set will list Places & Addresses group together in ascending order.

[setait]

Thanks Mike - it's working now (once I'd remembered to add some rows!). Very useful for assessing how well and/or consistently I've been using the Address and Place fields.

Incidentally, I've been playing with your Map Life Facts plugin and have found a useful online tool to convert British National Grid eastings & northings into decimal latitude and longitude co-ordinates. Provided by the British Geological Survey, it's at http://www.bgs.ac.uk/data/webservices/convertForm.cfm (feel free to ignore this, if it falls into the "teaching your granny" category)

Sheena

[arthurk]

Thanks for the further comments. A couple more things I'd like to know, please:

When converting single-field locations to Place and Address, is there any automatic (or at least easy) way to do this so that all instances of a particular address can be changed at once, or is it a case of changing one, then going to edit the other instances one by one, and selecting the amended Place and Address?

Also, if you set up Places or Addresses with a certain number of columns, then decide you need more, is there an easy way to handle this or will all the existing ones need to be changed manually?

Thanks,

Arthur

[tatewise]

Arthur, if I understand your question correctly, that is what Tools > Work with Data is for.
When you Edit any Address (or Place) all instances in the GEDCOM will be changed.
Click the Help button in that dialogue for a fuller explanation.

Currently, if you change the number of Columns then all the existing values must be rearranged manually. But as I said above:

Manipulating Address and Place fields is becoming such a hot topic that I am thinking of creating a Plugin to make rearranging any Address and Place columns easy, providing there is a consistent column assignment scheme.

Sheena, thank you for that link, but I find the Google geocoder used by the Map Life Facts Plugin usually gets close enough, that with a bit of N/S/E/W nudging a perfect plot can be obtained. Alternatively, a Google Maps search for any location will give you the decimal Latitude & Longitude. Having found somewhere right-click anywhere on the map and choose What's here? The Lat/Longitude are displayed at the bottom of the popup box of details top left.

[setait]

Unfortunately I've got a lot of isolated Caithness hamlets (or probably fermtouns) to deal with at the moment that Google maps don't recognise (although they may well appear on a standard Google search), so I've been using the ScotlandsPlaces website (http://www.scotlandsplaces.gov.uk/) and CANMORE (http://canmoremapping.rcahms.gov.uk/) both of which tend to use the older National Grid references.

Sheena

[arthurk]

Arthur, if I understand your question correctly, that is what Tools > Work with Data is for.
When you Edit any Address (or Place) all instances in the GEDCOM will be changed.
Click the Help button in that dialogue for a fuller explanation.

OK, but if you start with the fictional "23 Quebec Terrace, Chapel Allerton, Leeds, WRY" (all in one field), I can see that it would be one step to edit that to just "Leeds, WRY". However, wouldn't you then need to create an Address of "23 Quebec Terrace (plus however many further fields you think appropriate)", and I'm guessing you'd then need to apply that individually to each event that needed it? Or is there a quicker way of doing this second part?

Currently, if you change the number of Columns then all the existing values must be rearranged manually. But as I said above:

Manipulating Address and Place fields is becoming such a hot topic that I am thinking of creating a Plugin to make rearranging any Address and Place columns easy, providing there is a consistent column assignment scheme.

I'd wondered if that was what you had in mind, but as a newbie still on the trial version, I haven't given a lot of attention to plug-ins yet, except where you've recommended certain ones as ways to deal with various data issues.

Thanks,

Arthur

[tatewise]

The fictional "23 Quebec Terrace, Chapel Allerton, Leeds, WRY" (all in one field) would also benefit from my proposed Plugin.
I assume the starting point is that entire location is in the Place fields of several Facts, and that all your locations are entirely in the Place fields, with all the Address fields empty.

The first step would be copy every Place field to its associated Address field.
There is already a prototype Plugin to do that in Moving Place data to Address Field (10124).
But my proposed published Plugin would offer that capability in its repertoire.

Then you can apply the Tools > Work with Data > Places edit to leave "Leeds, WRY" in the Place fields.
Similarly you can apply Tools > Work with Data > Addresses to leave "23 Quebec Terrace, Chapel Allerton" in the Address fields.

[arthurk]

This gets better by the minute

Many thanks for what you're doing on this - your plug-in sounds as though it will deal with many of my issues, and if I do make a permanent move to FH, it's certainly one that I'd want to use.

Arthur

[tatewise]

The Plugin I mentioned is now available as a prototype: Rearrange Address and Place Parts Plugin (12330).