I added immigration and emigration fields, and that was ok as relatively few individuals were impacted. I’m assuming we won’t be able to hack the Ancestry API to build our own automated updater (they almost certainly license access, otherwise somebody would have done it by now). Perhaps more importantly, if somebody is already using the existing manual options to sync, any new tool would have to export the same fields to keep everything in sync. It’s always possible to have two uploads, a simple synced one for hints and a more complete one with hints disabled that is simply copy updated, but that’s a bit messy. Users may want a more detailed tree uploaded for reasons other than hint generation. I'm also considering whether including address fields (building, street) is necessary.Ĭouple of other thoughts around which fields are exported from FH. For example, you initially have a Q date for BIRT which you got from the GRO index, which you later update when you look at other sources, like the Birth Certificate or Death Certificate or. That should lessen the number of updates because we generally update events like BIRT and DEAT when we get more precise information, but the year often stays the same. In addition, Ancestry uses only years in the search criteria, so I don't see why we would want to export a full date. I believe that Lived in is generated from RESI tags, but I'm not sure. The current search window allows specifying: I'm currently trying to understand which tags are taken into account when Ancestry generates the search criteria for Search on Ancestry. As I see it, we should be exporting only the information which Ancestry will use in looking for hints and generating searches. To that end, I believe that we should be looking at simplifying the information that we pass to RM as much as possible. It's very preliminary at the moment, but if past experience is any guide, I expect that it will suddenly come together (also, probably in the middle of the night). Last night, as I was drowsing (half awake) in bed, I started thinking about a possible algorithm to handle updates/deletions of facts. Ideally, I would like to develop a process which is automated as much as possible, using plugins on the FH side and Auto Merge on the RM side. That's possible, but requires learning a bit of new technology and a clear head. Unless Calico Pie releases an update which uses the version of luasql which works in lua 5.3, I'll need to set it up manually. At the moment, we can only play with this in FH6, but theoretically it is possible to get it working in FH7. The more I think about it, I believe that directly accessing the RM database should definitely be in our tool kit.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |