Page 1 of 1

Places and addresses

Posted: 12 Jan 2023 13:22
by mezentia
Is it possible to use a separator other than a comma to separate elements of places and addresses? This question arises from the situation where the initial element, usually of an address, has itself multiple elements, and concatenating then into a single field can look clumsy without suitable punuation to separate the sub-elements. I would not want to increase the number of fields within an address to the extent it becomes difficult to remember how many commas to use to ensure the correct element appears in the correct field. I currently use three columns for place: City/Town/Village, County, Country and 4 for address: House/Flat name/number, Street, District, Postcode that fits quite well with my predominantly UK based research.

Re: Places and addresses

Posted: 12 Jan 2023 15:43
by Gowermick
I think Places have to stick to a strict rule for geocoding purpose, and the fact that Place records are identified by their content.

I don’t think this is the case for addresses, at least I never concerned myself which item goes where.
The only rule I stick to is to have the Street name first, so that they sort in a reasonably useful order, and make better use of the predictive text function of FH. I really cannot see a usefu purpose of putting the house number or name first.

If you regard addresses as simple free form text, and are not concerned about which item goes in which column, then by all means use a different separator for the various parts (I dare say someone will point out the error of my ways :lol: ), but my FH works happlily, so why should I change?

Re: Places and addresses

Posted: 12 Jan 2023 16:08
by mezentia
I understand your rules, Mick, I just prefer to use the columns in the same order that you would normally write an address. And it's easy enough to sort on the colums on the Work with Data/Addresses form, or knock up a quick query for a more detailed analysis. But when the first element of an address my contain 2, three or more parts, e.g. House 1, Court 4, Sainsbury Buildings, 27, London Road, then it all gets a bit complicated :(

Re: Places and addresses

Posted: 12 Jan 2023 16:38
by tatewise
In general, there are no rules at all for formatting the Place and Address fields.
They are entirely free-format text fields. So you can use whatever separators you like.

BUT
All the FH tools for handling the Place and Address fields rely on comma separators to split them into Column Parts.
So if you are not concerned with how those tools work then use whatever you like.
The set of tools that rely on comma separators includes:
Tools > Work with Data > Places...
Tools > Work with Data > Addresses...
Place field qualifiers :SHORT :MEDIUM :TIDY :FULL
FH Function =TextPart(...)
So check how they behave with any new format you propose to use before committing to any changes.

Remember that if you start editing Place fields then that upsets the link to Place records and so geocoded Lat/Longitude and any other Place details will get misplaced.

When using Tools > Work with Data > Places... and Addresses... bear in mind that the Reverse Display Order option lists the fields with the Last Part first and the leftmost parts to the right, so having extra House, Court, Building, parts is less of a problem.

Re: Places and addresses

Posted: 12 Jan 2023 17:18
by Gowermick
mezentia wrote:
12 Jan 2023 16:08
I understand your rules, Mick, I just prefer to use the columns in the same order that you would normally write an address. And it's easy enough to sort on the colums on the Work with Data/Addresses form, or knock up a quick query for a more detailed analysis. But when the first element of an address my contain 2, three or more parts, e.g. House 1, Court 4, Sainsbury Buildings, 27, London Road, then it all gets a bit complicated :(
That may be the normal way us Brits write an address, but not everyone uses it. Holland for example, puts house number after street :D

As you and Miketate states you can sort addresses in a variety of ways to get what you need, but the predictive text feature works on the natural order of the text as it was entered, so works best in my opinion, when street name is entered first.

Likewise with places, predictive text would be wasted if we used the reverse order i.e. Country, County, Town. Thankfully it also uses frequecy of use as a guide, so in my case, Typing ‘W’ in a place, automatically assumes I mean Warrington or type ‘S’ and it assumes Southwark. To me an often under-rated feature, which has saved me hours of typing :D

Re: Places and addresses

Posted: 12 Jan 2023 20:54
by jimlad68
mezentia wrote:
12 Jan 2023 13:22
Is it possible to use a separator other than a comma to separate elements of places and addresses?
I use a strict comma separated fields for PLACes, for similar reasons to Mike. I use ; (semicolon) as my own separator within a field and can be used as many times as required without upsetting the comma separated field structure. e.g.

Code: Select all

England, , Lancashire, Wyre, Cleveleys;Anchorsholme, North Drive, 335
England, , Greater Manchester, Wigan, Scholes, Scholes Street;Cooper's Yard, 13
England, , Greater Manchester, Wigan, Aspull, Scot Lane, (cen1871;s153)
The (cen1871;s153) is a census schedule # in place of a street number where the census does not show a street #, but still uses the ; as an internal field separator.
(I use biggest field 1st, "sorts out of the box", but that is another story).

The main reason for using a ; is:
- that for the Records Window other separators restrict the filter, e.g. filter for coop would find ;coop but not ~coop
- it is the neatest available to work with the filter. Others are " ' & ( .