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 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
