This may be a simple question/request - if I have missed the answer elsewhere, please forgive me!
I use Family Tree Maker and like the fact that a places report can be generated. However, I think I would find it more useful if the report could be output in different ways. The most useful would be if it could be organized by state, then by county, rather than strictly alphabetically.
Have I missed how to do this?
You can't do any such report as this before the current version of FTM2012
With the current version, you have limited capability:
Go to Places Menu
Turn on Heirarchical view (lelft button of button bar in left panel of Places)
Clean up places to get them into the heirarchical view. You must assign countries, resolve all place names (you can now resolve addresses and church names and cemetery names etc with the new resolver).
After you have (spent hours) cleaning up your places:
Go to heirarchical view:
Click on "linked to this place" or "link" to all", as you want
Go to USA
Go to your state
Go to your county
Go to your city
Now, hit the Print button in the upper right
Choose Print this report only
DON'T choose Print Place Usage Report - that will print your whole file and will take forever and a day and chew up a lot of paper.)
Play around with it and you'll get the idea.
The people within the place will be printed alpha by last name, then alpha by first name.
I think that is about as good as you are going to get.
If your Places file is like a lot of people and not resolved, you can go to a Custom Report and try to print a county or town at a time. This can be a challenge if you have a places that has other places with the same name (particularly places with common names like Washington, Fremont, Jefferson, etc).
Sounds like an upgrade to FTM2012 is in my future - I am still using 2010.
Thanks for the reply - I will upgrade, and then try your suggestions.
One issue I have with FTM is the inability of the program to deal with extinct or unincorporated towns/communities in a satisfying way. I am not sure how they would manage this, but it is aggravating.
Just ignore the places that are NOT in the mail system, which is what "Places" is based on. The places is based on the "Mail" location of the different mail services of the different countries around the world.
The other family database programs that use a similar tool, have the same problem.
FTM 2012 has been enhanced in this area of concern when the last update is installed.
Ancestry has announced they are not going to have an FTM2013 (like no 13th floor?); so getting FTM2012 now is ok.
The issue of historical names, names in records, aka names, villages & hamlets in states like New York, neighborhood names in big cities - like Los Angeles, etc has been cussed and discussed here ad infitum.
I think the solution on that score it to simply consider the PNA as a guide, a spell checker, and a rudimentary county finder - and if a place name does not fit into that scheme, just leave it alone (ie unresolved) or ignore it (ignore).
The problem with that approach is that only resolved places go into the heirarchical view. That means the heirarchical view is useless to me. As I have many names that I do not want to fit into that round hole.
The new ability to resolve church and cemetery names and include five part names for villages and hamlets in New York does provide a little help, but it is still a long way from curing the whole problem. It would be simpler if they just gave ALL names in heirarchical view, regardless of whether resolved or not.
A possible answer would be to allow users to select the way the place names are listed/reported. Or, like most database programs, allow users to select multiple criteria to form a report.
Got to be a way to simplify this process! :)
This was a feature in the earliest versions of FTM. The place name was broken out by city, county, state, country and you could go into the field and edit (similar to how you can go into a name and edit Prefix, First Name, Last Name, Surname. It was a feature that I hated to see go when they upgraded to newer versions of FTM to accomodate the mapping feature.
That is exactly what we need again! They could add in additional, customizable fields for things like cemetery names, or hospital names. There should be a way to do this and still have the cool mapping features.
One thing that needs to be thought about when suggesting these enhancements. What will happen to this data when a GEDCOM is made?
Until the time that GEDCOM catches up with the real world and ALL of the program OEM's use and comply with the updated requirements, data is going to get lost.
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.