Place names with map programs

[John Garvert 0]

Hello,

 

If I use the name of a place at the time of the event, which differs from the modern political name, will I have problems with the various place look-up buttons or external programs such as AniMap, Map My Family Tree, etc?

Likewise, does it matter if I use the English spelling or the spelling the native language?

 

What I am trying to do ... avoid changing to a consistent convention in a thousand places and find out I did it wrong!

 

I am trying to clean up my database place names to be consistent. For some places I have multiple variants, the modern "political" place name in both the English and German spellings, and the old name (at the time of the event) in both the English and German spellings, and in a few cases, some mixture of the old and new names in both languages. Of course, this repeats for other languages/countries as well. And then there is that whole changing county names in the US, but I digress.

 

My preference is to use the name at the time of the event in the native language, after reading Getting the Most Out of TMG. I am still deciding on how to convey the modern or English name.

First I was considering using the memo field somehow, or more likely creating additional tags for each tag group like BirthModernPlace and BirthEnglishPlace.

But then I read a post on the forum that caught my attention, about adding a non-person with the alternate spellings, creating roles for events with conflicting names, and adding the associated persons as witnesses using this role. I think that will control how often it prints.

I don't want a narrative of a person to repeat a phrase like "Rhede, Westfalen, whose modern name is Rhede, Nord Rhine-Westfalen, Deutschland, whose English spelling is Rhede, North Rhine-Westphalia, Germany" for every tag event for a person born, raised, lived, died and was buried in the same town.

 

Place names always get me wrapped around the axle. I know this topic is probably only second to censuses for opinions, but I would gladly read about any suggestions, advice, experiences or warnings. Thanks

Edited July 15, 2008 by John Garvert

[Michael Hannah 0]

I know this topic is probably only second to censuses for opinions, but I would gladly read about any suggestions, advice, experiences or warnings.

Yes, John, I think you may be right.

 

For my purposes, I am recording history, so always use the place name as recorded in the sources I am citing. If I choose to link the multiple names for the same location I use other tools, but retain multiple places in the Master Place List.

 

I searched the Forums and you might want to look at these earlier discussions:

if a place name is changed and changes in place names.

 

Hope this gives you ideas,

[John Garvert 0]

Thanks for the links Michael.

I had already looked at those as well as many of the online tips. I guess that is why I was all wrapped around the axle and started this post. Information overload.

 

I then started to implement the "place-person", but I decided that was getting too confusing. Plus, I already use "non-persons" for cemeteries, census, hospitals, etc, and by using TMG in a non-standard way, I got burned when I discovered that excluding witnesses does not work like it does for principals, citation sources, etc. (see prior post Hidding "non-person" witnesses).

 

So I decided on a simpler approach I think will work, still working out the bugs (opinions welcome), although it includes evaluating the best implementation approach for each individual and place separately.

 

I created several new place styles like "DE (modern in German)", "DE (modern in English)", and "German Old".

I then created two new Address Group tags,

"PlaceModernDeGerman", default place style "DE (modern in German)" and identical Principal/Witness sentences "<The modern name is [L].><M.>"

"PlaceModernDeEnglish", default place style "DE (modern in English)" and identical Principal/Witness sentences "<The English spelling is [L].><[M].>"

When I have a tag's place with both an old and modern name (a birth tag for example), I change the individuals birth tag's selected place style to "German Old" and enter only the location place information relative to the time period of the event. The exact data from the source is recorded in the source citation/footnote. I then optionally add a tag "PlaceModernDeGerman" with only the location fields populated, the sort date only (to position the sentence in the narrative), and an optional memo if additional clarification or historical note is desired. I then optionally add a tag "PlaceModernDeEnglish" in a similar manner.

If the individual spent their whole life in this one location/town, I only include these two tags once, typically after the birth tag, so the information is not repeated a dozen times in a narrative report. Plus, I could totally exclude all these place tags from reports if desired. If the person has tag events in various locations, I can repeat this process for each location as appropriate. In special cases, I could condense the place tags to identify only component that changed, such as the country or state/country.

This approach allows the place's start and end dates feature in the master place list to be utilized (I hope).

For places without these multiple names, I just enter locations using the "U.S. Standard Place".

 

I repeat the creation of new tags for each language of interest. The DE in the names above would be replaced with the appropriate country 2-letter ISO abbreviation.

I also created a new location place style "US Old" and a new tag "PlaceModernUS" using the "U.S. Standard Place" style. I will use the "US Old" place style for tags with locations in territories and counties that have been renamed, followed by the optional PlaceModernUS" tag. Obviously, the "in English" place style and tag are not needed here.

 

The only flaws I see are:

