Why are some Places in NO Events?

[strathglass 0]

Several PLACES in my MASTER PLACE LIST don't show up in any events.

(I.e. in the Master Place List, select a place, click on Events: no events are listed!)

 

Is this normal? Can I delete these (apparently unused) places?

(And if so how [there doesn't appear to be a delete function in the Master Place List]?)

If it matters, this data was imported from FTM 2005.

 

Similarly, there are some places that are very similar and should be consolidated. (E.g. "E. Greenwich, RI" and "East Greenwich, RI")

Is there a way to do this?

 

Finally, as a related aside: do you still refer to a place by its current locale name even if at the time of the event that the place is associated with the place had a different name (e.g. "E. Greenwhich, RI" event was before US independance, and what about Upper Canada vs. Ontario for Canada)?

 

Thanks,

strathglass

[nbradley 0]

Strathglass

 

Places with no Events - run Optimize under File, Maintenance, the strays should dissappear

 

Similar Place Descriptions - fix the "near duplicates" up to make them identical using Edit under Tools, Master Place List. Then run optimise and your newly created duplicate will dissappear.

 

Places where the names changes - this comes under the heading of "User Preference". It has been discussed a few times on this board. If you do a search you should be able to find the threads. Doubtless it will also have been discussed on the TMG Mailing List. I tend to use the latest geograpghic description and put the historic info in the memo field but there are many many other views on that issue. In the end you need to choose an approach that suits you and how you want to use the data.

[strathglass 0]

Excellent input Neil, thanks.

 

Only one issue: the optimize cleaned up some of the orphaned places, but I see at least one (the first one in the master place list) is still an orphan (has no associated events).

Anyone have any ideas on what the issue might be?

(In the mean time I may have to check all the other places to see if any other orphaned places remain after the optimize, or if it is just the 1st one.)

 

Thanks,

strathglass.

[Paul Lawrence 0]

Excellent input Neil, thanks.

 

Only one issue: the optimize cleaned up some of the orphaned places, but I see at least one (the first one in the master place list) is still an orphan (has no associated events).

Anyone have any ideas on what the issue might be?

(In the mean time I may have to check all the other places to see if any other orphaned places remain after the optimize, or if it is just the 1st one.)

 

Thanks,

strathglass.

 

It could be attached to a Repository....

[Virginia Blakelock 0]

Finally, as a related aside: do you still refer to a place by its current locale name even if at the time of the event that the place is associated with the place had a different name (e.g. "E. Greenwhich, RI" event was before US independance, and what about Upper Canada vs. Ontario for Canada)?

 

This comes up regularly on the TMG rootsweb list, for example this thread in the archives:

http://archiver.rootsweb.ancestry.com/th/r...2-04/1018839591

 

The archives are at

http://archiver.rootsweb.com/cgi-bin/search?path=TMG

 

To subscribe to the TMG list:

http://lists.rootsweb.com/index/other/Software/TMG.html

 

Virginia

[strathglass 0]

Thanks Paul.

I checked the repository list, but unfortunately it is not attached to any repository either.

Anyone have any further ideas?

 

And thanks Virginia for those links, they're just what I needed!

 

-strathglass

Edited April 3, 2008 by strathglass

[retsof 0]

places with no events...

 

Any tag can have a place...Christening, occupation, etc. etc.

I'll still put the non-place information into the memo field.

 

I end up MOVING a lot of place information into memo fields, since a lot of GEDCOM imports put it into the place. I notice that every comma becomes a separator that puts part of the import into a different place field.

[Michael Hannah 0]

Places are not stored with events. They are separate entries in their own separate data table, which is called the Master Place List (MPL). There are a number of issues concerning apparently duplicate places in the MPL and apparently unlinked places because it is a separate data table. The maintenance command "Optimize" is essential when modifying the MPL and "cleaning up" places as that command will do the actual merging of truly identical entries and the actual deletion of entries you have marked for deletion. The existence of places as a separate data table has two implications.

 

First, there is nothing wrong with having place entries in the MPL that are not linked to anything. I have several that I have entered when I was standardizing how I wanted entries in my MPL to look that I knew I would need "some day" but that day has not yet come for all of them.

 

Second, tags simply link to the place entry in the MPL. Separate tags that are the same place do not have separate place entries in each tag. This is both good news and bad news. The good news is that if you change the place entry in the Master Place List then all events that are linked to that one place entry have their place changed. The bad news is that if you only meant it to affect one tag you may have inadvertently affected lots of tags. That is why the Events button is valuable when dealing with place entries in the Master Place List to show you all the event tags linked to this place entry.

 

Finally, when entering new places it is tempting to use the F2 function key when the cursor is in a place field in the tag entry screen to find existing entries in the MPL for that place field. Unwanted duplicates or unwanted changes to the MPL are often introduced due to the clever and (probably) useful but non-intuitive (to me) functioning of the F2 key as it applies to searching for existing entries in the MPL. In searching the MPL, F2 finds all entries that match what is entered in the field containing the cursor and any non-blank higher level fields from that point on. Only MPL entries where all lower level fields are blank are displayed as choices even though the MPL may have multiple entries with non-blank lower fields and your tag entry may have values in these lower field. These other entries are not shown because TMG has no way to determine which one, if any, you want. When the F2 list is displayed TMG explicitly labels the list of entries with the field names of only the cursor field and higher trying to warn you that it is not showing these lower fields. The only way to ensure that when you use F2 you search the entire MPL is to force a non-blank value in the Addressee [L1] field of every place, and always put your cursor in a blank [L1] field when you use F2 on a tag entry screen. In effect that subverts the feature of the F2 key and shows the entire MPL. Many proposals have been offered concerning non-blank [L1] fields, but that is beyond the scope of this current discussion. A simpler alternative is just to bring up the actual MPL when trying to determine if you have already entered a specific place to remind you of how you entered it and spelled it.

 

Hope this sheds a little more light on the MPL,

Edited April 4, 2008 by mjh

[Jim Byram 0]

Just to be sure... What the MPL displays and what F2 displays are completely different. F2 does not draw on the place table at all. It builds a table on the fly consisting of linked place parts from the place parts tables.

[strathglass 0]

Thanks retsof, Michael and Jim.

 

Thanks especially for all the details Michael. Based on your detailed response, I have a couple questions for you:

 

You said "...the actual deletion of entries you have marked for deletion": how do you mark a place for deletion? I have not discovered a way to do this.

 

Also, I am not sure what you mean when you state that "Separate tags that are the same place do not have separate place entries in each tag."

Maybe because I am not clear what you mean by a tag.

I guess there is no "direct" way to pick a place in the MPL to use as the place for the current event, and I think you were describing a work around technique to achieve this. Correct?

 

Regards,

strathglass

[Terry Reigel 0]

You said "...the actual deletion of entries you have marked for deletion": how do you mark a place for deletion? I have not discovered a way to do this.

You "mark them for deletion" by removing all references to them in Tags or the Repository. But they are not actually deleted from the database files until you run the Optimize command.

Also, I am not sure what you mean when you state that "Separate tags that are the same place do not have separate place entries in each tag."

Maybe because I am not clear what you mean by a tag.

Tags are what TMG uses to record all details about a person - Name, parent/child Relationships, and Events. Of these, only events have places associated with them.

 

I think Michael is saying that the places are not actually recorded separately with each Tag, as it might appear from looking at the Tag Entry Screen, but are recorded in separate place files where identical places are not repeated.

I guess there is no "direct" way to pick a place in the MPL to use as the place for the current event, and I think you were describing a work around technique to achieve this.

If you are saying can you open the Master Place List and select a place there to enter in an event Tag, the answer is no. But to call the use of the F2 function a workaround makes no sense to me. It is the method designed to access the existing place data for entry into a Tag. It differs from the format of the MPL in that it's optimized for data entry in a Tag. It allows you to enter part of a place entry, say the Details field if you have a new street address in a city previously entered, then use the F2 function to enter the remainder of that place.

[strathglass 0]

Thanks Terry

You "mark them for deletion" by removing all references to them in Tags or the Repository.

I was afraid of this: my problem is I have some places that aren't referenced by any event and yet still don't get removed by the optimize command. Sounds like a bug maybe.

 

Regarding your last point, I am trying to understand exactly what Michael's concern was. It is not clear to me because I don't know what he means by higher and lower level fields. Can anyone help on this?

 

-strathglass

[Terry Reigel 0]

In the following list, the fields get "higher" as you go down the list:

 

Addressee

Detail

City

County

State

Country

 

In other words, the larger geographic areas are what we are calling "higher."

 

The idea is you may find new addresses, say, or perhaps a new cemetery, in a city you already have entered. So, enter that in the Detail field, put the cursor in the City field, and press F2. Type in a few letters of the city and then select the line with desired values for the rest of the fields.

 

Or, you have a new town name in a county you already have entered. Type the town in the City field, then use the same process to enter the county, state, and/or country based on previous entries.

 

Regarding places that stay in the MPL even though they don't appear in events or repositories, the issue is that having data in certian fields prevents their removal with Optimize. I've forgotten the details, but as I recall values in any of the fields in the MPL which cannot be accessed by the Tag Entry screen will cause the place to remain.

 

To see these fields you need to select a place and click the Edit button. They include the Short Place name, start and end year, and comment.

[Michael Hannah 0]

Terry's replies explained (more clearly than I did, which is why he has a popular book ) precisely what I intended to say. I also agree that F2 is not a "work around" and did not intend to imply that. My only reason for mentioning F2 was to make it clear, as Terry explained, that the list of places F2 presents is different than the entire MPL. I mentioned a method to make the F2 list more similar to displaying an entire MPL, but in my opinion that is not a "work around".

... my problem is I have some places that aren't referenced by any event and yet still don't get removed by the optimize command...

As quoted from the TMG Help topic on Optimize:

Optimizing will not remove unused place records for which a start year, end year, comment, or short place name have been recorded.

For example, I added comments for those places in my MPL that do not (yet) have any events linked to them so they are not deleted by Optimize. While you did check your Repository records for your places that have no events linked, it is worth noting that places for Repositories work just like places in event Tags. The MPL is also where the place data is stored for Repositories, and the Repository record simply links to the place entry in the MPL just like event tags. Again, the MPL avoids duplication, so you could have a place entry for a Repository that is the exact same place used in one or more event Tags and there would be only one place entry in the MPL for all of these links.

 

Hope this makes things clearer,

Edited April 7, 2008 by mjh

[Terry Reigel 0]

As quoted from the TMG Help topic on Optimize...

You mean I didn't have to try to recall the details; it was right there in Help all along?

 

Thanks Michael.

[strathglass 0]

Thanks very much Terry & Michael - I think you've straightened me out.

Now I just need to go clean up the data for all my places (and my MSL too).

 

-strathglass

[Michael Hannah 0]

You are most welcome. The more you learn the more you will be able to successfully use TMG, and ultimately be able to answer other people's questions yourself.