Thanks, Russ and Christine, for the responses. In answer to your question, Russ, the main reason I enter addresses into my FTM database is simply to preserve that information in case it will be of some benefit to me or someone else in the future. I'm not doing it for any particular reason, such as to display the information on an FTM map, although certainly I do that when the need arises. I want the location information I enter into the FTM database to be consistent with the Place Name Authority, but not to lose its accuracy just to make it conform to limitations of the Place Name Authority. As an example, take a dwelling located at the USPS address of 285 Spring Street, State College, PA 16801. That dwelling is not located in State College, but in College Township, Centre Co., PA. Note that State College is also located in Centre Co., but it is not located in College Township. Russ, under the system you use, how would you enter the information for that dwelling into your database in a way that is compatible with the PNA? Thanks for the help, Jim Hoke ---------------------------------------------------------------------------- ---- From: H R Worthington [mailto:rworthington@att.net] Sent: Tuesday, March 10, 2015 11:36 AM To: Jim Hoke; ftm-tech@rootsweb.com Subject: Re: [FTM-TECH] Resolving Place Names Jim, Question: What are you using the USPS "address" for ? For my family research, I want to place the location on the Map in Family Tree Maker. So, to do that, I use the Place Name Authority format. In the ADDRESS Fact, I put the full street address. I don't care about the Zip Code. BUT, If I did, I would put that in the ADDRESS Fact Description field. Oh, and I mark ALL Address Facts as Private. In the Residence Fact, I do not include the street address. IF a Census Record gives me the Street and House Number, I put that into the Address Field, and just the City, County, State, Country in the rest of the Residence Fact. Yes, for Census Records, it's could be a double entry. But, for two or three purposes. I can time line the Address and Residence Fact I can see you all lived at an Address I can see all who had an event in a Place (City, County, State, Country) One users approach to your question. Russ ---------------------------------------------------------------------------- ---- From: Chris Bauman [mailto:chris.bauman@comcast.net] Sent: Tuesday, March 10, 2015 11:27 AM To: Jim Hoke; ftm-tech@rootsweb.com Subject: Re: [FTM-TECH] Resolving Place Names Jim, I played around with a town in 2 counties. If I entered "address, city, state" then clicked resolve address, it obviously doesn't resolve. But if I click (in the resolve places window) the button to the left (arrow up), it moves the street address to the line above. Then it suggests my options, which includes both county choices. Choosing the correct one and clicking "replace" puts that one in. Back in the PERSON view, the address is kept in the location field. Looking at the PLACES view, I see drop down lists on the left. I get USA, then State, County, and City, with the street address below that. The map happened to place the thumbtack across the street, but I could move that to the correct location. Your situation is a little different due to Alexandria being an "independent city" in Virginia, but it's similar. If I put in your example the same way, and move up the street address, I get choices for both "Alexandria, Independent Cities, Virginia" and "Alexandria, Fairfax, Virginia". Choosing Fairfax County places the thumbtack correctly on the map, and the drop-down list in PLACES view shows it correctly. But you DO lose the zip code. Although that could be entered in the description, I suppose. You are right, the PNA can't tell you automatically that the above address is in Fairfax County, but it can let you distinguish between the Independent City and the other areas named Alexandria. It's going to boil down to how you want the data stored in your file. Personally, I have the street address in the description field, and I don't worry about the zip code--but that's me. Having played around with it a bit, though, I may consider moving the address up to the location field--it's kind of neat to be able to pull up the map and see the points. On the other hand I don't know if I want ALL of that printing in charts and reports, or taking the time to enter shortened versions. I'll think about it a bit before making a move. I don't know if that helps you or not. Good luck in deciding how you want to handle it! Christine ---------------------------------------------------------------------------- ---- From: Jim Hoke via <ftm-tech@rootsweb.com> To: FTM-TECH mailing list submission <FTM-TECH@rootsweb.com> Sent: Tuesday, March 10, 2015 10:26 AM Subject: Re: [FTM-TECH] Resolving Place Names Since the discussion several weeks ago on resolving place names, I've been slowly working my way through my FTM database, revising the Residence entries and other location-related facts to be consistent with the Place Name Authority. One facet I'm still wrestling with is how best to enter U.S. Postal Service mailing addresses. The problem is that the USPS address might not clearly reflect the geographic location in terms of city or township. For example, a sample address in our area is 2401 Cavendish Drive, Alexandria, VA 22308. Not only is that address not located in Alexandria, it is in a different county from Alexandria, namely Fairfax County. Similarly the USPS address can indicate a city or town that is not in the same township as the location designated by that address. Thus, the Place Name Authority cannot accurately reflect the location for the USPS address. At this point one option I have considered for entering USPS addresses is by using just the Description portion of the Address fact. Putting the USPS address in the Place portion of the Address fact creates a PNA conflict. I guess another option is to put the entire USPS address (including street number, street name, city, state, and zip code) in the Description portion of a Residence fact. Any suggestions on a better approach would be greatly appreciated. Jim Hoke