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