* Re: Difference between Address List and Repository Address

[Gary_G]

I read over an old post by PeterR on the topic; "Correct usage of 'Place' and 'Address'" at viewtopic.php?t=6658#p29125. So; I thought that I should confirm my current practise regarding addresses.

In other programs, I have been used to using the Address that are associated with a fact to define the "Street Address". I used the Address in a Repository to define the "Mailing Address" for the repository. To me; there seems no real conflict, since many places have a mailing address that is different from the geographic location implied by a street address. That doesn't, however, mean that the street and mailing address couldn't be the same and I used to enter it both places where applicable.

I should note; I tend to think of correspondence as a transfer of information from one repository to another. That means that I have one repository for a sender and one for a receiver; each with their own contact info. In this case, I wouldn't have any street address defined elsewhere.

> Did I miss some nuance about the use of the two locations for recording an address?

I notice that in the out-of-the-box FH7, there doesn't appear to be a place to enter the postal address data, despite it being present as a sub-element of the Address of a repository. This could just be my unfamiliarity with the interface. I checked the Help file, but didn't see an obvious reference to how to enter the data.

> Do I have to define the repository "mailing address" input fields using the customization feature of the repository input pane?

[tatewise]

The Repository record use of Address fields is completely independent of the Fact use of Place and Address fields.

The Repository Address provides whatever details you consider necessary to contact the Repository in order to retrieve Source documentation from that Repository. They will usually be current addresses.

The use of Place and Address fields for Facts depends on the context of the Fact.
e.g. Birth, Baptism, Census, Marriage, Death & Burial events would define where those events happened.
FHUG KB Working with Places and Addresses explains the strategies popular among users with their pros & cons which are mainly associated with geocoding latitude/longitude.
They will usually be historical and contemporary with the Facts.

The GEDCOM data structure specification has the same syntax for both uses of the Address field, but the semantics differ.

[Gary_G]

Thanks for the info, Mike. I'll have to read that reference later.
I've no problems accessing the forums, but the Knowledge base has started to give me access issues again.

[Gary_G]

I switched to the London VPN server and the issues "seem" to have gone away.

I was then able to find and read the KB article you mentioned.

I've always used the "Distinct Places and Addresses" approach. It may be a French thing, but it's difficult enough to get accurate geolocations for a commune without trying to locate specific buildings. Trying to cover all aspects of the address & location as place elements in France is fraught with danger as below the 4 fairly standard upper place fields, the number of remaining fields can vary somewhat widely. Places like France and Lyon are great examples of non-standard detail in addresses.

In the fact records, I've found referencing the current name is allows me to automatically get coordinates for a place. Because I've written my French templates as I have, I record the current and historic place names in the Places list. The citation makes it clear as to what the historic place name was and where the records are now located. I then go in and copy the coords of the new name to the old name. Doing this makes repeated template data entry a little less prone to error as some registrars had rather poor penmanship. Choosing places from a pick list reduces the risk of error.

[AdrianBruce]

... I've always used the "Distinct Places and Addresses" approach. It may be a French thing, but it's difficult enough to get accurate geolocations for a commune without trying to locate specific buildings. ...

For my UK stuff, my default process is to just put settlements into the Places and geocode them. However, recently, I have "promoted" some types of specific buildings (churchs, graveyards, hospitals, e.g.) to being Places in their own right. It may be inconsistent but I disliked having my father's Place of death, for instance, appearing on a map in the middle of the fields, simply because that's where the hospital's nearby settlement is centred.

But yes, in general, specific buildings are way too difficult to geocode - even churchs can be difficult to find if the detailed maps are the wrong side of a slum clearance and redevelopment that swept away all trace of the church.

[tatewise]

Gary, are you aware of the Place record's ability to store two place names?
The main Place name should be the historic version as recorded contemporaneously on the source documents.
The Standardized name should be the current name that works best for automatic geocoding.

[Gary_G]

Yes; I was aware of it, but was being cautious. I wasn't sure if a template could select it from a list as it can with the main place name. Nevertheless; I'll see what I can do. Thanks for the suggestion, Mike.