Reference a section of place


Edward Sneithe
 

In my attempt to decide between a narrative report that looks like a list of events and a more prose type representation I have the following question.

In a Baptism record I must put the church name into the place field.. ( i know I could use the note field )

My place field looks like this:
St Patrick, 47 West High St, East Hampton, Connecticut

Everything work including geocoding. When constructing a sentence I was wondering if I could reference just the church name or the street address. perhaps like PLAC(1) Or should I use the place field for the actual address and the address field for the church name. Or I could make my own baptism fact as an attribute where I can have a value.

I am confused at this point so any suggestions would be appreciated


colevalleygirl@colevalleygirl.co.uk
 

Have a look at the TextPart function https://www.family-historian.co.uk/help/fh6/hh_goto.htm?hh_start.htm#function_textpart.html to include in a sentence.

 

However, you might also want to look at Working with Places and Addresses – Family Historian User Group (fhug.org.uk), as there are many ways of splitting Address and Place, with different pros and cons – you don’t *have* to put the church name in the place if you’re already including the full address in the place, for example (which you seem to be doing). Geocoding doesn’t take the address into account unless you  use the Map Life Facts plugin (but there are pros and cons of that approach to0.) Have a think about what’s important to you, and if you need to change anything we’ll work out what you need to do. You can even overlap information between the address field and the place field as long as you’re careful how you use each of them. You can include [[privacy markers]] in the address field to exclude them from reports etc.

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Edward Sneithe via groups.io
Sent: 14 August 2021 16:39
To: family-historian@groups.io
Subject: [family-historian] Reference a section of place

 

In my attempt to decide between a narrative report that looks like a list of events and a more prose type representation I have the following question.

In a Baptism record I must put the church name into the place field.. ( i know I could use the note field )

My place field looks like this:
St Patrick, 47 West High St, East Hampton, Connecticut

Everything work including geocoding. When constructing a sentence I was wondering if I could reference just the church name or the street address. perhaps like PLAC(1) Or should I use the place field for the actual address and the address field for the church name. Or I could make my own baptism fact as an attribute where I can have a value.

I am confused at this point so any suggestions would be appreciated


Mike Tate
 

I advise against creating your own custom Baptism attribute, because the standard Baptism Event contributes to key FH features.

For example, its Date affects the estimated date of birth and estimated age if there is no actual Birth Event date.

That applies not just to the person being baptised but sometimes close relatives too.

i.e. It is as significant as the Birth, Christening, Death, Burial and Cremation Events.

 

Mike Tate

 


Edward Sneithe
 

Colevalleygirl,

I tried the textpart but was unsuccessful. It either returned nothing or I had a syntax error and the sentence just displayed the expression. I will need to  experiment with this.

In my search from your links I did find the GetLabelledText and that may be easier to use than splitting the place field.

Sentence structure:
<Performed at {=GetLabelledText(%FACT.NOTE2%,"Church: ")} >< by the {=GetLabelledText(%FACT.NOTE2%,"Minister: ")} > <for a fee of {=GetLabelledText(%FACT.NOTE2%,"Charge: ")} >


Note field:
[[
Minister: Rev John Smith
Charge: $200
Church: St Patricks
]]

Resulting sentence:
 Performed at St Patricks by the Rev John Smith for a fee of $200


Edward Sneithe
 

Mike Thank you.

It is always nice to see how various items affect other items. I will try to avoid digging myself into that hole.


Leslie P
 

This may or may not be of use in your situation Edward, but when I decided to get "fancy" with my Occupation Attribute sentence, it took a LOT of trial and error. I got there in the end, with something that looks hairy as heck, and there may be an easier way to do it, but perhaps this will give you some ideas.

Like I said, it's the occupation attribute, so I put things like "farmer" or "store owner" or "teacher" in the attribute field. I want to keep that as simple as possible so I can easily see and count how many farmers I have, or teachers or whatever.

