Jump to content


Photo

Share Data does not transfer Place Details to FSFT

FamilySearch Family Tree place details

  • Please log in to reply
7 replies to this topic

#1 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6268 posts

Posted 06 August 2013 - 10:36 AM

I note that there is no transfer of Place Detail from RM 6.3.0.2 to FSFT. Is there any intention to address this problem? If no upgrade of the FSFT API is likely, what about the alternative of concatenating Place Detail, Place in the transfer to the FSFT Place?

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8491 posts

Posted 06 August 2013 - 11:20 AM

Confirming enhancement request is in our tracking system.

One of the problems we have is FamilySearch doesn't want people to add "Place Details". They are looking for just a standardized place name. (Town, County, State, Country) That is why we are not sending it. But, as you see people are adding them anyways on FamilySearch. We need to work this out with FamilySearch before we make changes in sending the Place Details. Eventually FamilySearch will have a notes field, maybe that is where they would want this information. For now you could always copy the Place Detail into the reason statement so it's on the record.
Renee
RootsMagic

#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6268 posts

Posted 06 August 2013 - 12:13 PM

As a workaround for the current constraints, then the choices for placing the Place Detail are:
  • Concatenated with Place, but FamilySearch does not want that.
  • Copied to Reason but that field does not transfer to other RootsMagic and probably all other databases.
  • Concatenated with event Detail/Description which is where some used to put Place Details but I am having a problem seeing the transfer of Detail from FSFT to RM, despite the online changes which added the address to the Residence and Census facts being shown in the RM Changes list.
I'm wondering whether a batch procedure that copies the Place Detail to the Event Description in RootsMagic would be a useful interim tool until this gets resolved.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#4 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8491 posts

Posted 06 August 2013 - 04:13 PM

I am not aware of any event descriptions moving over to FT.
Renee
RootsMagic

#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6268 posts

Posted 06 August 2013 - 06:18 PM

I am not aware of any event descriptions moving over to FT.

I witnessed it happen today, although the reverse direction after a change directly on FSFT, did not seem to work until some other event upload.
Edit: see my message http://forums.rootsm...ion/#entry59434 for an example of event Description travelling both directions.

Edited by TomH, 06 August 2013 - 07:11 PM.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#6 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3608 posts

Posted 06 August 2013 - 06:31 PM

One of the problems we have is FamilySearch doesn't want people to add "Place Details".


I know I'm preaching to the wrong choir here. I should be preaching to FSFT. But all I have to say is "yuck"!

Putting aside the issue of whether things like cemetery names are better stored as a part of a concatenated Place name or as a separate field called Place Details, wouldn't good genealogy and good research indicate that cemetery names for burials are important data that ought to be recorded and documented? The current standardized place name standard does not accomodate cemetery names at all. The case may be a little less compelling for other uses of Place Details such as hospital of birth or death for people who were born or died in a hospital. I just think the whole concept of a standardized place name as is being implemented at FSFT is just wrong.

I'm an IT person and I do understand in general why it's important for data to be clean and why for certain data elements in certain databases it's essential for the data elements to be standardized (e.g., "M" and "F" for male and female, respectively, rather than sometimes entering "M" and sometimes entering "male" - that sort of thing). But imagine if FSFT insisted on standardized surnames, and anybody with a surname of Smithe or Smyth or Smythe or Schmid had to be entered as Smith because of the standard. I don't see place names as being much different.

Well, I could definitely see the concept of structured place names where "details, town, county, state, country" could be stored separately and only concatenated for display purposes. And I could see software being smart enough to have a standardized place name storage format for its structured parts and also have a way to display the structured parts in a different format. For example, if the standardized storage format for the country of which I'm a citizen were "United States", then there could be various standard display formats to choose from such as "USA", United States of America, or just null for those of us who don't want to attach United States to every place name in every report.

There are counties and towns that have the same name, and it can be hard to tell which is which sometimes. It's common for one county to have multiple towns. It's not as common, but some towns have multiple counties. The current standardized place name does not deal with many of these situations very well at all. And for darn sure, you don't want anything displayed with a ,,, in it. For display purposes, there would have to be a way to have nulls for each and every structured part, including nulling out the separating comma.

I realizing that I'm supporting a position that stands no chance of winning out, but the standardized place name concept that we have right now is just awful.

Jerry

#7 J P

J P

    Advanced Member

  • Members
  • PipPipPip
  • 302 posts

Posted 14 August 2014 - 04:08 AM

Confirming enhancement request is in our tracking system.

One of the problems we have is FamilySearch doesn't want people to add "Place Details". They are looking for just a standardized place name. (Town, County, State, Country) That is why we are not sending it. But, as you see people are adding them anyways on FamilySearch. We need to work this out with FamilySearch before we make changes in sending the Place Details. Eventually FamilySearch will have a notes field, maybe that is where they would want this information. For now you could always copy the Place Detail into the reason statement so it's on the record.

 

Sorry to return to an old topic but have been experimenting and struggling with this issue of getting the Place Details information to FSFT.

 

As I see it, they prefer the standard place names but allow you to "extend" them with the equivalent of Place Details. This is from their user guide:

 

 

If you want to include extra information that does not appear in the standardized place, such as the name of a hospital, cemetery, or church where the event took place, do the following:

 

If you do that using their web interface, you can specify such information followed by the normal place naming hierarchy, but it also encourages you to then select a standard name as well. Both are visible when you go into edit the "fact" but only the "concatenated" one is displayed on the summary panels. This would suggest that they ought to be able to extend their API such that RM could supply a new parameter which is a concatenation of place details and place to be used as the default to be displayed but could also supply just the place as the existing parameter which FSFT would try to use as the standard name to be displayed when going into edit, and perhaps to be used for searches on location.

 

Whenever and if an opportunity arises, RM should be lobbying for such an API extension. Maybe RM should then also have a parameter as to whether the individual user wants this concatenation to happen.

 

Of course, many of us split out Place Details when RM introduced the option, but now we are reaping an unfortunate dividend.



#8 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8491 posts

Posted 14 August 2014 - 05:40 PM

Confirming RootsMagic and FamilySearch are aware of this issue.  For now you could add the place details in the "reason for this change box".  It's a field with a Red box around it whenever you add or change a fact on FamilyTree through the Share Data tab in RootsMagic's FamilySearch Person Tools. 


Renee
RootsMagic





Also tagged with one or more of these keywords: FamilySearch Family Tree, place details