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.
|
|
|
|
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, 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. 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.
|
|
|
|
@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
|
|
|
|
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. :)
|
|
|
|
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:
|
|
|
|
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
|
|
|
|
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:
|
|
|
|
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
|
|
|