5 replies to this topic

[stst415]

My RootsMagic database generally uses modern geographical place names, such as...

San Francisco, San Francisco, California, United States

instead of the historical place names...

Yerba Buena, Alta California, New Spain

This is helpful in research (knowing where to go to find more records) and presentation (so that family members can understand where I'm talking about).

As my work evolves, though, I am finding many instances where I would like to also have the historical name.  I don't want to choose one over the other, nor do I want to go back through 18,700 people to update them all.

I am aware that I can use the old name and go to the Place List to plug in a "standardized" field, but this is useless if it only shows up in mapping or FamilySearch hints.  I need it to be visible on the Edit Person summary page (since that's where I'm working when I am doing new research) and it needs to export via GEDCOM too.

In a perfect world, a future RootsMagic update would include another field alongside Place Details where the Historical Name or an Alternate Name could be written out too.  In lieu of that, what are some possible workarounds?

I experimented with creating another Fact to represent the older place name...

CLICK HERE TO SEE WHAT I MEAN,
https://rata.la/2GmK...TSMAGIC-EXAMPLE

... but I don't particularly like having TWO entries to represent ONE fact, so I'm not sure if I'm going to keep this solution.

What are some other ways to solve this problem?

Thank you,
Scott Trimble
Los Angeles, California

[TomH]

Maybe some food for thought in this post but, yes, the real solution is full support for a new historical place and for standardized place. http://forums.rootsm...st_return=81833

[KFN]

Two place names are not enough! You need an unlimited list of place names associated with a place.

Their is a need for a set of fields that stores the from/to dates the places name is valid for, and a set of points that represent a location polygon, and you would need a language (or cultural) reference for the name (some places have different names based on language or culture for a given time period). I would also have a NOTE and Media field for each place.

[TomH]

Agreed. The database structure to support time variant place names might bear similarity to that of County Check's database but down to an even lower level. Arguably down to an address because street names and even street numbers change over time. However, I fear the complexity of accommodating all these variants is a deterrent to development and, ultimately, to users should it see the light of day.

[Don Newcomb]

Historic place names is an oft commented subject. The problem is just how much "history" do you want to support. A some point every place was called "Grok-Ugh" (which translates roughly to "my rock"). It's the same as with names. It would require massive changes in the database structure to accommodate all possible global variations in naming conventions.  

[TomH]

The changes to the database structure may not be so massive to support what might be Alternate Place Names, akin to Alternate Person Names. The latter are stored in the same table using the same fields as the Primary Name. The only thing that distinguishes them is the IsPrimary flag: 1 for Primary, 0 for Alternate. All of the names for a person have the same OwnerID value, the RIN of the person. The NameTable also has a Date field, which can be a From-To range and a NameType field that holds a number corresponding to, e.g., "AKA", "Maiden", "Married:,...

 

The PlaceTable already supports 3 PlaceTypes, 0=LDS Temple, 1=Place, 2=Place Detail and a MasterID which is the PlaceID of the Place to which a Place Detail belongs. Every record also has fields for Name, Abbrev and Normalized (name) along with Latitude, Longitude, LatLongExact (unused?), and Note. A new PlaceType=3 could designate an Historical Place name (here's where a Date column needs to be added for sure) and a 4 could designate an Historical Place Detail.

 

Each historical place can have its own geo-coordinates. The idea of boundary plotting is wonderful but I wonder if simply adding a radius for a circle or the dimension of a square for a place that is a crude approximation of its size would go a long way toward mapping that more analogously represents how precisely we know the location of an event than the oft-overstated pinpoint.

 

The biggest issue in going this far is not the database structure - it's the programming that uses it. There are a number of unused columns among the 25 tables in a RM database that represent design intentions yet to be fulfilled.