Rich, I don't think that John was missing the point at all. Neither are you. To me those appear to be two distinct issues.
Whether the data fields go from smallest to biggest or from biggest to smallest, the fact remains that the data fields are not identified in any way with particular geographical or political subdivisions. In other words, no matter which way the data fields go, you still can't tell whether any one of them is a county, or township, or city, or address, etc. John's method is one way of providing this identification, by assigning a "type" to each data field. Something of this nature, while likely a nightmare to code, would provide for much more "intelligent" logic when using resources like the county verifier or the Geo database. This would also free us from being too US-centric, as has been mentioned. And, as we have learned from these discussions, there is absolutely no consistency within the US either! Bob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rich from LA CA Sent: Tuesday, December 14, 2004 13:33 To: [EMAIL PROTECTED] Subject: Re: [LegacyUG] Back to Basics IMHO, you may be missing the point, if not humble apologies. At present the Location file is stored in the DB sorted smallest to biggest. Switching it to, biggest to smallest would not change any data (hopefully). Here is a good example of why this is good. Do you remember Y2K. In the 1960's dates were stored as a digit, which was how many days since 1/1/1900. We now internally store dates as 20041214120016, that is 16 seconds after noon on 14 Dec 2004. We never need to sort this out personally. Note it is sorted biggest to smallest. If you don't care about seconds, leave it blank. I left of the micro seconds. The new storage plan would be, Country [level1], state [level2], county [level3], city [level4], neighborhood [level5], address [level6], room [level7]. ;-). Please give the programmers time to do it. It should take a few monthsyears to change every place. That is miles of code, that cannot be search and replaced. I will get off the soap box now. delete away. Rich in LA CA -----Original Message----- From: "John R. Bayle" <[EMAIL PROTECTED]> Sent: Dec 13, 2004 7:30 PM To: [EMAIL PROTECTED] Subject: Re: [LegacyUG] Back to Basics In replying to my posting, John Murray wrote: > Here in England we don't have states so how would we sort. I think that the > programmers should be careful not to make this wonderful program USA centric > or it will lose lot of customers In the method I have in mind you would never use the "States" field in your genealogy then, at least not for your English events. You could use the term Shire or County or whatever. You could then sort on those location types. I really hadn't very explicitly designed my scheme when I first posted on this thread, but now I can see a way to do it. What follows is a bit long and perhaps a bit technical. Legacy would have a group of Location Fields for each Location. They would have the name Location1, Location2... LocationN. Each of these fields would have two subfields, a Name and the Data. So in Access Database terms there'd be a table or table fragment with Location1Name and Location1Data fields etc. In the Location1Name field a user could put "Address". In the Location1Data field a user could put "25 Main Street" Another user could do things differently and In the Location1Name field put "City" In the Location2Data field put "Albany" Note this varies for EACH EVENT. So the user could use the above scheme for one event and the following for another event Location1Name field = "Village" Location2Data field = "Lake George". So this is completely flexible and instantly international, because even the types of the jurisdictions change and they can do so from any event to any other event. One could then search for all "Villages" describing a certain location level. So you could find and mark all events or people who had events with "County" in a certain place location type. Then Search among the marked records only for place location name of "Cork". These two searches would yield all the folks who had County Cork as a location. IMO this design eliminates the need for placeholder commas. The program just looks at the two parts of each place name and writes out so and so was born on July 21, 1876 in the Village of Lake Luzerne, in the Town of Queensbury, in the County of Warren, in the State of New York in the Country of USA. For those concerned about the tediousness of doing data entry, under this scheme, I'm sure the clever programmers at Millenia could come up with default schemes and other methods to minimize the pain. That's what I was hinting at when I said this scheme could keep the programmers busy for a while. jr Legacy User Group Etiquette guidelines can be found at: http://www.LegacyFamilyTree.com/Etiquette.asp To find past messages, please go to our searchable archives at: http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/ To unsubscribe please visit: http://www.legacyfamilytree.com/LegacyLists.asp Rich in LA Legacy User Group Etiquette guidelines can be found at: http://www.LegacyFamilyTree.com/Etiquette.asp To find past messages, please go to our searchable archives at: http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/ To unsubscribe please visit: http://www.legacyfamilytree.com/LegacyLists.asp Legacy User Group Etiquette guidelines can be found at: http://www.LegacyFamilyTree.com/Etiquette.asp To find past messages, please go to our searchable archives at: http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/ To unsubscribe please visit: http://www.legacyfamilytree.com/LegacyLists.asp
