* Address and Place, yet again

Questions regarding use of any Version of Family Historian. Please ensure you have set your Version of Family Historian in your Profile. If your question fits in one of these subject-specific sub-forums, please ask it there.
Post Reply
avatar
NigelBrown
Diamond
Posts: 68
Joined: 27 Apr 2015 21:12
Family Historian: V6.2
Location: Wolverhampton, UK
Contact:

Address and Place, yet again

Post by NigelBrown »

Yesterday's (21 Sep 2016) Preferred Format for Places (14212) thread has prompted me to ask a question or two, which I have been rehearsing for a while. After 18 months of testing and trying (and liking) Family Historian, and modifying my Master Genealogist (TMG) project to improve the Direct Import even further, I am now ready to make the move, bar one issue. Address and Place. Please excuse a fairly long message.

I understand the GEDCOM distinction, where address = "as it would appear on a mailing label", and place = "jurisdictional name of the place". However, the more I think about it, the less clear I am as to why I need to use both when recording what we may generically call "location" of an event. (In TMG I have worked for 15 years with just one.) So I have considered using either one or other of Address or Place for all fields but nothing I have read on the Forum seemed to support this approach, until yesterday when I read (in Preferred Format for Places):

"David's scheme though, is not the usually recommended way of using places, as he includes Addresses in his Places data. Used the usual way, 3 columns would suffice for Places." The only reason that I've adopted this approach is so that I can add media (photos) to places right down to address level, e.g. a photo of the house where my ancestors lived at Mead Cottage, 40, London Road, Woolcroft Green, Stevenage, Hertfordshire, England. Hence the 7 place fields. I know that some others on here have done the same thing for this reason, I wasn't the first."

So why do we continually discuss the formats and overlaps between Address and Place when just one will do? Or do we need both but for different things? And does the one have to be Place, why not Address? I am sure I will want to link photos to places down to address level too.

But back to a more normal approach. I have created a table to show the scheme I have in mind and look forward to comments. Notwithstanding the idea of using just one (or the other), Address or Place, I would welcome some advice, especially the pros, cons, shortcomings and any pitfalls of what I propose. For the time being I am not much interested in mapping, but I am sure I will be in the near future.
Address-Place.png
Address-Place.png (8.61 KiB) Viewed 11464 times
I can use the Rearrange Address and Place Parts plugins, and I can use the Tools/Work with Data ... Places and Addresses, and I can amend Fact Definitions. So far so good. And I understand that the two can contain overlapping fields, and I have experimented with using a combination of both in my Fact Definitions (using "<at {address}> {place}"), but I do not see how I can then stop report outputs repeating the overlapping (repeated) elements.

In my scheme I know I could, perhaps should, separate House No. from Street and maybe I will. Also, I could avoid overlap by stopping the Address at Village/District, but then it is not as it would appear on a mailing label. When I address an envelope, which presumably is the same as a mailing label, I invariably include all of my ADDRess elements, including Country if its going abroad, so what does PLACe add to the location description of an event/fact? Not much, it seems to me, but it does omit a lot if as per my proposal. Perhaps I should amend all Fact Definitions to have only ADDRess, and reserve PLACe for geo-coding, or not do Place at all? Are there any reports or anything else that require PLACe instead of or in addition to ADDRess?

As well as reading and re-reading all the past Forum debates on this vexed topic, I have looked for guidance in these matters to Family Historian Help, but an Index search on "address" brings up only one entry, which says "Addresses (see Residences)", and following that link tells me nothing useful as far as I can see. I have read "Getting the Most from Family Historian 6", and Address does not even appear in the Index, although Place does, but nothing there helps me answer my current questions as far as I can see. The Fact Tag in the Property Box has boxes for both Place and address but I can see nothing that says what best goes in what box. Finally, I looked at the Sample Project and was bewildered and a little amused to see in Work with Data - Addresses that "Cheltenham" appears in Parts 2 and 3 (so much for consistency), while Part 1 is a mix of both Streets and Building Names. Meanwhile, in Work with Data - Places, Part 2 includes cities, counties and countries. I think I am right in saying that if you run an Individual Narrative Report for Anthony Edward Munro, we are told that "Tony was baptised in June 1927 in Cheltenham." It does not tell us the name of the church because that is recorded in Address not Place.

