Jump to content


Photo

Places and Ancestry TreeShare


  • Please log in to reply
16 replies to this topic

#1 pstaveley

pstaveley

    Member

  • Members
  • PipPip
  • 24 posts

Posted 09 October 2017 - 12:28 PM

One of the benefits of using RM is that you can change the place and location spelling and details for all entries for that place or location.

 

I am finding that changing the places and locations does not change the status of that individual to 'changed'. Even an individual edit in RM does not change it to 'changed'.

 

Therefore, the only way to push that change back to the Ancestry tree is to clear the 'only show changed people' and find and highlight each affected individual in TreeShare. Finding those changes is very time consuming.

 

Can TreeShare be altered to mark every changed individual to 'changed' regardless as to where in RM the change is made?



#2 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2701 posts

Posted 09 October 2017 - 02:31 PM

The original release of TreeShare worked in the way you wish that it might work. It was changed because the change of the spelling of one particular place could effect dozens or hundreds or thousands of people, and each individual person would then have to be manually approved for sync with ancestry. Manual approval of so many people could be so burdensome as to be unmanageable. 

 

The "fix" was not to change the status of individuals to "changed" when an item in the Place List is changed. Many users are hoping that this "fix" is only a temporary measure until some sort of bulk approval can be implemented for changes to the Place List.

 

Only the developers know what the plans are to deal with this problem. I think that if all the developers did was change it back, it wouldn't really solve your problem because you would be back to having to manually approve dozens or hundreds or thousands of changes for only a single change of the spelling of a single place.

 

Jerry

 



#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5554 posts

Posted 09 October 2017 - 02:39 PM

This is a rebound from the problem which some complained about and was addressed so that such place changes in RM would not obscure other changes. As you note, a single place edit in RM can result in many changed people in TreeShare Compare. Some of those people and some others may have other changes. Apart from bulk acceptance of all changes as an enhancement, perhaps there needs to be a filter in TreeShare so that the user can choose to see only differences in selected criteria, e.g., places, events, master sources, citations, media, names, couples, dates, descriptions...

Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#4 pstaveley

pstaveley

    Member

  • Members
  • PipPip
  • 24 posts

Posted 09 October 2017 - 02:55 PM

I am not even asking for bulk acceptance, although that would be helpful.

 

All I want is that if there are any changes or differences on either side then they are shown on the changed list. I am then happy to have to click on each individual to share that change up to Ancestry or mark it as not changed and keep the RM data different to that on Ancestry. Obviously with TreeShare I can edit each side individually ir necessary. So if I make a change to a place name I will then only see the list of individuals who are affected and individually decide to propagate that change up to Ancestry.

 

As I said currently I either have to scroll through each individual to find those changes (which with a database of nearly 9,000 individuals is very time consuming) or do complicated checks with saved reports to try to find the affected individuals.

 

Of course it takes time to generate those reports.



#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5554 posts

Posted 09 October 2017 - 06:50 PM

What you are asking for is a return to how TreeShare initially worked. Many users objected and development changed it to ignore place changes. Neither is generally acceptable which is why I am suggesting a more granular choice of what gets compared.

A frequent request is for bulk acceptance of all changes in one direction or the other. That, too, would benefit from such filtering.

Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#6 Jim Byram

Jim Byram

    Advanced Member

  • Members
  • PipPipPip
  • 50 posts

Posted 10 October 2017 - 08:39 AM

There is one flaw in this discussion.

 

Using FTM, I standardized all places for a test database. These changes get synced back to Ancestry. OK so far.

 

Then I discovered that if you open any source for an event in Ancestry, the place is changed back to the format that Ancestry used when the source was first added. There went the nice reformatted place.

 

Bottom line... It's not worth the effort standardizing the places in your database application if you plan to ever revisit that source in Ancestry.

 

RM not syncing the place structure actually gets around this problem. You can have your RM database places formatted like you want and just ignore what Ancestry does with the places.



#7 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7301 posts

Posted 10 October 2017 - 11:54 AM

You can create a group using Any Fact - Contains and the place name you changed to. Then in TreeShare use that group to filter on. You can go through each individual to add the change to Ancestry.


Renee
RootsMagic

#8 pstaveley

pstaveley

    Member

  • Members
  • PipPip
  • 24 posts

Posted 10 October 2017 - 02:16 PM

That is a partial workaround but that filter would then provide all the individuals who previously had the new place name and so they do not need sync'ing again with Ancestry.

 

The situation is something like this: If a hint provides a place "Here Upon There" but its official name is "Here-Upon-There" (i.e. with the hyphens) then it is easy in RM to change the non-hyphened version to the hyphened version (I normally just merge the two versions with the hyphened version remaining). However, if there are already 500 instances of the hyphened version in RM (and in Ancestry) then filtering on the hyphened version in TreeShare would still provide me with 501 instances for me to plough my way through to find the one instance that it is wrong in Ancestry.

 

The reason for using standardised places is so that it is easier to do statistical queries in RM and it helps when using a atlas against timelines.

 

I have not found an instance when Ancestry changes place names back and certainly not without me knowing about it. Obviously if there is a hint then it will use whatever was on the original record. Even then you have to individually tell Ancestry (when online) to overwrite a place name (or any other fact) with the data from the hint. Even for new facts, which have a non-standardised place name, I can cope with that by simply using the above system to bring the fact and sources into RM, clean it in RM and then sync it back to Ancestry.



#9 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7301 posts

Posted 10 October 2017 - 02:26 PM

Make the group before you change the name. Then you will know which people you need to focus on.


Renee
RootsMagic

#10 pstaveley

pstaveley

    Member

  • Members
  • PipPip
  • 24 posts

Posted 11 October 2017 - 03:10 PM