I do not use Addresses at all, I only use the place field to define the place that an event happened, and I keep the places all very well divided up - detail, city, county, state, country - so the 5th place item from the end will always be the name of the company, if it exists.

The sentence I want is:

no place: In 1975 Mack was a lobbyist.
no place detail: From 1933 to 1950 Homer was a farmer in Follett, Lipscomb, Texas, United States
with place detail: Katie was a teacher at Follett High School in Follett, Lipscomb, Texas, United States

The code that finally allowed me to get this is: 
{date} {individual} was {a/an value} {=ExistsText(%FACT.PLAC%, CombineText( "at ", TextPart( %FACT.PLAC%, -5), Text(" in ".TextPart(%FACT.PLAC%,-4) .", ". TextPart(%FACT.PLAC%,-3) . ", ". TextPart(%FACT.PLAC%,-2) .", ". TextPart(%FACT.PLAC%,-1))  ,Text("in ".%FACT.PLAC%)))}.

Like I said, it took ages to get this right, but this combination of TextPart, CombineText, and ExistsText seems to work to get what I want.
Hope this helps.
---
Leslie P
Houston, TX
user of: Zotero, RootsMagic, Family Historian, TNG, IMatch, ZenPhoto


@JoopvB
 

I only use the Place fact (no Address) and structure it like:
1. name of the town, village etc.
2. name of the street, sublocation etc.
3. name of the country (or state, county etc. followed by name of the country between parenthesis)
4. name of the church, hospital, graveyard, building etc.

Parts 2 to 4 are optional.
The fact definition usage is: replace {place} by {=TextPart(%FACT.PLAC%, 4)} <in {=TextPart(%FACT.PLAC%, 1, 3, TIDY)}>. This can of course be modified to one's liking.
Works nicely together with the Place list in Tools/Work with Data and also with geo-coding.

Joop van Beek


Edward Sneithe
 

Joop van Beek,

I've been looking into how I want to store address information and it appears that if I include the address as part of place I will get an entry in places for every address, OK but very voluminous. If I use the method of putting everything into the place field then I will need to ensure that I have all the proper number of commas so that country always appear at the same number in the list. That will require a lot of corrective work.

The nice thing about FH is there are always many ways to solve a problem. In my particular instance I have found many ways to get this job done. Now I need to decide and reiterating what is in the Knowledge base I will need to be consistent.

I wonder why FH does not have an option to include the address for geocoding that we need to use a plugin and the resulting information is outside of FH.

Thank you for your suggestion. Now I need to choose.

On Sunday, August 15, 2021, 06:35:05 AM EDT, j.van.beek@... <j.van.beek@...> wrote:


I only use the Place fact (no Address) and structure it like:
1. name of the town, village etc.
2. name of the street, sublocation etc.
3. name of the country (or state, county etc. followed by name of the country between parenthesis)
4. name of the church, hospital, graveyard, building etc.

Parts 2 to 4 are optional.
The fact definition usage is: replace {place} by {=TextPart(%FACT.PLAC%, 4)} <in {=TextPart(%FACT.PLAC%, 1, 3, TIDY)}>. This can of course be modified to one's liking.
Works nicely together with the Place list in Tools/Work with Data and also with geo-coding.

Joop van Beek


Mike Tate
 

To rearrange your Place &/or Address parts there is the cunningly named plugin ‘Rearrange Address and Place Parts’.

That can adjust the number of comma-separated parts, move Address parts into Place parts, etc, etc, …

 


@JoopvB
 

FH (especially with help of the numerous plugins) offers indeed a multitude of ways to implement users ideas, wishes etc.

