* Addresses and commas after house numbers.

[RS3100]

I have spent the best part of a couple of days tidying up my places and addresses, which was long overdue and a great improvement on their previous state that had become somewhat inconsistent. The only issue I still have unresolved is whether to separate house names or numbers and streets with a comma. I admit to having done that with all addresses that include house names or numbers since I first started using FH, but despite reading the relevant article in the knowledge base I'm still somewhat confused about the benefits, or disadvantages.

Of course, not all addresses have house numbers or names, and I have a few which have both a house number and a name that I have entered with both separated by a comma, e.g. "Sunnyside, 63, High Street". But that leads to a disconnection between the field containing the street in such addresses, compared to addresses that only have a street and no house name or number, unless I go through all my addresses and insert an additional comma or commas in front of addresses that only have a street; of which there are far more in my database than those with house names or numbers. Then I will have to condition myself to entering such addresses with leading commas, which will apply to most of them.

I've also searched the forum, but although I turned up a few posts about places and addresses, I didn't find anything that really helped. So I'm just wondering how others handle this, and why?

[Ron Melby]

my major concern in addresses is whether or not I can find them on google that way, and whether or not miketate's Map Life Facts can find them on google.
my addresses are as follows:
building, street, city, state, zip, nation, with placeholders.

Fort Stotsenburg, Lily Hill Street, Angels City Pampanga, PH, 2009, PHL
, 10025 21st Avenue NE, Seattle, WA, 98125, USA
Acacia Park Cemetery, 2151 Pilot Knob Road, St Paul, MN, 55120, USA
Arlington Cemetery, , Arlington, SD, 57212, USA
Green-Wood Cemetery, 5th Avenue & 25th Street, Brooklyn, NY, 11232-1317, USA

I (and only in my opinion, but I am right and everyone should do it my way LOLOL) addy number while important if known is not separately atomic data contextually, it is part of the street datum.

I correspond with a friend in England that has a two part address if you will a addr1, addr2, and they deliver mail there without the comma inserted, so my advice would be put the address in google maps all the different ways with a couple of those types of addresses you have
and see how close they hit.

[Mark1834]

Ask yourself the question “why am I recording these data, and what do I anticipate doing with them?”. Is it to give neat and tidy reports, or in preparation for detailed mapping or analysis? That will probably steer you towards what works best in your context.

FWIW, I tend to treat addresses as free form text, and record whatever level of detail is appropriate, but never with commas after numbers or double commas.

[Gowermick]

RS3100,
Here’s what I do.
1. Keep addresses separate from Places.
Google et al get confused when placename is preceed by an address!

2. Enter Places in 3 part format whenever possible, i.e. Town, County, Country (99% of my places are in UK!)
NB when just County is known, I use a preceeding comma, to force County into second field. Likewise if just Country know, I use 2 Commas

3. Addresses are entered in reverse format, putting street name first: Street, House name or Number.
NB I put the house number after the Street to aid autofill, as FH shows matches as you type. If one entered number first, it would show matches to addresses having same house number, which is as useful as a chocolate teapot

[RS3100]

Thanks both of you.

Mick, I probably wasn't explicit enough in my original post. I do keep addresses separate from places, and I now have all of my places "properly" constructed in three part, comma separated format after a couple of days spent resorting them. I'm quite happy with the consistency of entering new places in that format, adding leading or intervening commas where necessary where I only have a country, or county and country for example.

For foreign places, I've restricted the place field to the last three elements to conform to that construct, and any preceding parts I've enter in the address field. For example, Goldthwaite, Mills County, Texas, USA is entered in my project with "Mills County, Texas, USA" in the place field, and "Goldthwaite" in the address field. I don't lose any information in reports, as I include the address in many of my fact sentences as described below. Very few of my ancestors were abroad, and for those that were I'm quite happy with a description of the location by street/town/county/state/country rather than a fully formatted postal address including zip codes etc.

I understand what you mean about autofill, but I don't particularly find that a problem. If I have two or more addresses starting with "32" for example, I'm happy to enter enough characters in the address field until the street name or other information after the house number identifies the correct one of the two or more options that autofill would match. That's no different to me than when entering Manchester or Mansfield in the place field, and then there are all the churches - St Marys, St Nicholas, Holy Cross, etc.

Plus I have edited several of my fact sentences to include the address and place in the sentence ("<at {address}> {place}") so reversing the addresses would display rather oddly in reports.

Really, what I'm asking about is whether I should enter addresses in the address field as:

