That is a great concept, Ron. Try to keep selling the idea. It would make a great standard for a new GEDCOM, it seems. Jerry
Ron Taylor <[email protected]> wrote: >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