- There is no direct link between the old and modern names, or foreign language and English names, the best I can come up with is using identical LatLong entry and a place's comment field in the master place list for common places. A manual process bound to be applied inconsistently over time.

- If I have a lot of individuals in a specific city, I will have to create PlaceModernXXLanguage tags for each person which may be identical except for the sort date. Because of the sort date, the same tag with witnesses cannot be re-used.

- I have to manually verify I have consistently applied this approach for all location through the entire database, but I already have that issue in a lot of other situations, so whats a few more ... (as a software engineer, this makes me cringe )

 

I hope this will work to meet my needs. Any potential pitfalls I have missed?

[Michael Hannah 0]

Hi John,

 

Sounds like you have come up with yet another way, and one that will work for you.

 

I think I may have been the one who suggested the Place non-persons. They work for me because I don't have that many, only for a few really confusing places that changed their names (and what county or state the were in) a lot. Probably too burdensome for all places. However, for a few of these Place non-persons I have defined Name-Var tags for them, and use the Name variables for this "Witness" instead of the Location variables. It keeps all the names for this one place in one spot in the database, and I can put a date range on the Name-Var tag. The down side comes with the place name winding up in a Name index rather than a Place index, forcing work-arounds. I think I like your solution for multiple names better and may incorporate it into my process.

 

Your separate place tag idea could also optionally print the Location information at the end of the "normal" tag sentence thanks to the new V7 sentence concatenation variables which did not exist when I was designing my system. Being separate custom tags you can select whether or not they print. Sounds really promising. I will have to think about it some more.

There is no direct link between the old and modern names, or foreign language and English names, the best I can come up with is using identical LatLong entry and a place's comment field in the master place list for common places. A manual process bound to be applied inconsistently over time.

I can't think of anything else you can do. That is why I use the non-person approach. Any new information or changes I make automatically link to all usages. But it also requires a manual process prone to inconsistencies. You may want to create the non-persons just as the spot to record the information about the various names for the place over time and in all the languages, but not actually link them to "real" people tags. It might help with your consistency. A List of Places report also might be helpful to periodically check your consistency.

 

Thanks for sharing your ideas, great food for thought,

[RobinL 0]

Some time ago I made a request that the Place Name system be extended to use a simular mechanism to the Person Name system uses for Name variants.

 

That is, that Places could have place name-variants associated with a Primary Place name. This would allow for names that are different with politics, language and date.

 

When entering a place for an event you could associate that variant with another Primary place name. This could be used for simplified reporting or filtering, but allowing the appropriate place name variant to be selected for reporting (in sentences) etc when that option was selected.

 

This would divide the Master Place List into 2 levels, Primary only and on the second level, the variants that are synonyms for that place. It would require some extra management when restructurung which Place name variant entry should become a new Primary entry.

 

I believe a variant of this technique would overcome the current "ducking and weaving" that is being attempted in this thread.

[Michael Hannah 0]

I agree, Robin, and would be a big aid in research to be reminded which place names are really the same location. No matter how great we think TMG already is (and I do) we can always come up with ideas to make it even better.

[Michael Hannah 0]

Since you are considering adding custom Place Name tags to sort relative to the "real" event tags, you will be using special Sort Dates for multiple tags all associated with the same event date. You might want to save this list as a memory aid for how TMG date modifiers cause dates to sort. For example, all of the following Sort Dates would put a set of tags associated with an event on 21 July between any similarly constructed set of 20 July and 22 July Sort Date tags. I have adopted this scheme because I like to have the "actual" date (e.g. 21 July 2006) remain as part of the specially constructed Sort Date.

 

before 21 Jul 2006

before 21 Jul 2006?

say 21 Jul 2006

say 21 Jul 2006?

circa 21 Jul 2006

circa 21 Jul 2006?

21 Jul 2006

21 Jul 2006?

after 21 Jul 2006

after 21 Jul 2006?

21 Jul 2006-22 Jul 2006

21 Jul 2006-22 Jul 2006?

21 Jul 2006-23 Jul 2006 --- etc.

21 Jul 2006 or 22 Jul 2006

21 Jul 2006 or 22 Jul 2006?

21 Jul 2006 or 23 Jul 2006 --- etc.

21 Jul 2006 to 22 Jul 2006

21 Jul 2006 to 22 Jul 2006?

21 Jul 2006 to 23 Jul 2006 --- etc.

 

Notice that with the "etc." forms, you can have an unlimited number of events on a given date sorting in the order that you desire.

 

Hope this helps with your Sort Dates,

[mkd19 0]

How about using LatLong data to supplement the "Old German" name. Then you know you can find the place, regardless of any subsequent name changes.