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: LegacyUserGroup@LegacyUsers.com 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:jerrysemailgro...@gmail.com] Sent: 17 November 2011 17:10 To: LegacyUserGroup@LegacyUsers.com 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 <alanpere...@tiscali.co.uk> 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:doit4...@yahoo.com] >Sent: 17 November 2011 13:14 >To: LegacyUserGroup@LegacyUsers.com >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/legacyusergroup@legacyusers.com/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyfamilytree.com/ 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
