Ron, That was my reason for the comment at the end. I to use the full address in the location field as it was at the time. The comment at the end considers another possibility. Location: Fictional names used: Date: Before 1889 Full Address: 24 Randolph Street, Islington, Middlesex, England [Would be the Long Name] Short name: Islington, Middlesex, England Current: Islington, Greater London, England: effective Date 1965
The problem with this is if you want short names in charts but want to retain the street number and name. A compromise to achieve some sort of Location Standard. Alan -----Original Message----- From: Ron Ferguson [mailto:[email protected]] Sent: 17 November 2011 19:43 To: [email protected] Subject: Re: [LegacyUG] Locations Alan, Given the way in which Legacy currently works at present any Location field should, in my view, have the option for the user to enter the full location, including house and street, where applicable. It must also be able to do this for every country in the world. There are currently 9 fields available for use in the locations, and I see no reason to reduce this, I regularly get quite close to the limit, although I haven't got there yet! Ron Ferguson http://www.fergys.co.uk/ -----Original Message----- From: Alan Pereira Sent: Thursday, November 17, 2011 5:53 PM To: [email protected] Subject: RE: [LegacyUG] Locations The way I would see it handled would be via an "options setting" where you choose whether to show current location or location at the time of the event. A bit like whether to show long or short names. I am visualising a preloaded Location Table which gets updated via Legacy Updates or via some mechanism similar to the way Virus Checking Software Update their databases. This database would be activated on entering the Event date and the start of the Location similat to the way new family search tries to identify locations based on your input. If you had a family living at the same address over 10 generations and the loaction changed 3 times in that period I would expect based on dates all 3 locations to show up in the database depending on the date. All those historical locations would have the same current location. e..g for UK 1867 Islington, Middlesex, England 1890 Islington, London, England 1970 Islington, Greater London, England Current: Islington, Greater London, England: effective Date 1965 Of course, if you wish to use the full location as it was at the time, including street and house number / name, then this all goes out the window. unless... One uses the above scenario for the short name to match the master location list. Alan -----Original Message----- From: Jerry [mailto:[email protected]] Sent: 17 November 2011 17:10 To: [email protected] Subject: RE: [LegacyUG] Locations Alan, would your solution allow one single location for each place or would you still end up with multiple location names, based on time in history? Jerry Alan Pereira <[email protected]> wrote: >Ron, >In answer to your first paragraph only... >I could see how you could do this in a relational database by having a >starting and ending date for each location together with it's >approximate grid position. When entering a location a lookup to that >table will provide a consistent location. >It does beg two major questions. >1) Who owns the master list? >2) What level of detail does this location permit In FreeBMD they >already provide cut-off dates for changes in UK Parish boundaries, >which I have, for my own Genealogy, converted to a relational database. >This I suspect, is one of many such instruments that people >use...Spreadsheet, documents etc. >The User Group does not have a consensus on what to put in the location >( I go down to street number and name - as that is what I found at the time). >There has been a push for some time to conform to the USA 4 field >standard, with, I believe, no success outside of the USA. May I >suggest either a 3rd tier to the Location Table: Long, Short, World >Standard or drop the short name in place of a World Standard. The >World Standard would be the Current Location and Grid Position, which >would necessitate enough fields to conform to what each Country now >considers it's Location to be. This World Standard would also have an >effective date indicating when it became that location. When it >changes, the old standard will be moved into an historical record identifying >start and ending dates. > >The key is ownership. Without that, anarchy rules and we all do our >own thing. Which is where we are now! >Alan Pereira > >-----Original Message----- >From: Ron Taylor [mailto:[email protected]] >Sent: 17 November 2011 13:14 >To: [email protected] >Subject: Re: [LegacyUG] Locations > >I've commented before about time sensitive location names. This is a >very simple problem which can easily be solved with database tools. >When programming at BYU, the university had many codes which were used >for various purposes. By combining the code with its context, it was >easy to determine what the code meant at a particular time and in a >specific setting. The same could be done with locations. If the >lattitude and longitude were stored as pointers in the individual >records, marriage records, event records, etc. then a simple lookup of >that point on the map coupled with the time frame could retrieve what >it was called at that point in time and in whatever language you wish >it. By similar logic, you could find a location in the Master >Locations table and then have another "show list" function to display >all the alternate names for that referenced geo point. The alternates >would not have to be in the notes for every location but rather they >would come from a table similar to the Geo Database. This might also >provide a better way to verify locations than the current method of the >"county verifier" as it could be made functional for all areas of the >world. In summary, I would always find the current location in >whatever language I might be using and then have it verified against a >Geo Database type of table. Then I would have an option that I could >check to show all locations in their time-sensitive name or in the current >name or possibly both. > >While I'm at it, I'll give one more possibility that would be easy to >implement. The locations table should not have any of what I call >"location modifiers". Legacy calls them "prepositions" even though >some of them are not actually considered such. They are words like >near, of, from, probably, and many more. To correct this situation, it >would require another table of these location modifiers that the user >could add to if necessary and then in the individual record, marriage >record, event record, etc. there would be a pull-down for the location >modifiers next to each location field. The default would be blank or >none but if a location modifier were selected, the pointer for it would >be in the record and associated with the field that it modifies. That >way, all locations in the Master Locations table could be verified >because none would have location modifiers in them. I realize that >even though these mechanisms might be easy to visualize that they may >require some major re-programming but the method would be very >consistent and allow for each location to be listed just once. > >Ron Taylor > Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on our blog (http://news.LegacyFamilyTree.com). To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on our blog (http://news.LegacyFamilyTree.com). To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