For me this means that I've to ask myself why would I want what?". My answers to that question for the Place considerations are:
1. Places are about two things: naming and location on earth. The naming may change over time while the location stays the same. This is neatly solved in FH by using the standardized name and using the geo-location of that name. Sometimes we have Places with the same name but at a different location. Here also the standardized name and the (in this case different) geo-location help us out. In this case it's usually wise to add extra information to the name (e.g. county, province etc.) to set the names visually apart.
2. To not clutter up the narratives, I want the names to be as short as possible. So, no extensive use of state, county, province, country etc. info if, from the context of the narrative, it's obvious where the Place is expected to be located. And, due to point 1 there's always an exact reference to the location on earth.
3. Sometimes interesting information about the Place is available (e.g. the name of the hospital where a child was born, the name of a graveyard, the name of a church where people married etc. etc.). I'd like to add that in to the "Place name" to make it easily accessible within FH (see my solution for this in my former post).

For what it's worth: up until now the above approach has served me well with thousands of Places in The Netherlands, Belgium, Germany, France, the UK, the USA and a few other countries. :)


Edward Sneithe
 

If I read the GECOM 5.5.1 and the new 7.0.0 it seems that the place should contain a location like city, county, state, country. The address field should contain the entire address, multi line address as it would appear on a mailing so I assume that would be street address, city, county, state, country, zip code

Gedcom 5.5.1 page 58 says place:

"This shows the jurisdictional entities that are named in a sequence from the lowest to the highest
jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is
still accounted for by a comma."

The same standard says this about Address:

ADDRESS_STRUCTURE:=
n ADDR <ADDRESS_LINE> {1:1} p.41
+1 CONT <ADDRESS_LINE> {0:3} p.41
+1 ADR1 <ADDRESS_LINE1> {0:1} p.41
+1 ADR2 <ADDRESS_LINE2> {0:1} p.41
+1 ADR3 <ADDRESS_LINE3> {0:1} p.41
+1 CITY <ADDRESS_CITY> {0:1} p.41
+1 STAE <ADDRESS_STATE> {0:1} p.42
+1 POST <ADDRESS_POSTAL_CODE> {0:1} p.41
+1 CTRY <ADDRESS_COUNTRY> {0:1} p.41

"The address structure should be formed as it would appear on a mailing label using the ADDR and
the CONT lines to form the address structure."


 in 5.5.1 the place field is described like this on page 65:

"A comma-separated list of jurisdictional titles, which has the same number of
elements and in the same order as the PLAC structure. Entries should be in an
order where each is typically subsumed by the next.
Example — The following represents Baltimore, a city that is not within a
county.

2 PLAC Baltimore, , Maryland, USA
3 FORM City, County, State, Country"


From page 37 of the new 7.0.0 GEDCOM Standard an address is:

"A specific building, plot, or location. The payload is the full formatted address
as it would appear on a mailing label, including appropriate line breaks (encoded
using CONT (p.60) tags). The expected order of address components varies
by region; the address should be organized as expected by the addressed region."

It does not reference the person etc. at that location or naming. If I follow that standard then from my example I would have :

Place: East Hampton, Connecticut

and the address:

St Patrick,
47 West High St,
East Hampton, Connecticut, USA

including all the line breaks. If I follow this standard then the geocoding will not get the exact location but just the city location. The exact location is in the Address field. If I use this model then the geocoding is very general but the location can be dragged to the correct position thus manually making up for the lack of a street address in the place field. But that also has the drawback of not allowing for multiple locations in the same city.

It looks like the only solution for geocoding is to include the street address in the place field and extracting the components with FH functions.

I have also tried the use of labelled text in the note field, surrounded by privacy symbols like:

[[
Church: St Patricks
]]

and then in a sentence extracting the various components using FH functions.

If we are to follow the GEDCOM standard then it appears that the geocoding would be better placed on the address field rather than the Place field. It would be nice if FH gave us an option to select either or both to use  in geocoding so that 99.99% of my place fields only have City, County, State, Country and the address field has the specific street  address. 

A lot to contemplate. FH does have a way to adjust for any of these scenarios except for geocoding.

Should something like this be better defined and go on a wish list?

I hope I have not confused anyone.

On Monday, August 16, 2021, 05:57:26 AM EDT, <j.van.beek@...> wrote:


FH (especially with help of the numerous plugins) offers indeed a multitude of ways to implement users ideas, wishes etc.

For me this means that I've to ask myself why would I want what?". My answers to that question for the Place considerations are:
1. Places are about two things: naming and location on earth. The naming may change over time while the location stays the same. This is neatly solved in FH by using the standardized name and using the geo-location of that name. Sometimes we have Places with the same name but at a different location. Here also the standardized name and the (in this case different) geo-location help us out. In this case it's usually wise to add extra information to the name (e.g. county, province etc.) to set the names visually apart.
2. To not clutter up the narratives, I want the names to be as short as possible. So, no extensive use of state, county, province, country etc. info if, from the context of the narrative, it's obvious where the Place is expected to be located. And, due to point 1 there's always an exact reference to the location on earth.
3. Sometimes interesting information about the Place is available (e.g. the name of the hospital where a child was born, the name of a graveyard, the name of a church where people married etc. etc.). I'd like to add that in to the "Place name" to make it easily accessible within FH (see my solution for this in my former post).

For what it's worth: up until now the above approach has served me well with thousands of Places in The Netherlands, Belgium, Germany, France, the UK, the USA and a few other countries. :)


Mike Tate
 

Yes, the FHUG Knowledge Base ‘Working with Places and Addresses’ explains similar options:

https://fhug.org.uk/kb/kb-article/working-with-places-and-addresses-for-new-users/

 

Family Historian allows some deviation from the GEDCOM specification, as do most products.

IMO the omission of Address from geocoding was a mistake.

 

I advise that you format your Place and Address data to suit your use of FH rather than adhere to the GEDCOM specification too closely.

 

Mike Tate

 

 


Edward Sneithe
 

Mike,

I was thinking that if we use  place field like Address, City, County, State, Country that we re dependent on properly placed commas for missing data. I know you can't speak for FH but it would seem nice that when we are entering a place that we could get a formatted scree for all the possibilities for place and then FH would properly format the place field with comma for missing data.

Just a thought. It would make entering and extracting individual pieces more reliable

On Monday, August 16, 2021, 12:46:03 PM EDT, Mike Tate <post@...> wrote:


Yes, the FHUG Knowledge Base ‘Working with Places and Addresses’ explains similar options:

https://fhug.org.uk/kb/kb-article/working-with-places-and-addresses-for-new-users/

 

Family Historian allows some deviation from the GEDCOM specification, as do most products.

IMO the omission of Address from geocoding was a mistake.

 

I advise that you format your Place and Address data to suit your use of FH rather than adhere to the GEDCOM specification too closely.

 

Mike Tate

 

 


Victor Markham
 

When I enter a place name in England I always give the place name it's full name.

When it copmes to county names I always stick to the ancien boundary names. What we see today are known as administration boundary.

As an example let's say Sheffield. If someone lived thewre in the 1960's or earlier they would be in West Yorkshire. When the boundary changed Sheffield became South Yorkshire, which is an admin boudary. I wouldn't bother to change thinghs from West to South. This sort of thing has happened all over the country so I stick to the old names. The boundaries are going through another change so it would mean one has to change things again if they do that.

This is how I do place names

anytown, anycounty, England (in one row)

Followed by any street in the second row

Both rows are separate on FH so it is easy to add the two addresses

I would put the full name of the place like Kingston Upon Hull not just Hull

When it comes to Yorkshire I would add East, North or West to Yorkshire. There are similar place names in say East Yorkshire and North Yorkshire (Scalby fr example) so one needs to know which is the right place

Victor

On 16/08/2021 5:57 pm, Edward Sneithe via groups.io wrote:
Mike,

I was thinking that if we use  place field like Address, City, County, State, Country that we re dependent on properly placed commas for missing data. I know you can't speak for FH but it would seem nice that when we are entering a place that we could get a formatted scree for all the possibilities for place and then FH would properly format the place field with comma for missing data.

Just a thought. It would make entering and extracting individual pieces more reliable