Hmm, it is unhelpful that the place list is modal meaning that you cannot create the group while the looking at the place information especially if you have split the place and location facts. It would be so much easier if there were fewer modal screens and a way of RM automatically changing a changed flag when a change has been made.

 

However, thanks for the very complicated workaround.



#11 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7301 posts

Posted 11 October 2017 - 03:48 PM

I'm afraid you simply didn't use version 7.5.0.0 when that feature was in there, so you have no personal reference to know why we say it doesn't work. 

 

If you want to uninstall the current version and download 7.5.0.0. to see why we say it doesn't work you can do so. You can keep it installed until you have all your places fixed and then have them changed on Ancestry. Update to the current version once that project is done. You can download the older version here - files.rootsmagic.com/RM7.5.0.0/RM7Setup.exe

 

As you use 7.5.0.0 with the place list keep in mind the program is not frozen it's simply processing everyone for the change list. Just let is sit a few minutes and it will complete. If you merge places expect the wait to be even longer.


Renee
RootsMagic

#12 pstaveley

pstaveley

    Member

  • Members
  • PipPip
  • 24 posts

Posted 12 October 2017 - 04:12 PM

Thanks I will try that.



#13 pstaveley

pstaveley

    Member

  • Members
  • PipPip
  • 24 posts

Posted 23 October 2017 - 04:58 PM

Is there any sort of date/time stamp for when the record of an individual is modified?

 

In a  future version could there be such a field and we have access to it? That way we could create a group for all individuals whose details have been modified or created in a time period of our choosing, such as in the last day. Then we could use that group to do a proper synchronise with ancestry.



#14 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2701 posts

Posted 23 October 2017 - 10:29 PM

Is there any sort of date/time stamp for when the record of an individual is modified?

 

In a  future version could there be such a field and we have access to it? That way we could create a group for all individuals whose details have been modified or created in a time period of our choosing, such as in the last day. Then we could use that group to do a proper synchronise with ancestry.

 

The requested date/time stamp exists. You can see it on the Edit Person screen. It's hidden in plain sight on the lower left hand corner of the screen.

 

You can make the date/time stamp into a column in People View, and you can sort the column ascending or descending.

 

You can print the date/time stamp as a column in Custom Reports, and you can sort the column ascending or descending.

 

You can search for the date/time stamp and color code based on it and make groups based on it. In the Searching or Marking dialog, it's called Date Last Edited.

 

That's the good news. The bad news is that the date/time stamp can be somewhat unreliable at times. It can sometimes be updated to today's date when in fact nothing for the individual has been changed. It can sometimes fail to be updated to today's date when in fact something has been changed.

 

The main problem with changing the date/time stamp when nothing has been changed is when you open a note and close it with Ok when nothing in the note has been changed. The design of RM suggests that if you haven't changed a note you should cancel out of it instead of Ok out of it. But I refuse ever to cancel out of a note for fear of losing changes. Until I switched to always exiting notes with Ok, I regularly lost changes to notes by exiting with cancel by accident.

 

I'm less clear about all the cases where changes are made without updating the date/time stamp. Certainly bulk changes such as making changes to places in the Place List or making changes with Search->Search and Replace do not update the date/time stamp. I would have to do a lot of experimenting to be sure, but I think that changes to sources and media do not update the date/time stamp. That's certainly true if you make the changes from Lists->Source List or Lists->Media Gallery and it's certainly true if you make media changes via any variation of the media tagging process. I'm less sure about making changes to sources or media directly from the Edit Person screen, but I think even there that source and media changes do not always update the date/time stamp.

 

Jerry



#15 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2701 posts

Posted 23 October 2017 - 10:38 PM

That way we could create a group for all individuals whose details have been modified or created in a time period of our choosing, such as in the last day. Then we could use that group to do a proper synchronise with ancestry.

 

I have not played with TreeShare quite enough to be 100% sure, but it seems to me that TreeShare itself already does a better job of keeping track of which individuals have been changed than does RM's basic date/time stamp. I'm not sure if TreeShare is 100% accurate in this regard, but it certainly seems better than RM's basic date/time stamp. One problem with TreeShare in this regard is that its ability to keep track of bulk changes to places was removed because such changes can quickly become too numerous to move from RM to ancestry in any practical way.

 

So I guess I'm a little curious about your thinking in regard to using a group to sync with ancestry. Which is to say, I think that TreeShare already does a better job of keeping track of changes than does the date/time stamp. That being said, I would still like to be able to limit TreeShare to a group for a totally different reason. Namely, I would simply like to upload a portion of my RM database to ancestry using TreeShare rather than uploading my entire RM database to ancestry using TreeShare.

 

Jerry



#16 pstaveley

pstaveley

    Member

  • Members
  • PipPip
  • 24 posts

Posted 25 October 2017 - 04:51 PM

All I want is a reliable way to ensure that if I do a bulk change to a place name that it flags all the affected individuals as changed in RM so that I can upload those changes to Ancestry using TreeShare.

 

Earlier in this thread it was confirmed to me that changes to place names do not flag as changed in TreeShare. If a bulk place name change changes a time stamp then I can at least use that as a group so avoiding the need to have to look through all 9,000+ individuals.

 

Generally I know when I did that bulk change but it is not easy to know which individuals were affected because the place dialog box is modal meaning that I cannot create a group before I do the change and it takes very long to keep closing the modal box, do a search, create a group and then do the place name change. Doing a location report is another option but that again takes some time to run and then to save as an external file (again that is a modal screen).



#17 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2701 posts

Posted 25 October 2017 - 07:37 PM

The "better job" that I was talking about for TreeShare was adversely affected by the change in TreeShare wherein it no longer makes note of bulk changes to places. But of course the Last Date Edited field has never taken bulk changes to places into account.

 

Jerry