I guess someone might tell me that all this shows how "flexible" FH is, and how different users can define things to work how they want it to, and that is fine. But for now, I really would like to get it right first time for me, and I am not even sure I am on the right lines. My mind is so unmade up I feel like asking someone to just tell me what to do! Help! And thank you in advance.

Nigel Brown
Nigel Brown - https://vousden.one-name.net
Vousden One-Name Study - https://vousden.one-name.net
avatar
jbtapscott
Megastar
Posts: 513
Joined: 19 Nov 2014 17:52
Family Historian: V7
Location: Corfu, Greece
Contact:

Re: Address and Place, yet again

Post by jbtapscott »

I probably can't add much to what you have said, but I came over from TMG with just the one set of "locations". After some thought, I decided to split the likes of house and street names (and in some circumstances, village) in to the Address data and keep Town, County / State in the Place data. I do not duplicate Town / Country, etc., data in both Address and Place records. I utilised the plugin to achieve quite a bit of this (as well as tidy it up) and, as I move through my project reviewing / updating data, I manually make the changes if I find data that does not meet the criteria as indicated above.

In terms of Fact sentences, I have modified most to include both Address and Place data, with liberal use of the angle brackets to exclude reference to Address fields if there are none (e.g. "<br>{individual} was born {date}< at {address}> {place}").

In essence, there is no right or wrong way - primarily because the "old" Gedcom standard seems to be encouraging duplication of data.
Brent Tapscott ~ researching the Tapscott and Wallace family history
Tapscott & Wallace family tree
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Address and Place, yet again

Post by tatewise »

Nigel, that is quite a lucid summary, and as you have found, it is a long-standing area of debate.

First the Gedcom differences between Place and Address :-
If you visit the All tab of a Property Box and right-click any Fact you can add Place and Address fields.
Right-click on those two fields, and you can add quite different sub-fields to them, as required by Gedcom.

Now the FH differences between Place and Address :-
I think you are aware of their differences in Diagrams and Reports, and how the Options affect them.
Place fields are linked to Place Records but Address fields are just text fields.
See the Places tab & Property Box of the Records Window for further details.
Only Place Records can be Mapped with Lat/Longitude and have Media images attached.
So if you want to map locations and attach media, then you must use Places and NOT Addresses.
That is the explanation for many of the recent debates for moving all location details into Place fields.

FYI:
In the UK there is often a significant difference between jurisdictional name and postal address of the same location.
The jurisdictional Registration District (Town) & County for BMD events can be quite different to the Town & County postal address.
Yes, even the County can be different, and over history the same location can be designated to different Counties.
It makes recording Family History something of a challenge.

Yes, FH is flexible, and your decision of what to record where hinges on how you wish to use your data: Mapping and Media, which Diagrams, which Reports, which Queries, etc.

BTW: By using the =TextPart() function it should be possible to avoid the duplication of overlapping parts of Place and Address in Narrative Reports.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
Gowermick
Megastar
Posts: 1702
Joined: 13 Oct 2015 07:22
Family Historian: V7
Location: Swansea

Re: Address and Place, yet again

Post by Gowermick »

Nigel,

The simplest way to think of places and addresses, is to consider your postcode, which form part of your 'single address'.

When mail is collected, the originating sorting office only looks at the first part of the postcode (Place), so it knows which destination sorting office to send it to. The receiving sorting office then looks at the second half of the postcode (address) to decide which postman to give it to for delivery.

FH works in a similar way, Places are the towns and cities, and addresses are the house etc within the city. It really makes data input easier if you split it up that way, but as David pointed out, it would seem that you can only attach media to a Place, not an address, so to get round this limitation, David has combined the two into his Places, solely so he can attach media to it.
Mike
Mike Loney

Website http://www.loney.tribalpages.com
http://www.mickloney.tribalpages.com
User avatar
LornaCraig
Megastar
Posts: 3190
Joined: 11 Jan 2005 17:36
Family Historian: V7
Location: Oxfordshire, UK

Re: Address and Place, yet again

Post by LornaCraig »

I use separate addresses and places, with no data overlap.

On the question of linking media, you need to consider how you might use any pictures you link to a place. Bear in mind that if you set Report Options to show pictures of places you may get a lot of duplication because many people will be linked to the same place. This is likely to be true even if you specify places down to address level.