"25, High Street, Anytown" or "25 High Street, Anytown"
", Lower Road, Othertown" or "Lower Road, Othertown"
",, Mytown" etc.

So, I have the place fields conforming to a 3 part format and I can see the reason for that and will maintain it for new entries. But what I'm really asking is, for the address field, does it really matter other than for consistency, and if so, why? Your reversing of addresses suggest to me that the format is not really important other than for consistency within the specific project and perhaps personal preference. Unless there's something I'm missing that might have other implications I am more inclined to just carry on as I am, and not worry that some addresses are entered as "number, street, village" and others as "street, village" - where those with a house number have the street name in the second field, but those without a house number have the street name in the first field so are effectively offset one field to the left.

I understand the importance in the place field structure, for geolocation etc., but geolocation doesn't utilise the address field. Is there something else I'm missing that should make me apply consistency to the address field in a specific way?

[tatewise]

Consistency is important for future searches and analysis, even if you have no use for it at present.
That crops up regularly in these Forums, and inconsistent data can be a stumbling block.
Take a look at Tools > Work with Data > Addresses... and review how your address columns are presented.
It is useful to be able to collate addresses by street, town, etc, especially in Reverse Display Order.
That sometimes leads to edits and merges that would be difficult to spot without consistent columns.
c.f. Tools > Work with Data > Places...

[Gowermick]

Consistency is important for future searches and analysis, even if you have no use for it at present.
That crops up regularly in these Forums, and inconsistent data can be a stumbling block.
Take a look at Tools > Work with Data > Addresses... and review how your address columns are presented.
It is useful to be able to collate addresses by street, town, etc, especially in Reverse Display Order.
That sometimes leads to edits and merges that would be difficult to spot without consistent columns.
c.f. Tools > Work with Data > Places...

Totally agree. There is a gotcha when it comes to use of spaces too. Inconsistent use of spaces after the comma used to separate your component parts can hinder autocomplete. The unwanted space could prevent autocomplete finding an existing place, so one ends up creating a duplication, albeit one with a space and one without. e.g. ,,France and ,, France
If you use a space always use a space - be consistent

[Mark1834]

Or just France and France - that is less error-prone, and have ,,France as the standard name.

In my experience, absolute consistency is more difficult to achieve with addresses than with places. I have a family variously recorded as living at 4 Crescent Cottages, Crescent Cottages, 4 Crescent Cottages, High Street, and finally 114 High Street when the road was re-numbered. It’s all the same small terraced house, but coming up with a practical system that keeps all that aligned (plus the option of a house name) without introducing more problems than it solves would be a challenge!

As ever, it comes down to a trade off between ease of entry and ease of analysis. There’s no universal answer - it’s what works for you.

[RS3100]

Consistency is important for future searches and analysis, even if you have no use for it at present.
That crops up regularly in these Forums, and inconsistent data can be a stumbling block.
Take a look at Tools > Work with Data > Addresses... and review how your address columns are presented.
It is useful to be able to collate addresses by street, town, etc, especially in Reverse Display Order.
That sometimes leads to edits and merges that would be difficult to spot without consistent columns.
c.f. Tools > Work with Data > Places...

Much of the last two days has been spent going through Tools>Work with Data>Places Mike, and generally tidying up all the entries and making the columns consistent. Sorting out addresses is my next intention, hence my question.

I'm still not quite getting this though. I have addresses at say "2, Bridge Street", "35, Bridge Street", "37, Bridge Street" and just "Bridge Street" all attached to the place "Barking, Essex, England". If I search for "37, Bridge Street" I can find all records of the type(s) I select attached to that address. If I search for "Bridge Street" I can find the records attached to all of those addresses. For the first three, the first column of the address in Tools>Work with Data>Addresses currently consists of the house number. For the last one, it consists of "Bridge Street".

So from what you are saying, I would be better off adding a preceding comma and space to all entries that don't have a house number, so that all street names are in the second address column? Or would it make any difference if I removed the comma from between house numbers/names and the street name, so that all street names and preceding house numbers etc. (if any) all fell into the first column?

Just trying to get my head around this and I want to get it right so I don't have to subsequently repeat the exercise!

[RS3100]

Or just France and France - that is less error-prone, and have ,,France as the standard name.

In my experience, absolute consistency is more difficult to achieve with addresses than with places. I have a family variously recorded as living at 4 Crescent Cottages, Crescent Cottages, 4 Crescent Cottages, High Street, and finally 114 High Street when the road was re-numbered. It’s all the same small terraced house, but coming up with a practical system that keeps all that aligned (plus the option of a house name) without introducing more problems than it solves would be a challenge!

