Ron Taylor, as I can see we're barking up the same tree regarding the present possilities storing global positions to a location and as I understand what you are saying but at the moment I think that many on the list could have problems with it.
Please contact me of list as I have something cooking. Bernhard -----Original Message----- From: Ron Taylor [mailto:[email protected]] Sent: Thursday, November 17, 2011 2:14 PM 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
