* Creating a Correct Place Record

[Wheatley-Dewey-58]

This is my first post.
I have decided to use the OVERLAPPING PLACES & ADDRESSES approach discussed on FHUG.

My question comes from observing other experienced users with a 3-column PLACE approach and often having two items in Column 3, or a mixture of items in columns. For example:

If they have a Town called Spring, in the State of Texas, in the Country of USA.

C1 Spring, C2 Texas, C3 USA

If they have a place in the County of Harris, in the State of Texas, in the Country of USA.

C1 Harris, C2 Texas, C3 USA

If they have a place in the Town of Spring, in the County of Harris, in the State of Texas, in the Country of USA.

C1 Spring, C2 Harris, C3 Texas, USA

Is this good practice, or doesn’t it matter having columns with a mixture of Town/County, County/State, or State/Country. And C3 sometimes with two place types separated by a comma.

It would seem better to have a 4-column place approach and when you don’t have some data, just leave them blank, for example, always Town, County, State, Country.

For Harris Texas USA: C1 (blank), C2 Harris, C3 Texas, C4 USA.
For Texas USA: C1 (blank), C2 (blank), C3 Texas, C4 USA.

Is it no good starting with a blank C1 as a practice?

Or perhaps just a 3-Column approach where C1 is always a Town or County, but then is mixing a Town or County advisable. Perhaps just a consistent approach is OK, so long as it doesn't affect queries or printing reports or documents?

Thanks for your help.

[ADC65]

Hello and welcome to FHUG.

You will find no end of discussions on the subject of place formatting in the archives; I would suggest having a read through those and deciding which suits you best, because there is no right-or-wrong solution. It will depend on what you want to do with the data and how hard you want to work at formatting it consistently. Whatever method you decide on, I can guarantee that you will meet an exception within a very short time period, and trying to shoehorn data into a template it doesn't really want to go into is generally not a good idea.

For the UK I tend to use Town, County, Country (e.g., Stoke on Trent, Staffordshire, England) and for the USA I use Town, County, State, Country. If I find a locale or area, I tend to add it after the address, e.g., Address = City Road, Fenton, Place = Stoke on Trent, Staffordshire, England. But there are still many exceptions. I leaned not to worry about it too much and get on with researching family history instead .

So my advice would be: try to be as consistent as you can, find whatever suits you best, and don't over-complicate it.

[tatewise]

The general advice is to have as many columns as needed for the maximum number of Place components.
So your 4-column Town, County, State, Country approach works well and if you don’t have some data, just leave them blank.

An advantage of that format is Queries, and other features, can analyse by Town, County, State, or Country.
They would use the =TextPart(...) function to isolate the particular column part to be analysed.
That is not possible if the columns do not hold consistent Place components.

However, when entering Place fields FH tries to auto-complete based on existing Place records.
If some records have leading blank columns then that feature may not work so well and you must remember to start Place fields with a comma to make the first column blank.

I suggest you practise, perhaps in the Family Historian Sample Project, with different Place column settings and enter various Place fields. Then investigate analysing by particular columns.

[LornaCraig]

Is this good practice, or doesn’t it matter having columns with a mixture of Town/County, County/State, or State/Country. And C3 sometimes with two place types separated by a comma.

Just to be clear, it is not possible to have “C3 sometimes with two place types separated by a comma.” The insertion of a comma is what delineates the separate parts (columns), so you can’t have a comma within a column. In cases when I find I need to add an extra element within a column I either add it without a comma or, for clarity, put brackets round the extra element, as in “Spring (Harris), Texas, USA”.

However many columns you decide to use, I do recommend being consistent in keeping the same type of component in the same column, for reasons Mike has explained – for example it makes it easier to use a query to find all events in a particular county. But you do have to be careful when entering data because you have to take care to enter commas in the right positions.

Your choice may depend on where most of your places are likely to be. If a lot of your places are likely to fit best in a four part place structure then I’d recommend using a four columns and just leaving some part(s) blank if they are not needed.

[AdrianBruce]

To reinforce what Lorna says from a different angle perhaps...

Columns are not an inherent part of placenames. The placenames are stored on file as bits of text separated by commas. The columns appear only in certain views such as Tools / Work With Data / Places. You can specify the number of columns in that view and to start with, a comma-separated bit of text goes into a single column. If there are more comma-separated bits of text than there are columns, then the remaining bits end up in the last column.

On a personal level, I did once try to ensure the same type of text was in the same column (e.g. country names were always in column 4) by having leading, empty parts (e.g. ", , , USA"). The first issue was that I could never train my typing to do a consistent comma-space or space-comma. Sometimes I typed one, sometimes the other. And this was partly because my brain could never decide whether such a name should start with a space or a comma... Also, as Mike alludes, I found the auto-complete issue to be a pain because comma-space and space-comma are different placenames in the current auto-complete software so I couldn't use auto-complete to produce a consistent set of names. So I decided not to bother with leading commas. I do use intermediate empty comma parts - e.g. "Manhattan, , New York State, USA" (that's not a placename I use, I'm just illustrating the empty bit).