As ever, it comes down to a trade off between ease of entry and ease of analysis. There’s no universal answer - it’s what works for you.

You must have replied as I was typing my last post Mark. You have quite succinctly expressed some of the issues I'm grappling with, especially with an address in a specific street, and then another crops up that is in a small close or yard leading off of that street. As you say, it's more difficult keeping track of those issues and putting the various address parts into the right pigeon holes. I think I'm getting the hint that whilst consistency is important, it's less of a problem inthe Address field than inconsistency in Place field structures.

[tatewise]

There are other considerations.

If you omit the comma between number and street then that column does not sort very well.
The street column entries that start with a 1 are grouped together, and so on for 2, 3, 4, etc, regardless of street name.
So "35 Bridge Street" and "37 Bridge Street" will be sorted near each other, with "2 Bridge Street" quite separate.
The street column entries that start with A are grouped together, and so on for B, C, D, etc.
So "Bridge Street" will be nowhere near the three above.

If you include a comma when the number is missing, then the street column will sort all Bridge Street entries together regardless of the number.

On the other hand, as long as you are consistent with commas to the right of the street, then Reverse Display Order will work quite well with whatever you use for number and street separation including no comma if no number.
However, a mandatory comma is slightly better.

[AdrianBruce]

... There is a gotcha when it comes to use of spaces too. Inconsistent use of spaces after the comma used to separate your component parts can hinder autocomplete. The unwanted space could prevent autocomplete finding an existing place, so one ends up creating a duplication, ...

As I've said before, my muscle memory goes pear-shaped when faced with leading commas and - maybe? - spaces for exactly those reasons. I therefore try to minimise "unreal" commas - partly as a result, I don't insert commas after house numbers.

I do have other aspects to try and remember in addresses, such as spelling out "Road" and "Street" in full or spelling the dedication of churches usually as "St. Mary's" - note abbreviation with full stop and possessive. Even there I find issues - I use "St. Barnabas" not "St. Barnabas's" because that's what my Dad called it... And there are other dedications that don't seem to work with a possessive.

[AdrianBruce]

...
If you omit the comma between number and street then that column does not sort very well.
The street column entries that start with a 1 are grouped together, and so on for 2, 3, 4, etc, regardless of street name.
So "35 Bridge Street" and "37 Bridge Street" will be sorted near each other, with "2 Bridge Street" quite separate.
...

Yes, I admit this is an issue for my "no comma" policy - but it's one that could be mitigated to some degree if the "Find" facility in "List of Addresses" actually did do a find and not go to the first address starting with the so-called search-string. E.g. "Find" "Bridge Street" finds all addresses containing "Bridge Street", rather than (as now), doing nothing unless there is an address reading just "Bridge Street".

[davidf]

One of the options that I have tried is to put the number after the road name but before the comma (German Style)

This then means that a sort is more useful if searching for neighbours:

Bridge Street
Bridge Street 35
Bridge Street 37

etc.

Although we still have the problem Bridge Street 35 and Bridge Street 37 could be in different towns - and without a systematised link to place, we can only tell by looking at the combination of place & address (via a fact query?). But that is a GEDCOM restriction?

A form of syntax that allows us to add a qualifier to an address (that does not show when the ADDR tag is used) might help a bit:

Bridge Street {Westminster}
Bridge Street 35 {Shrewsbury}
Bridge Street 37 {Newcastle)

[ColeValleyGirl]

I enter address + place in the place field (as it was -- as far as I can tell -- at the time of the event/attribute). I used to worry about consistency, but then realised my ancestors weren't consistent anyway, so it was pointless me trying to corral things into a rigid system.

I geocode every address + place combination (and add a standardised 'modern' place if useful).

If I need to 'analyse' addresses + places, I use the map window -- the only analysis I've ever needed is to understand the spatial relationship between two or more facts.

I don't generate paper reports; on my website online, I include a map of the locations associated with each individual, which should be sufficient for modern readers to know where I'm talking about. Ancestry and the other 3rd party sites on which I put my tree as cousin bait can do what they like with my location information (Ancestry, for example, makes enough of a mess of other people's location info that It's not worth trying to adhere to their 'standards' when uploading.) Anyone perusing my tree who is trying to work out whether we 'share an individual' will have sufficient location info available to know whether we're in the same general ballpark or not -- and if they can't tell, they can always ask.

