* Renamed Cemetery, Hospital et al

[Stephen]

Hello,

I have tried to find previous discussions regarding this topic using the forum search but to no avail so please forgive me if I'm re-hashing a worn topic.

I have been using fH for about 6 weeks now and have read many of the forum entries and KBs and am considering abandoning my Legacy FT and Rootsmagic in favour of this program. I have imported a basic gedcom file limited to names and dates with nothing else. My intention is to now go through the tree and add the various events/facts. etc.

To start off correctly I am hoping someone can advise me what is the "correct" way to record a cemetery/hospital etc in the {address} field when the facility undergoes a name change? A case in point: I have a mother and daughter buried in the same cemetery; the mother in the Northern Suburbs Cemetery (1972) and the daughter in the Macquarie Park Cemetery (2007).

Should I record them as two entities or as something like this: Northern Suburbs (Macquarie Park) Cemetery.

Any advice on this matter would be greatly appreciated.

[Gowermick]

Stephen,
There is no Correct way to record the Cemetery. As long as you, or anyone else understands where you meant, anything goes. I suggest that what you proposed, by putting its new name in Brackets, is perfectly acceptable. I don’t know the Cemetery, but I would understand what you meant if I read that, and to my mind, that’s what counts!

As a tip regarding normal addresses, instead of writing 24 New Road, use a format like New Road, 24 instead. This will assist the predictive text mechanism when entering a new address.

[tatewise]

Welcome to the FHUG Stephen.

As a newcomer I advise you study how_to:key_features_for_newcomers|> Key Features for Newcomers and follow its links into our Knowledge Base. For example it cross-refers to how_to:index#importing_to_family_historian|> Importing to Family Historian that has specific advice for importing from both Legacy FT and RootsMagic.

It also refers to our companion program Ancestral Sources that is extremely useful for capturing new records.

Regarding addresses changing name, that is an intersting question.
Yes, it would be logical to combine the alternative names.
Does not matter exactly how you do it providing it is consistent throughout your data.
The rest of the postal address will make it clear that it is just one location.
e.g.
Northern Suburbs General (Macquarie Park) Cemetery, Delhi & Plassey Rd, North Ryde, NSW 2113
or
Macquarie Park formerly Northern Suburbs General Cemetery, Delhi & Plassey Rd, North Ryde, NSW 2113

If necessary you can add a Note explaining the name change and when it occurred.

I suspect the two Burial Source records are both derived effectively from the same location.
So the associated Repository record could hold all the relevant contact details.

[Stephen]

Thank you both for your advice and suggestions. I will look at those KBs and keep that tip regarding normal addresses in mind.

[dewilkinson]

I am a firm believer in recording places as they were known at the time. I then use the Standardized Name and notes in the Place Record to note the details. I adopt this standard for all places, eg Clapham in "London" I would record as in Surrey until 1889, in London until 1975 then in Greater London.

[tatewise]

Yes David, but this question is about the Address field where that feature is not available.

Or are you proposing that the Address field should be avoided and everything entered into just the Place field?

[jbtapscott]

I keep Church names, etc,., in the Address field and the town, etc., in the Place field. Where there has been a change of name, or where I have identified that a church or similar has been known by two names then I include both in a single Address field, e.g. "the Parish Church (aka St. Andrew with St. Luke), [[Stoke Damerel]]".
Like David though, I do record Place Names in line with the source document so have multiple records for, say, London!

BTW: The use of the [[place-name]] differentiates identically named locations such as St. Lukes Church but in different places, whilst the [[brackets]] allow the contents to be excluded from Diagrams and Reports.

[dewilkinson]

I only use the Place and don't use the Address field. I thought long and hard and posted on this forum prior to adopting this strategy when I switched to FH and it works for me. I happen to think this is the weakest aspect of FH, coming from TMG where these were in a structured format.

[tatewise]

Yes, it is a widely adopted strategy to only use Place fields and disregard Address fields.
Tools > Fact Types can even be used to hide the Address field in the Facts tab.

I agree that some way of 'structuring' place names would be a useful feature.
But migrating such structures from product to product via GEDCOM is problematic, because the GEDCOM Spec does not cater for that, as you found when migrating from TMG.

Having said that, the GEDCOM Spec does define a sub-structure for the Address field.
It defines 1st Line, 2nd Line, City, State, Country, Postcode.
I was most dismayed that when Calico Pie introduced Place records to mange locations that they did not incorporate the Address and its structure.

As you probably know, but for the benefit of others, the only way to structure the Place field is to have a dedicated number of comma separated column parts with a preassigned meaning to each column part, such as those for the Address field.

[davidm_uk]

Yes, it is a widely adopted strategy to only use Place fields and disregard Address fields.
Tools > Fact Types can even be used to hide the Address field in the Facts tab.

So is there way of hiding Address Fields in all facts (i.e. globally) or does it have to be done individually for each fact type?

[tatewise]

Officially it must be done fact by fact.

But if you felt confident editing the C:\ProgramData\Calico Pie\Family Historian\Fact Types\....fhf files using a plain text editor then replacing Field Address=1 with Field Address=0 is a shortcut.

[davidm_uk]

Much quicker, thanks Mike.