David Abernathy said:
"One thing that needs to be thought about when suggesting these enhancements. What will happen to this data when a GEDCOM is made?"
Yes to a small extent the implementation of the GEDCOM standard is part of the problem, HOWEVER, a good database and application designer can easily work around this AND still get worthwhile data into the GEDCOM PLAC tag.
Unfortunately FTM and a lot of other programs do not put enough effort into the data entry and storage design of their own application to aid the user AND implement well formed GEDCOM PLACe data (or NAME tags, dates, relationships, etc.).
1) Place needs to have its own database record/table in FTM and not be a singular field within a "fact" record/table.
2) The place record/table should allow the user to enter complete information about the place. This information can include:
2a) Place name for external use in reports, display pages etc. Values in this field would be "Olso, Norway" -or- "New York City, New York, USA"
2b) GEDCOM name hierachy with all of the correct political divisions including county, township, etc.
2c) Historical name information, alternate spellings
2d) User defined information, including room for stories about places, pictures of places, etc
2e) Map coordinates
2f) Place Name part indexes, so that you can locate places by various name parts and historical/alternate names
3) Users (aka data entry people) should be able to select from a list of previously provided/supplied places or define their own places using datapoints outlined above.
4) The ability for 3rd party companies ($) or the web community (free) to supplement the data in the record with additional places. So that experts from any place in the world can provide good solid information about places.
5) Provide reports and book sections that print out this detail. When I do work for a client I give them place information in todays terms so they can go to the place a relative came from but I also provide historical information (previously used place name, alternate spellings, historical information, pictures) so they learn about the place a relative came from.
I'm sure that I've forgotten a few things since I'm writting this off the top of my head. In conclusion, the GEDCOM is only partly to blame, however the way data is entered and stored into the FTM database is completely the problem of FTM and they have done a poor job giving you/us a well design data entry process and an incomplete database. The additional data I've outlined here will be lost when exporting to a GEDCOM but so long as FTM creates a superior product generating a GEDCOM is not real important AND if they build into the database a field/column that contains a well formed PLAC tag that GEDCOM can use most people would be satisfied.
"One thing that needs to be thought about when suggesting these enhancements. What will happen to this data when a GEDCOM is made?"
Yes to a small extent the implementation of the GEDCOM standard is part of the problem, HOWEVER, a good database and application designer can easily work around this AND still get worthwhile data into the GEDCOM PLAC tag.
Unfortunately FTM and a lot of other programs do not put enough effort into the data entry and storage design of their own application to aid the user AND implement well formed GEDCOM PLACe data (or NAME tags, dates, relationships, etc.).
1) Place needs to have its own database record/table in FTM and not be a singular field within a "fact" record/table.
2) The place record/table should allow the user to enter complete information about the place. This information can include:
2a) Place name for external use in reports, display pages etc. Values in this field would be "Olso, Norway" -or- "New York City, New York, USA"
2b) GEDCOM name hierachy with all of the correct political divisions including county, township, etc.
2c) Historical name information, alternate spellings
2d) User defined information, including room for stories about places, pictures of places, etc
2e) Map coordinates
2f) Place Name part indexes, so that you can locate places by various name parts and historical/alternate names
3) Users (aka data entry people) should be able to select from a list of previously provided/supplied places or define their own places using datapoints outlined above.
4) The ability for 3rd party companies ($) or the web community (free) to supplement the data in the record with additional places. So that experts from any place in the world can provide good solid information about places.
5) Provide reports and book sections that print out this detail. When I do work for a client I give them place information in todays terms so they can go to the place a relative came from but I also provide historical information (previously used place name, alternate spellings, historical information, pictures) so they learn about the place a relative came from.
I'm sure that I've forgotten a few things since I'm writting this off the top of my head. In conclusion, the GEDCOM is only partly to blame, however the way data is entered and stored into the FTM database is completely the problem of FTM and they have done a poor job giving you/us a well design data entry process and an incomplete database. The additional data I've outlined here will be lost when exporting to a GEDCOM but so long as FTM creates a superior product generating a GEDCOM is not real important AND if they build into the database a field/column that contains a well formed PLAC tag that GEDCOM can use most people would be satisfied.