On Monday, August 16, 2021, 12:46:03 PM EDT, Mike Tate <post@...> wrote:


Yes, the FHUG Knowledge Base ‘Working with Places and Addresses’ explains similar options:

https://fhug.org.uk/kb/kb-article/working-with-places-and-addresses-for-new-users/

 

Family Historian allows some deviation from the GEDCOM specification, as do most products.

IMO the omission of Address from geocoding was a mistake.

 

I advise that you format your Place and Address data to suit your use of FH rather than adhere to the GEDCOM specification too closely.

 

Mike Tate

 

 


Andrew Braid
 

Victor

Sheffield has never been in West Yorkshire. It was in the West Riding of Yorkshire until reorganisation.

Yorkshire is challenging from a geographic standpoint. Formerly three ridings and an Ainsty and now North, East, West and South plus Humberside and Teesside. And it's all about to change again

Like you I always use the old names.

Andrew 

On Mon, Aug 16, 2021, 18:13 Victor Markham via groups.io <victor=markham.me.uk@groups.io> wrote:

When I enter a place name in England I always give the place name it's full name.

When it copmes to county names I always stick to the ancien boundary names. What we see today are known as administration boundary.

As an example let's say Sheffield. If someone lived thewre in the 1960's or earlier they would be in West Yorkshire. When the boundary changed Sheffield became South Yorkshire, which is an admin boudary. I wouldn't bother to change thinghs from West to South. This sort of thing has happened all over the country so I stick to the old names. The boundaries are going through another change so it would mean one has to change things again if they do that.

This is how I do place names

anytown, anycounty, England (in one row)

Followed by any street in the second row

Both rows are separate on FH so it is easy to add the two addresses

I would put the full name of the place like Kingston Upon Hull not just Hull

When it comes to Yorkshire I would add East, North or West to Yorkshire. There are similar place names in say East Yorkshire and North Yorkshire (Scalby fr example) so one needs to know which is the right place

Victor

On 16/08/2021 5:57 pm, Edward Sneithe via groups.io wrote:
Mike,

I was thinking that if we use  place field like Address, City, County, State, Country that we re dependent on properly placed commas for missing data. I know you can't speak for FH but it would seem nice that when we are entering a place that we could get a formatted scree for all the possibilities for place and then FH would properly format the place field with comma for missing data.

Just a thought. It would make entering and extracting individual pieces more reliable

On Monday, August 16, 2021, 12:46:03 PM EDT, Mike Tate <post@...> wrote:


Yes, the FHUG Knowledge Base ‘Working with Places and Addresses’ explains similar options:

https://fhug.org.uk/kb/kb-article/working-with-places-and-addresses-for-new-users/

 

Family Historian allows some deviation from the GEDCOM specification, as do most products.

IMO the omission of Address from geocoding was a mistake.

 

I advise that you format your Place and Address data to suit your use of FH rather than adhere to the GEDCOM specification too closely.

 

Mike Tate

 

 


Victor Markham
 

Of course it is the West (East or North) Riding of Yorkshire but for address purposes on FH West, East or North simplifies things.

Writing letters in those far off days people simply wrote East, North or West and that is sufficient clarity

Victor

On 16/08/2021 6:34 pm, Andrew Braid wrote:
Victor

Sheffield has never been in West Yorkshire. It was in the West Riding of Yorkshire until reorganisation.

Yorkshire is challenging from a geographic standpoint. Formerly three ridings and an Ainsty and now North, East, West and South plus Humberside and Teesside. And it's all about to change again

Like you I always use the old names.

Andrew 

On Mon, Aug 16, 2021, 18:13 Victor Markham via groups.io <victor=markham.me.uk@groups.io> wrote:

When I enter a place name in England I always give the place name it's full name.

When it copmes to county names I always stick to the ancien boundary names. What we see today are known as administration boundary.

