Alan,
not everybody living in a country has his roots there and not everyone living in
a country has his roots there ;-).
Looking at the history of my parents and greatparents I would be Polish today.
1. That's a very good question and at the same time very difficult.
It depends on the counrty you live in and not only those laws.
While on your PC it's your property.
If you have posted data in the internet check the country and the
agreements to the list you signed to.
It could be that they have all rights using your data sent and at the
same time you pay to get what you have sent.
2. again only my opinion.
I only support tools supporting Legacy functions.
Had a look a very short glimps at FreeBMD. A great tool for the Britsh
decsandants but over 90% of the world aren't British ;-). Please don't take
that wrong )-:.
What can be used directly without any conversions in Legacy.
3. I agree that the User Group doesn't have a consensus about the way to
document an exact location.
We talked about it a while ago and as I'm as. a hard liner wasn't liked
:-(
The present USA 4 field standard is only a workaround.
In my cases it works best but am not alwasy happy about it.
As long as we don't have any better option to use it, I'll continue to
use it.
I'd prefer one Master Location and many Addresse locations.
4. using a new system means many new problems.
At the moment all fields needed are present.
The poblem could be to just combine tem.
In my opinion the major problem it to use the diffenten location data and
combine to one database.
Bernhard
-----Original Message-----
From: Alan Pereira [mailto:[email protected]]
Sent: Thursday, November 17, 2011 4:25 PM
To: [email protected]
Subject: RE: [LegacyUG] Locations
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:[email protected]]
Sent: 17 November 2011 13:14
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
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