[tatewise]

Instead of Bridge Street {Westminster} use Bridge Street [[Westminster]]
i.e. the private Note [[ double square brackets ]]
In many scenarios the include/exclude Private Note options are also applied to Address fields.

That and other related ideas are given in FHUG KB Working with Places and Addresses.

[davidf]

I thought private note brackets [[...]] only worked in note fields - and the address being a single line is not a note field?

Or is that a restriction in V6 that has been lifted in V7?

[Mark1834]

I think that is an important point, to record address only to the precision that is supported by the sources for the event. For example, if two successive censuses give the address as 7 Church Street, and a baptism between the two reports the address simply as Church Street, then that is what is recorded.

I write the name of the road in full in the address field (Street, Road, Villas, Cottages, Lane, etc), but as written originally in Text from Source, and keep dedications as abbreviations with no full stop (St Mark's Church, etc). I think we have discussed before how to record something like St Benedict's Church, Church St, Bury St Edmunds...

[RS3100]

Hmm, a lot of food for thought there. I'm beginning to see the light. I found it much easier to understand the necessity for consistency in the place filed though. I admit to having made a conscious decision from the start to always use "Road" and "Street" etc. rather than abbreviations in the address field, and I also avoid apostrophes or other similar punctuation, so churches in my addresses are always St Marys Church, St Batholomews Church, etc. Text from Source I do always try to copy the original text as precisely as possible.

Quite a lot to think about though, before I decide exactly how to proceed, although I will aim for consistency of one sort or another. I can see an investigation of Mike's Search and Replace plugin is going to be required shortly.

Thank you everyone.

[tatewise]

@davidf: The [[ privacy square brackets ]] work in more than just Note fields (but entirely consistently) and the Address field is not restricted to one line but is a muti-line text box.
Click the [...] button on its right and choose Edit Address to get a multi-line edit box.

[davidf]

@davidf: The [[ privacy square brackets ]] work in more than just Note fields (but entirely consistently) and the Address field is not restricted to one line but is a multi-line text box.
Click the [...] button on its right and choose Edit Address to get a multi-line edit box.

Sounds as if I ought to start using them - particularly to distinguish one "St Marys" from another!

[jbtapscott]

I have (since I started with v5) used the [[....]] brackets with addresses to differentiate, particularly, churches in different locations - eg "St Marys Church, [[Bridgwater]]" and "St Marys Church, [[Bristol]]" etc. For the first few months with FH I didn't do this but quickly learned the error my ways!!.

[LornaCraig]

Instead of Bridge Street {Westminster} use Bridge Street [[Westminster]]
i.e. the private Note [[ double square brackets ]]
In many scenarios the include/exclude Private Note options are also applied to Address fields.

Unfortunately one of the scenarios where the double square brackets don't work is when addresses are included in diagram text schemes. The double brackets and their contents still show up!

I have a family variously recorded as living at 4 Crescent Cottages, Crescent Cottages, 4 Crescent Cottages, High Street, and finally 114 High Street when the road was re-numbered. It’s all the same small terraced house, but coming up with a practical system that keeps all that aligned (plus the option of a house name) without introducing more problems than it solves would be a challenge!

Yes I have many similar cases where the same building is recorded in a variety of ways. What we need is a 'Standardised' field for addresses, like the one for Places. But I imagine that's not possible, because Addresses, unlike Places, are not a Record type.

[tatewise]

True, but you could use =Section(%INDI.BIRT.ADDR%,1,"[[") to remove trailing [[text]].

In standard GEDCOM Place is not a record ~ it is an FH extension.
So something similar could be applied to Address fields.
It is unfortunate that did not happen and be integrated with Place records when they were introduced.

One solution is to disregard Address fields and put the entire Address & Place in the Place field as suggested in Working with Places and Addresses

[AdrianBruce]

... I geocode every address + place combination (and add a standardised 'modern' place if useful). ...

I'm wondering if perhaps I should investigate doing that. I'm currently just geocoding places but just lately I've added some things like Hospitals as places in their own right - basically because I looked at the map for my father and it showed him as dying in (the village of) X, Cheshire, England - whereas he actually died at X Hospital, X, Cheshire, England. Might not have been so bad if the hospital wasn't absolutely visible on the map, some distance from the village of the same name. Currently the place-name is set to X Hospital, X, Cheshire, England and that Geocodes fine - but that's not wholly consistent with other places.