As an example let's say Sheffield. If someone lived thewre in the 1960's or earlier they would be in West Yorkshire. When the boundary changed Sheffield became South Yorkshire, which is an admin boudary. I wouldn't bother to change thinghs from West to South. This sort of thing has happened all over the country so I stick to the old names. The boundaries are going through another change so it would mean one has to change things again if they do that.

This is how I do place names

anytown, anycounty, England (in one row)

Followed by any street in the second row

Both rows are separate on FH so it is easy to add the two addresses

I would put the full name of the place like Kingston Upon Hull not just Hull

When it comes to Yorkshire I would add East, North or West to Yorkshire. There are similar place names in say East Yorkshire and North Yorkshire (Scalby fr example) so one needs to know which is the right place

Victor

On 16/08/2021 5:57 pm, Edward Sneithe via groups.io wrote:
Mike,

I was thinking that if we use  place field like Address, City, County, State, Country that we re dependent on properly placed commas for missing data. I know you can't speak for FH but it would seem nice that when we are entering a place that we could get a formatted scree for all the possibilities for place and then FH would properly format the place field with comma for missing data.

Just a thought. It would make entering and extracting individual pieces more reliable

On Monday, August 16, 2021, 12:46:03 PM EDT, Mike Tate <post@...> wrote:


Yes, the FHUG Knowledge Base ‘Working with Places and Addresses’ explains similar options:

https://fhug.org.uk/kb/kb-article/working-with-places-and-addresses-for-new-users/

 

Family Historian allows some deviation from the GEDCOM specification, as do most products.

IMO the omission of Address from geocoding was a mistake.

 

I advise that you format your Place and Address data to suit your use of FH rather than adhere to the GEDCOM specification too closely.

 

Mike Tate

 

 


David F
 

Is the basic problem that geocoding "puts a pin in a map"?

Places are areas, whilst addresses are much closer to points.

If you want to check who lived in a house through a period of time, or who were close neighbours, you probably want point-mapping (which either has to be "full-address" based or manually adjusted). If you are trying to show general migration (say from "Ireland" to "USA" or even "Cork" to "New York State") you probably want area-mapping.

Reducing an area to a point can be misleading; USA gets reduced to a point somewhere in Kansas, Australia gets reduced to somewhere close to Alice Springs.

Trouble is area-mapping requires definition of numerous points on sometimes complex boundaries - unless the system can piggy back on another existing mapping system that already understands areas. Even then, genealogists will want to define places like "Yorkshire, West Riding" which modern mapping systems no longer recognise!

David


Edward Sneithe
 

I want the point ability since I want to locate very closely where ancestors lived, traveled, etc. One task I have that I have not yet found a suitable platform is to be able to map  very specific migration pattern. I also need to add waypoints to adjust the migration path so I don't get unrealistic results. If I want to map Miami to Boston it takes a path out over the Atlantic when in reality the path would be through Florida, Alabama, Carolinas, etc.

Some people even want to go as fine as the location of a single grave in a cemetery

So far I can get the ability to map a path or reasonable maps but not both in the same product. It would be nice if I could map a path in FH.


I can adjust FH data to align with what I want without the waypoints.



On Monday, August 16, 2021, 01:58:44 PM EDT, David F <fhug-forum@...> wrote:


Is the basic problem that geocoding "puts a pin in a map"?

Places are areas, whilst addresses are much closer to points.

If you want to check who lived in a house through a period of time, or who were close neighbours, you probably want point-mapping (which either has to be "full-address" based or manually adjusted). If you are trying to show general migration (say from "Ireland" to "USA" or even "Cork" to "New York State") you probably want area-mapping.

Reducing an area to a point can be misleading; USA gets reduced to a point somewhere in Kansas, Australia gets reduced to somewhere close to Alice Springs.

Trouble is area-mapping requires definition of numerous points on sometimes complex boundaries - unless the system can piggy back on another existing mapping system that already understands areas. Even then, genealogists will want to define places like "Yorkshire, West Riding" which modern mapping systems no longer recognise!

David