[tatewise]

Yet another angle...

The following tactics work well if Place field comma-separated parts are always completed from right-hand end.
e.g.
USA
Texas, USA
Harris, Texas, USA
Spring, Harris, Texas, USA
and NOT
Spring, , Texas, USA

The =TextPart(...) function allows comma-separated parts to be extracted counting from the right-hand end.
e.g.
=TextPart( %INDI.BIRT.PLAC%, -1 ) extracts the last part, i.e. the country USA in the above examples.
=TextPart( %INDI.BIRT.PLAC%, -2 ) extracts penultimate part, i.e. the state Texas in the above examples.
=TextPart( %INDI.BIRT.PLAC%, -3 ) extracts the next part, i.e. the county Harris in the above examples.
If the part does not exist then it returns an empty string.

That allows analysis to focus on consistent parts and auto-complete also works well.

P.S.
Tools > Work with Data > Places also works well with the above format if Reverse Display Order is selected.
Then Places are shown with last column on the left so displays in order Country, State, County, Town.

[Gary_G]

I tend to agree with Tatewise on the strategy to use. My experience has been that the larger divisions are more "standard" within a country. It's the smaller divisions and specific places that seem to be an issue. That means that the "work from the right" approach he mentions seems to turn out better results.

[Vyger]

You will find no end of discussions on the subject of place formatting in the archives; I would suggest having a read through those and deciding which suits you best, because there is no right-or-wrong solution.

The advice above is sound and you will received and read many conflicting opinions and styles on this very contentious subject.

There is no right or wrong way but in each software package there are methods of data entry which work better for more desirable outputs. I find a lot of Family Historian users prefer to combine Address and Place as you appear to have settled on. I find the reason they do this is that FH does NOT facilitate the Geocoding of Addresses and people do want to want to do that.

If I use Belfast, Ireland as an example I have over 2K Addresses, they are mostly geocoded in another program, often have notes and Media attached, those Addresses are relational to Belfast and I want to view them as such. I do not want over 2K Place entries in my list for Belfast sorting all over the show. I ask myself would a postal sorting office just lump everything into one sack with all the problems resulting from sorting and the differing ways Addresses were entered and formatted?

If Family Historian were to someday produce geographical proximity reports of Churches, Cemeteries, Schools, Hospitals and Addresses where family events took place and offer the option to Print such reports with like a book appendix with the option to include attached Notes and Media I believe discussions like this would have a different bias.

Regardless those are the limitations of Family Historian and each user needs to decide how they invest their time to get the best and most beneficial output for themselves. I have always tried to avoid restricting myself to the limitations of software packages, preferring to Wish for better and there are items on the Wish List on this subject also.

For now, I default to FOUR components (no Address) if a less significant (detailed) location is missing then I omit it, in simple terms reading from right to left the more components the more detail, examples;

Ireland - Parish, Barony, County, Country (Townland, if known as Address)
US - Township, County, State, Country (Address or site detail, if known, as Address)

The Ireland example is the best reliable geographic mapping indicator I can use for communities, the TOWNLAND which is a sub-division of the Parish I enter as ADDRESS so relational to the Parish. There are over 65K TOWNLANDS in Ireland and, as you can imaging those names repeat often so being relational is important. Also the Townland system goes back to Norman times, has remained mostly unchanged and is still used today by land registry services north and south of the border.

The only advice I can offer users is to think very carefully about your goals in the future so you don't waste a lot of time needing to revert from a hasty decision. I must admit I am passionate about mapping, the movements of people and communities are more revealing to me than any specific PLACE entry (Address or not) I also like to record and research more details on Churches etc to embellish my research, not everyone would.

I'm only with FH a few years and the bottom line is that I find it lacking in terms of mapping at present and I try not to do work-arounds which I will regret later.

[ColeValleyGirl]

I find a lot of Family Historian users prefer to combine Address and Place as you appear to have settled on. I find the reason they do this is that FH does NOT facilitate the Geocoding of Addresses and people do want to want to do that.

If you do combine Places and Address, I strongly suggest adopting a standard set of columns (I use house number/name, street, village/suburb, town/county, county, country for the UK). If you standardise it makes using the Rearrange Address and Place Parts plugin easier in future if things change.

[tatewise]

I have decided to use the OVERLAPPING PLACES & ADDRESSES approach discussed on FHUG.

So, contrary to what was said recently, the OP is NOT combining Address & Place which would be the Places Only approach.

[Vyger]

Thanks for the clarification Mike, I misinterpreted "overlapping"

I also agree with the right to left approach recommended by you and seconded by GaryG. I see no reason for not discovering the data regarding where a specific location is through research. Geocoding further defines this and Notes can be utilized for border straddling and historical changes.