The media I link to places are mainly general views and copies of old town maps. In the Report Options for pictures I don't normally include pictures of places, but sometimes insert them manually at the end.

For pictures of a specific address (house, church, school) I create a Source record with the Source type 'Building'. In addition to linked pictures the Source record can hold notes about the history of the building, who lived there and when, etc. I then cite the Source against facts which use that address. If I feel it is appropriate I can opt to display Source pictures at the end of the report, or insert a separate Source Report for selected 'Building' Sources. Either way this again avoids duplication of pictures.

(By the way, I too have noticed the inconsistency in the places and addresses in the FH sample project. Perhaps we should have a word with Calico Pie about that!)
Lorna
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Address and Place, yet again

Post by AdrianBruce »

Nigel
For what it's worth, I think that the reason discussions keep rolling on is that the basic GEDCOM structure is flawed at this point - or perhaps - it's UK users who are flawed! Because of the flaws, each of us makes our own decision, with our own trade-offs driven by our own criteria (a.k.a. prejudices if you don't agree with mine!) and potentially each decision will be in a different place.

Many of us have a distaste for the duplication between Address and Place. However, it is at least arguable that the duplication doesn't exist if you follow the GEDCOM specification. The Place hierarchy is driven by jurisdiction, the Address hierarchy by postal. Thus if I were to enter a Place for nearby Alsager, it could include "Alsager, Cheshire" because Cheshire was the County Council at that time. But the post went via Stoke, so I believe the (postal) address would be "Alsager, Staffordshire". Hence under these circumstances, there is no duplication at the town-county level. (OK the town element is still duplicated but that needs much more complex representation if we are to remove that issue.)

It is not, however, an argument I care much for - firstly what the heck is a postal address before the Penny Black (say)? And which jurisdiction would you care to use out of local government, ecclesiastical, registration....?

You ask reasonably - why not concentrate just on one? There are, as referred to above, limitations in what FH and the plug-ins use for geocoding, for starters. I am also reluctant to stray too far from the classic GEDCOM usage because the more I do that, the more risk there is that any use of my data in other software won't work. For me, what I have done is simply to slice away any duplication between Address and Place by having Addresses that contain simply "200 High Street" or "St. Mary's" (say). Others don't like this because it makes the "work with address" stuff difficult as there are lots of "St. Mary's" in different towns. If I wanted to correct my addresses of "St. Mary's" in the place of Nantwich to "St. Mary & St. Nicholas", it is trickier for me to do the selection than if I used an address of "St. Mary's, Nantwich, Cheshire" in the first place.

By the way, FamilySearch FamilyTree has just one item for the address and place combined. Except... It doesn't, because behind the scenes - but not always behind the scenes - it uses a standardised place that works effectively at the level of the current place, allowing you to prefix the place with the address in the visible "place".

I can offer you no definitive answers - these are just a few thoughts to help you come to your own decision. And the old joke that "If you think you understand Places and Addresses, you clearly don't".
Adrian
avatar
jbtapscott
Megastar
Posts: 513
Joined: 19 Nov 2014 17:52
Family Historian: V7
Location: Corfu, Greece
Contact:

Re: Address and Place, yet again

Post by jbtapscott »

Reference Adrian's "St Marys" example, I get around this by including the town (or whatever) in the second column of the Address data using the double square brackets to ensure the reference does not get included in reports (e.g. "St Mary's Church, [[Bridgwater]]". Yes, I end up with quite a few " St Mary's" but it makes corrections / changes easier.
Brent Tapscott ~ researching the Tapscott and Wallace family history
Tapscott & Wallace family tree
avatar
Gowermick
Megastar
Posts: 1702
Joined: 13 Oct 2015 07:22
Family Historian: V7
Location: Swansea

Re: Address and Place, yet again

Post by Gowermick »

At the risk of prolonging the debate, as far as I see it, the 'address' is simply a piece of text which forms part of a list within FH, to aid autocomplete when entering an address. If one thinks this way, 'St Mary's' itself has no meaning until it is associated with a Place i.e Place + Address, in the same way that High Street only has meaning when it too is associated with a Place. I think no-one would add a qualifier to explain what High Street they were referring to, but simply rely on its association with a Place to make it clear which one!
Mike Loney

Website http://www.loney.tribalpages.com
http://www.mickloney.tribalpages.com
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Address and Place, yet again

Post by tatewise »

Brent's technique of using the [[privacy brackets]] is a novel one that has merit.
It not only differentiates otherwise identical Addresses, so that Work with Data global changes can be made, but it automatically avoids duplicating overlapping parts in Reports.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
arthurk
Superstar
Posts: 366
Joined: 31 Jan 2015 20:24
Family Historian: V7

Re: Address and Place, yet again

Post by arthurk »

tatewise wrote:Brent's technique of using the [[privacy brackets]] is a novel one that has merit.
It not only differentiates otherwise identical Addresses, so that Work with Data global changes can be made, but it automatically avoids duplicating overlapping parts in Reports.
This is an idea that I came up with too - see my post of 1 Feb 2015 in Place and Address - Appearance in Reports etc. (12244). In fact Mike (tatewise) made a similar response then:
Arthur, thank you for thinking outside the box and talking about [[ bracketed ]] private Addresses.
Yes, to my amazement that works.
e.g.
If the Place is Cheltenham, Gloucestershire, England and the Address is St Mary's Church, [[Cheltenham]] then the bracketed [[Cheltenham]] is governed by the Report Option to Inc. [[private]] Notes.
In fact that Report Option governs [[private]] text in any long (multi-line) text field such as Note, Address, Text From Source, Author, Publication Info, etc, but NOT short text fields such as Place, Where Within Source, Individual Names, etc.
I haven't actually managed to implement the idea for myself yet, but I will in time....
avatar
NigelBrown
Diamond
Posts: 68
Joined: 27 Apr 2015 21:12
Family Historian: V6.2
Location: Wolverhampton, UK
Contact:

Re: Address and Place, yet again

Post by NigelBrown »

Thank you all for so many helpful comments. Clearly, as I knew already, there is no straightforward answer, but it seems there are workarounds, compromises, etc. Compromising on the full "mailing label" for Address seems to be widely practised, combined with copious use of "<at {address}> {place}" in Fact Definitions. Arthur's/Brent's [[privacy brackets]] is ingenious. I have had a quick go and certainly it works in narrative reports, of course, although all the brackets still show in the Property Box Sentence which looks a bit odd.

Mike, you mentioned that by using the =TextPart() function it should be possible to avoid the duplication of overlapping parts of Place and Address in Narrative Reports. This is very interesting and new to me. I have looked at the the couple of examples in the Knowledge Base, and see that for example, =TextPart( %INDI.BIRT.PLAC%, 3, 1, STD ) gives 3rd comma separated part of Birth Place and =TextPart( %INDI.DEAT.ADDR%, 2, 1, STD ) gives 2nd comma separated part of Death Address. I sort of understand what these mean, but I don't know where to go next. I don't know how to create or use them, or whether they work for other Facts such as Education and Graduation, or for Custom Facts (not so good if they can't). And do they cope with blank fields, etc. Most Facts involve location and ideally I could do with a catchall construct that I can understand and adapt easily.

I see that Family Historian Help on Expressions is headlined: "This topic is for advanced and technically-minded users only." It continues: "There is no need for any user to ever learn or know anything about expressions." I must say that I would prefer to get on with my family history rather than learn the inner workings of Expressions. Is there a Simple Guide to deploying Expressions that will avoid the duplication of overlapping parts of Place and Address in Narrative Reports?

Mike again, you say that my decision of what to record where hinges on how I wish to use my data: Mapping and Media, which Diagrams, which Reports, which Queries, etc. The answer of course is that I do not yet know, I just know that I surely will want to use all these in the future. But I don't want to have to re-invent the wheel every time I want to do something new. Sorting out my Addresses/Places once will be quite enough for me!

Finally Lorna, I will write to Calico Pie about inconsistency in the Sample Project.

Thanks again, and I do feel that a solution may be in sight.

Nigel
Nigel Brown - https://vousden.one-name.net
Vousden One-Name Study - https://vousden.one-name.net
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Address and Place, yet again

Post by tatewise »

The reason the [[parts]] appear in the Facts tab Sentence and not in Narrative Reports is they are governed by the Report > Options > Main tab Inc. [[private]] Notes setting, which defaults to exclusion.

However, the Fact Sentence cannot pre-guess which setting will apply in any particular Narrative Report, so it shows everything.

Although, [[private brackets]] in the Note field are excluded by the {note} code in the Facts tab Sentence.

So perhaps that anomaly should be reported to Calico Pie.

There is no "Simple Guide to deploying Expressions" because as the Help says it is an advanced topic, but to get the most out of FH, just like Data References, they are well worth understanding. Otherwise, many features of Diagrams, Reports, Queries, Records Window Columns, Fact Sentence Templates, etc, will be closed to you. However, the FHUG is here to help you. See how_to:understanding_expressions|> Understanding Expressions for some clues.

For the =TextPart() function to avoid duplication, your Address & Place fields must use column parts consistently.
To define global Fact Sentence Templates, use Tools > Fact Types and Edit each Fact where you can investigate the Template Codes.
The =TextPart() function has four parameters:
  1. The Data Reference of the Address field for any Fact, and in Sentence Template is always %FACT.ADDR%.
  2. The column part number to start from, and in this case will always be 1.
  3. The number of column parts to retain, and in your case will always be 3 based on your original posting.
  4. TIDY to remove blank comma parts.
The function is then replaced by the first 3 column parts of the chosen Address with blank comma parts removed.

So wherever your Sentence Template would have used the {address} code, even within < at {address}>, replace it with {=TextPart(%FACT.ADDR%,1,3,TIDY)} to include the first 3 column parts of Address.

Unfortunately, just as with any new software package, you have to familiarise yourself with its features in order to make wise decisions about how to use it well. Does not matter whether it is Family Historian, MS Word, or a Photo Editor.

It won't take too long to become familiar with the Reports you are likely to use.
The same Report > Options for [[private]] Notes apply to the most popular Individual Summary Report, Family Group Sheet, and Narrative Reports. Sentence Templates only apply to Narrative Reports.

If you get it right for those Reports then it will probably be satisfactory for Diagrams, etc, but it does not take long to check a few cases.
One point to note is that [[parts]] in Address fields are NOT governed by the Inc. [[private]] Notes setting in Diagrams. I think Calico Pie have been informed.

Mapping and Media are crucial, because those features do NOT apply to Address fields. So if you want to link Media to a particular location such as a Church photo, then that location must be recorded in a Place.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
BobWard
Superstar
Posts: 420
Joined: 18 Nov 2012 01:50
Family Historian: V6.2
Location: Mesa, Arizona, USA

Re: Address and Place, yet again

Post by BobWard »

U.S. user here. My approach has always been to just use the PLACE box for everything, e.g., street address (when needed), city/town, township, county, country - all go in the PLACE box. I do not use the ADDRESS box at all.

I also manually assign specific coordinates to each PLACE to make sure it is pinpoint accurate. As soon as I enter a PLACE value with an initial set of coordinates, I check its location on the FH map and zoom in to make sure I have the map marker on a specific street location (if an address is part of the PLACE name), or, on a specific structure if a church, school, etc. is being named. Minor adjustments of the map marker just require dragging the map marker to the exact spot that you want.

I am not an FH "power-user" though, I just try to keep things as simple as possible.
avatar
NigelBrown
Diamond
Posts: 68
Joined: 27 Apr 2015 21:12
Family Historian: V6.2
Location: Wolverhampton, UK
Contact:

Re: Address and Place, yet again

Post by NigelBrown »

Finally (?), thank you all again for your help. I have decided to go down the road of keeping it simple, using Place only, for the time being at least. Yesterday evening I found another Forum discussion on this same topic from January 2015, entitled 'Place and Address - Appearance in Reports etc.' It covers a lot of the same ground and I wish I had found it earlier. I have written to Calico pointing out the inconsistencies in the Sample Project.
Nigel Brown - https://vousden.one-name.net
Vousden One-Name Study - https://vousden.one-name.net
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Address and Place, yet again

Post by tatewise »

Nigel, with that approach you may need to adjust the Fact Sentence Templates for Narrative Reports.

Typically they say John Smith lived in Wolverhampton, England which is fine if no address parts.
This is because the {place} code automatically adds the in prefix.
John Smith was baptised in St. Mary's Church, Wolverhampton, England is OK.
John Smith was born in St. Mary's Hospital, Wolverhampton, England is OK.
Although, at would work just as well for those instead of in.

But, John Smith was born in 10, High Street, Wolverhampton, England is not ideal.
And John Smith was born at 10, High Street, Wolverhampton, England is much better.

In general, if there are address parts in the Place it should be prefixed by at and otherwise by in.
If you have 3 address part columns then each Sentence Template code {place} needs replacing with:
{=CombineText( TextIf( TextPart(%FACT.PLAC%,1,3,TIDY) = "", " in ", " at "), %FACT.PLAC:TIDY%, , )}
The CombineText() function displays nothing if the Place field is empty.
The TextIf() function chooses the prefix " in " if first 3 Place parts are blank, otherwise chooses " at ".
The TextPart() function extracts the first 3 Place parts and tidies the , separators.
The %FACT.PLAC:TIDY% data reference tidies the Place field just like the {_place} code.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
jimlad68
Megastar
Posts: 921
Joined: 18 May 2014 21:01
Family Historian: V7
Location: Sheffield, Yorkshire, UK (but from Lancashire)
Contact:

Re: Address and Place, yet again

Post by jimlad68 »

late reply I'm afraid, but I like your topic title ...yet again . Yet again I'll add my 2 pennyworth. I too came from TMG and liked the place/address structure there, one of the simpler and logical aspects of TMG. But since moving to FH and with the introduction of GPS/Geocoding I completely revised my thinking, rather than repeat again I will just direct you to one of the many topics in this area:
Rearrange Address and Place Parts Plugin (12330) in particular my latest method which has worked well for me (there were many before) detailed at:
Postby jimlad68 » 28 Mar 2015 17:43 http://fhug.org.uk/forum/viewtopic.php?p=60520#p60520
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Address and Place, yet again

Post by tatewise »

Jim, how do you handle your reversed Place arrangement in Narrative Reports?
e.g.
John Smith was born in England, Wolverhampton, St. Mary's Hospital. does not appeal to me!
Also the Report > Option > Use Short Form for Repeated Place Names will not work well, because it will truncate down to just the first Place part.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
jimlad68
Megastar
Posts: 921
Joined: 18 May 2014 21:01
Family Historian: V7
Location: Sheffield, Yorkshire, UK (but from Lancashire)
Contact:

Re: Address and Place, yet again

Post by jimlad68 »

Mike, ah, but it does appeal to me. We are used to certain 'illogical' formats through custom and usage and so they 'feel' better. I have not tried it, but I suspect you could separate the PLACe 'parts' and arrange accordingly.

I don't use Use Short Form for Repeated Place Names

Having been in IT and lastly as a "systems tester", logical data makes life so much easier. The obvious 'illogical' format is that of date. USA is month, day, year, try sorting that from scratch! The UK date format whilst a little more logical with day, month, year is still not great to sort, Yet the International standard (sometimes committees do work well!) of Year, month, day (e.g. 20110326) sorts 'out of the box', no need to format as date field in things like excel or databases. So, for any basic data I use yyyymmdd, but if there is an option in say reports I will use day,short month, year (e.g. 26 Mar 2010) as this pleasing to our 'norm', is a logical order, and with the month as alpha removes any confusion between UK and USA formats and fairly concise.

Likewise with my PLACe structure, it sorts 'out of the box', this can be useful in many report scenarios. Say a simple Fact with Place query, with my method you can just click the %FACT.PLAC>% column and all addresses are in order, with standard street, town, country etc you have to add 10 =TextPart(%FACT.PLAC%,1,1,STD), =TextPart(%FACT.PLAC%,2,1,STD) etc columns. (OK these are nice columns to have anyway for other reasons).

I am sure there are semantic language reasons why we use what are to my mind 'illogical' structures, but language, convention and even traditions change over time. When people say we should do something because it is traditional, I ask what did they do before the tradition!
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
avatar
NigelBrown
Diamond
Posts: 68
Joined: 27 Apr 2015 21:12
Family Historian: V6.2
Location: Wolverhampton, UK
Contact:

Re: Address and Place, yet again

Post by NigelBrown »

Mike,

"Yet again", thank you for your help. Having made the decison to incorporate address elements in an all-embracing Place, straightaway I replaced my "<at {address}> {place}" with "{_place}". However, your suggestison is much improved and I will adopt this forthwith.

Nigel
Nigel Brown - https://vousden.one-name.net
Vousden One-Name Study - https://vousden.one-name.net
Post Reply