There was a wish list item (No 71) that was incoporated in Version 2.2.
However, there is still no auto-complete in some fields eg Address. (Place, yes, but Address no.). Auto-complete in this and other fields would speed up data entry.
Gerry
http://www.fhug.org.uk/wishlist/wldispl ... wlwlref=59
ID:4007
* Auto-complete
-
Jane
- Site Admin
- Posts: 8441
- Joined: 01 Nov 2002 15:00
- Family Historian: V7
- Location: Somerset, England
- Contact:
Auto-complete
Other than address what fields were you thinking of?
Jane
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
-
ChrisBowyer
- Superstar
- Posts: 389
- Joined: 25 Jan 2006 15:10
- Family Historian: None
Auto-complete
There was a discussion about this a long time ago, my conclusion to which was that a) the address needs to be in the context of the placename, and b) drop-down selection is more helpful than auto-complete. That was one of the things that prompted me to write Toponymy... see http://www.fhug.org.uk/cgi-bin/index.cg ... ews&id=152
P.S. Sorry I don't know how to put a link in here, and is there a way of finding a wish list item from its number?
P.S. Sorry I don't know how to put a link in here, and is there a way of finding a wish list item from its number?
-
gerrynuk
- Megastar
- Posts: 565
- Joined: 25 Apr 2007 09:21
- Family Historian: V6
- Location: Welwyn Garden City
- Contact:
Auto-complete
Jane, All the address various fields that Gedcom uses - I'm sure someone with a better knowledge of the Gedcom format could specify them - but particularly the one that FH uses with Place.
Chris, Auto-complete or drop-down would fit the bill.
I use the address fields a lot and having to type the same text many times over is not only tedious but error-prone. For example, if I am writing up a family's baptism records it is usually the same church name each time.
Gerry
Chris, Auto-complete or drop-down would fit the bill.
I use the address fields a lot and having to type the same text many times over is not only tedious but error-prone. For example, if I am writing up a family's baptism records it is usually the same church name each time.
Gerry
-
ChrisBowyer
- Superstar
- Posts: 389
- Joined: 25 Jan 2006 15:10
- Family Historian: None
Auto-complete
That was another of the things that got me started on Toponymy... I got fed up with typing St Mary the Virgin every time someone was baptised, married or buried in Pirton, Herts.
-
PeterR
- Megastar
- Posts: 1129
- Joined: 10 Jul 2006 16:55
- Family Historian: V7
- Location: Northumberland, UK
Auto-complete
There is another Wish-list item which may be relevant: 59 - Address management like that for Places, but to which I added the following comment:
For the GEDCOM standard for Address-Structure see:
http://homepages.rootsweb.ancestry.com/ ... _STRUCTURE
The GEDCOM tag for Address which FH uses by default is ADDR. It may be possible to implement auto-complete for this single field, but this may have to be restricted to values within a single line, as is the case for Place and Occupation, etc. However, it may be too restrictive to make Address somehow dependant on Place. There are some contexts in which Address is allowed but Place is not, e.g. a Repository record, and for Events you can enter an Address value without specifying a Place. It is also possible in some cases that the value entered for the ADDR tag, e.g. name of church, or street address, remains fixed for hundreds of years, but the corresponding Place has changed its name.
I have certainly found that FH4's Fact Queries can be very useful for sorting by Place, or Address, or Address within Place.I can see why auto-complete and a system like Tools > Work with Data > Places could be useful for the Address field, but I can see several complicating factors. (1) Address and Place values can and do exist independently of each other, i.e. within neither FH (v.4.0.2) nor GEDCOM 5.5 is Address in any sense 'within' Place. (2) The Address field itself can have multiple continuation lines, which the Place field cannot. (3) Address has many possible sub-fields: First Indexing Line, Second Indexing Line, City, State, Postal Code, and Country. Also, FH v.4 introduced Fact Queries, which enable filtering by Place and/or Address (and its sub-fields).
For the GEDCOM standard for Address-Structure see:
http://homepages.rootsweb.ancestry.com/ ... _STRUCTURE
The GEDCOM tag for Address which FH uses by default is ADDR. It may be possible to implement auto-complete for this single field, but this may have to be restricted to values within a single line, as is the case for Place and Occupation, etc. However, it may be too restrictive to make Address somehow dependant on Place. There are some contexts in which Address is allowed but Place is not, e.g. a Repository record, and for Events you can enter an Address value without specifying a Place. It is also possible in some cases that the value entered for the ADDR tag, e.g. name of church, or street address, remains fixed for hundreds of years, but the corresponding Place has changed its name.
Peter Richmond (researching Richmond, Bulman, Martin, Driscoll, Baxter, Hall, Dales, Tyrer)
-
AdrianBruce
- Megastar
- Posts: 1962
- Joined: 09 Aug 2003 21:02
- Family Historian: V7
- Location: South Cheshire
- Contact:
Auto-complete
Re addresses and the way they relate to places.
Peter says 'within neither FH (v.4.0.2) nor GEDCOM 5.5 is Address in any sense 'within' Place.' Which surprised me but when I read his reference, he is of course correct. However, the way I have used Address is totally different to this implied method and my Address is very much within Place. E.g. Place = 'Crewe, Cheshire, England', Address = '220 High St.' And only that! My sentences for the narrative report then concatenate Address and Place so it would be stupid to have any duplication. Well, that's the way I've done it - clearly other people's methods are different. But for me, I'd be very happy with possible Addresses varying by Place.
NB - yes, my Repository Addresses ARE multi-line. At which point, I feel like admitting, 'There's nothing like standardisation and that's nothing like...'
Peter also mentions the possibility of a fixed address while the place name varies. I'm not sure how this would occur in the full multi-line address scheme - while 'St Helen's Church' might stay fixed as the surrounding town changes from 'Witton, Cheshire' to 'Northwich, Cheshire', _if_ we use the 'proper' GEDCOM multi-line standard, it would need to be written as 'St Helen's Church, Witton, Cheshire' first, then 'St Helen's Church, Northwich, Cheshire'. So it may not be that much of an issue? But what this does raise is the issue of places that change name over the years. Ideally, if I do a query on 'Winsford, Cheshire', it would be very nice to extract all references to 'Over, Cheshire' and 'Wharton, Cheshire' as well, since these are the preceding townships to the town of Winsford. However, I fear we may be running ahead of what GEDCOM will support here. (I can feel certain people wanting to reply to that!).
Still - it might be nice to have some useful aliases - in fact, I've just realised the major area we need aliases for locations is to resolve the issue between the pre-1974 counties and the post. I'm quite happy to write 'Manchester, Lancashire' for an event from 2008 - but it's a bit odd, isn't it?
Peter says 'within neither FH (v.4.0.2) nor GEDCOM 5.5 is Address in any sense 'within' Place.' Which surprised me but when I read his reference, he is of course correct. However, the way I have used Address is totally different to this implied method and my Address is very much within Place. E.g. Place = 'Crewe, Cheshire, England', Address = '220 High St.' And only that! My sentences for the narrative report then concatenate Address and Place so it would be stupid to have any duplication. Well, that's the way I've done it - clearly other people's methods are different. But for me, I'd be very happy with possible Addresses varying by Place.
NB - yes, my Repository Addresses ARE multi-line. At which point, I feel like admitting, 'There's nothing like standardisation and that's nothing like...'
Peter also mentions the possibility of a fixed address while the place name varies. I'm not sure how this would occur in the full multi-line address scheme - while 'St Helen's Church' might stay fixed as the surrounding town changes from 'Witton, Cheshire' to 'Northwich, Cheshire', _if_ we use the 'proper' GEDCOM multi-line standard, it would need to be written as 'St Helen's Church, Witton, Cheshire' first, then 'St Helen's Church, Northwich, Cheshire'. So it may not be that much of an issue? But what this does raise is the issue of places that change name over the years. Ideally, if I do a query on 'Winsford, Cheshire', it would be very nice to extract all references to 'Over, Cheshire' and 'Wharton, Cheshire' as well, since these are the preceding townships to the town of Winsford. However, I fear we may be running ahead of what GEDCOM will support here. (I can feel certain people wanting to reply to that!).
Still - it might be nice to have some useful aliases - in fact, I've just realised the major area we need aliases for locations is to resolve the issue between the pre-1974 counties and the post. I'm quite happy to write 'Manchester, Lancashire' for an event from 2008 - but it's a bit odd, isn't it?
Adrian
-
ChrisBowyer
- Superstar
- Posts: 389
- Joined: 25 Jan 2006 15:10
- Family Historian: None
Auto-complete
I couldn't agree more with Adrian. I too changed my text scheme years ago to read '... at in '. It may not be what the standard implies, but hey, it does what I want.
Unlike the Gedcom standard, Toponymy understands that place names change over time. It lists addresses (as well as identifying districts and locations) recorded for a particular 'place' taking into account spelling variants, county boundary changes, or whatever. That enables me to record place names as they would have been understood at the time, which I think adds flavour to the tree. After all, the present local government boundaries (and even present spelling conventions) are pretty arbitrary in the long term, so why use them to record information about the 19th or even early 20th century.
P.S. I can't bring myself to care how repository addresses are stored; that's about the mechanics of genealogy (I could just as effectively use notes), not the content. Useful for record keeping no doubt, but not relevant to my ancestors.
Unlike the Gedcom standard, Toponymy understands that place names change over time. It lists addresses (as well as identifying districts and locations) recorded for a particular 'place' taking into account spelling variants, county boundary changes, or whatever. That enables me to record place names as they would have been understood at the time, which I think adds flavour to the tree. After all, the present local government boundaries (and even present spelling conventions) are pretty arbitrary in the long term, so why use them to record information about the 19th or even early 20th century.
P.S. I can't bring myself to care how repository addresses are stored; that's about the mechanics of genealogy (I could just as effectively use notes), not the content. Useful for record keeping no doubt, but not relevant to my ancestors.