There are two kinds of concerns about RM’s implementation of Place Details. Let me call them “big picture” concerns and “little picture” concerns. I will write two messages, This message will be about the “big picture” concerns and the other message will be about the “little picture” concerns.
The “big picture” concerns have to do with exchanging RM data with other genealogy software. Some other software does not support RM’s Place Details. If the other software does not support RM’s Place Details, then the Place Details data is lost when you transfer your data.
Here follows a brief and very incomplete summary of the kinds of things that can happen when RM’s Place Details data is exchanged with other software.
GEDCOM. RM’s Place Details data is placed into ADDR records in GEDCOM. This is somewhat in conflict with the intended purpose of ADDR records in GEDCOM because ADDR records are intended to contain full postal addresses rather than just something like the name of a cemetery or the name of a hospital or the name of a church or the name of a street etc. Whether RM’s Place Details data is lost on a GEDCOM transfer ultimately depends upon how the software importing RM’s GEDCOM stores the ADDR data into its own database. My experience is that most other software does not import RM’s Place Details from GEDCOM in a way that is very useful.
FamilySearch. Until about 2019, FamilySearch didn’t really want things like cemetery names and hospital names and church names and street names etc. stored as part of their database at all. A place name in FamilySearch was simply city, county, state, country and there was no other place data. That has now been changed but there is still just one place field. So for example you can now have cemetery, city, county, state, country or hospital, city, county, state, country etc. When RM stores places directly into FamilySearch, the RM Place Details are not added to the front of the other place data and the cemetery names or hospitals names or church names or street names are lost.
Ancestry. Ancestry has not prohibited things like cemetery or hospital names to be a part of place names, but there is only one field. RM’s TreeShare feature supports an option to add the cemetery name or hospital name from its own Place Details field to the front of the place name when it is sending data to Ancestry. I’m not quite sure what happens when the same data comes in the other direction from Ancestry back into RM.
GedSite (a Web site generator). GedSite supports RM’s Place Details when it process RM’s GEDCOM. I’m not sure exactly what happens within GedSite’s internal database, but Web sites created with GedSite display RM’s Place Details + Place fields correctly without data loss.
GRAMPS (an RM competitor which is free and which is very limited in function compared to RM). GRAMPS imports a GEDCOM ADDR record as intended by GEDCOM. Namely, GRAMPS imports a GEDCOM ADDR record as a postal address and not as a Place Detail. Also, if a single Place in RM should happend to have more than one Place Detail, all the various Place Details are merged together into a single postal address in GRAMPS. Most Places in RM will have more than one Place Detail. For these reasons, GRAMPS cannot really handle RM’s Place Details.
Family Historian (a full function commercial product which is a competitor to RM). Family Historian can do a direct import from an RM database. It places RM’s Place Details field into a Family Historian field called Address. But Family Historian is able to process such imported Address fields very much in the same manner that RM treats its Place Detail field. The net result is that RM’s Place Details data is not lost upon import into Family Historian.
The bottom line is that you should not use RM’s Place Details feature if you are concerned about data loss when your data is transferred to other software. Some users care a great deal about this issue and some RM users care not at all about this issue. This issue would be much mitigated if RM’s interface to FamilySearch had an option to add the Place Details field to the front of the main place field like RM’s interface to Ancestry. This issue would be much mitigated if RM’s GEDCOM export process had an option to add the Place Details field to the front of the main place field like RM’s interface to Ancestry.