* Importing from TMG - no sort dates in FH

[ColeValleyGirl]

Linda, re facilities in FH to reorder facts...

If you go to the Facts tab of the Property box and select a fact, there are two large arrows at the bottom of the facts list that allow you to reorder facts. Click the up or down arrow to move a fact through the list.

However, there are some constraints, which can result in one or both arrows being disabled for a particular fact.

1. You cannot move a fact outside its 'Normal Time Frame'. For example, you can't move a burial before a death, or a occupation after a death (makes sense to me).

2. If your fact has a date, you can't move it out of date order. (If one or more facts have the same date, you can change the order within that date, and this is the use I make of the facility most often).

3. If you have an undated fact, you can move it anywhere within its 'Normal Time Frame', except for some reason (which I don't understand and haven't investigated) you can't move it past a marriage. (My way around this is to create a dated fact that sits in the right section of the fact list and then remove the date and move it to where you want it, but no doubt others will have a better solution). This is useful, for example, to identify a 'lead occupation' -- one that is displayed in preference to others (otherwise you typically get the first occupation and 'At school' isn't that representative of most of my ancestors! If you move undated events like this, they stay put even if you reorded facts in date order.

So, not as totally flexible as Sort Dates, but workable for some purposes.

[ColeValleyGirl]

Mike,

I can't think of a way in which automatic generation of a sort date can work *and* put marriages in the correct place in a sequence, as the place in the sequence of a marriage (or other family event) will differ between the two individuals concerned.

I think we may have to fall back to using a field or a labelled private note for an optional sort date. (GedSite will take the actual date of a fact as the sort date of no sort date is specified, so the sort date can be made optional in FH).

We've eliminated Descriptor as an option, and I can't identify any other standard field associated with a fact that we could use instead without conflicting with either existing Wish List requests or the 'normal' use of these fields. In any case, using an 'obscure' field will make the entry of a sort date more complex than using a labelled note.

Your thoughts?

Helen

[tatewise]

Further to this discussion, automatically setting the 'Sort Date' on Gedcom export to GedSite is clearly useful, but if FH did offer a 'Sort Date' field similar to TMG, then you would have to enter a value into each such field where required, and that is essentially no different than tediously entering a labelled Note as I proposed earlier, and if FH introduced a 'Sort Date' field, then populating those fields would be similarly tedious.

However, overnight I have updated the Plugin to use better 'Sort Date' values.
Primarily it uses the Date of each Fact to set the 'Sort Date'.
If there are successive Facts with identical Dates or NO Date at all, then the 'Sort Date' is simply incremented by one day from the preceding Fact.
To cater for initial Facts with NO Date the 'Sort Date' is initialised to 1 Jan 1000.
With that strategy it should sort Family Facts (MARR, DIV) amongst Individual Facts much better.
But undated Facts may still be a problem in some circumstances, such as a Marriage with no Date, or Individual Facts with no Date that come after a Marriage Event.

Nevertheless, try the attached Export Gedcom File Plugin ZIP file Version 3.2.12 Date 08 Jul 2017. [Now Deleted]

[ColeValleyGirl]

Mike,

I've done some testing with a wholly fictious project and some very strangely documented individuals (Born-married-died, all no dates... and other perms and combs).

Marriages with no dates sort (as you indicated) in the wrong place -- and this is a very likely scenario ("I know they married; I just don't know when"). However, some will be happy to record an approximate marriage date of some kind, or a date range, based on the information they have about the couple, and if there's no sound information with which to estimate a marriage date, a 'Marriage Status' of <default> can be applied with a note to explain the reason, so I don't think this is a stopper.

I can't get an undated lifetime fact to 'stick' immediately after a dated marriage, so haven't been able to test that, but an undated death after a dated marriage works OK.

[tatewise]

That seems like the basis for a workable solution.
Now what about combining the two proposed methods?
For those 'exceptional' cases, such as an undated Marriage, add a labelled Note such as [[Sort Date: 1 Jan 1900]] and the Plugin will use that value as if it were a Fact Date purely to put the Fact in the correct order.
Only then will the Plugin use the automatic Sort Date strategy currently implemented.

[ColeValleyGirl]

Mike, I almost suggested that but didn't want to make more work.

It would also help with the occasions when, try as you might, you can't get an undated fact into the right sequence!

Helen

P.S. I have run some quick tests for witnesses to dated and undated events -- they seem OK as well.

[tatewise]

That is OK, try the attached Export Gedcom File Plugin ZIP file Version 3.2.13 Date 08 Jul 2017.

The Note label is Sort Date: followed by any reasonable simple date, and may be enclosed in [[privacy brackets]].
e.g.
[[ Sort Date: August 1900 ]]

[ Attachment deleted as now published in Plugin Store in Feb 2018. ]

[ColeValleyGirl]

That works, Mike.

I think now we've got a solution that can be (largely) automated for most facts, with some data entry needed for edge cases; plus an option for people who want to input sort dates manually, as they have been accustomed to in (e.g.) TMG.

It doesn't address the problem of people who had a lot of sort dates in TMG and lose them when moving to FH; it would be nice to address this to get a complete solution, as I suspect it's stopping a number of people making the leap.

[Linda Reinfeld]

Helen and Mike -

Yes, I did know about manually moving the events around to create the correct order. However, I have over 21,000 sort-date only tags in TMG. I can work that down to about 15,000 with an automatic date put in for tags after the death date, but it does present too big a hurdle for the rest. I shall have to spend some time rethinking this -

Thanks for the ideas & the changes to the plug-in.

Linda

[tatewise]

Linda, have you reported the problem to Calico Pie? See how_to:about#problem_reporting|> Problem Reporting.

Even if FH only imported the _SDATE sort date tag from TMG, then a Plugin could shuffle the Facts into the desired order.

[jmurphy]

John Cardinal suggested ensuring that everything had a date (which I won't do for events I don't have evidence of date for), and modifying dates to force the correct order (ditto I won't do this).

I hate doing that, too. If I'm forced to do it, I mark the date as estimated and create a source note that the date was inferred.

[E Wilcock]

As yet I have only two of my personal family Projects from TMG imported into fh. Plus one work project. But I am a user of both fh and gedsite.

I use both without much computer know how and I am posting here so Mike and others know that I have not understood the technical discussion in this thread.

Would it be possible please (eventually) to have a resume giving guidance to ex TMG users like myself on what we should do? Either on import, after import and when exporting via the plug in to Gedsite.

My only gedsite tree so far (from fh of one these imported TMG projects) is a basic website giving B M D and Occupation. The Occupation is an undated field designed for website purpose, an individual field in fh) and appears to come first. Occupation birth marriage and death.

Since the site looked as I expected, it did not occur to me tjhat undated fields might be a problem. Is there anything I ought to be checking for on the site?

Pace John Cardinal, I do not intend to give dates to every fact. But where I have no source for e.g. a birth I have already put in ca. 1856 or abt. I suspect I did that to establish birth order in Generations software I used prior to TMG and which had no sort dates.

I have several historical Place study projects in fh amounting to several thousand names. For these I used the options available in fh and paid little attention to what I might now be missing.

But it has unsettled me to discover bit by bit complications or losses that I was not aware of when I made the switch. And may be we need a special section for these on the FAQ web page?

[E Wilcock]

Linda - Please do report this to Calico Pie. If RM can import the sort date field, fh should do the same.

[ColeValleyGirl]

In a nutshell, without technical talk:

Mike has modified his Export GedCom Plugin to automatically add Sort Dates that GedSite can use to get 'tags' in the order you have them in FH (by moving them up and down in the facts list as I've described in an earlier post in this thread). For those facts you can't move into the correct sequence (for whatever reason) or if you prefer to define an explicit Sort Date for a fact, you can add this as a 'labelled note' for the fact and the Export Gedcom Plugin will include that Sort Date for GedSite to use.

I would wait for Mike to make an 'official' version of his plugin available, as initialising the development version is a little tricky, but I've tested it (quite) extensively and am very happy with the results, especially where I want to force events on the same day into a particular order (Occupation-Residence-Marriage, or Occupation-Residence-Death, for example) or move a 'preferred occupation' to the top of a section in FH. It may be coincidence that your preferred occupation for website is currently coming first, so if things change, you might find a sort date ensure the output you want; it really depends on how Gedsite handles undated tags and I'm not certain about that. They will definitely not be lost, but they might not show up where you expect.

There is not yet a way to import Sort Dates from TMG, which needs to be taken up with Calico Pie. (If this was provided, people newly migrating to FH would not need to do any manual rearrangement of facts or input of Sort Date notes; this doesn't affect me, as I've always used FH but I would like to see newcomers from TMG have the best possible migration experience).

Helen

[E Wilcock]

Thank you very much Cole Valley Girl.
I now understand too (from your explanation) why I too may get the three facts on the same date - arising from the one source, a UK certificate.
This may happen also with witnessed events, because German records (handwritten images newly on line) sometimes give the age, occupation and residence info for witnesses on the marriage registration.

I do not understand what is meant by a labelled note. But I have been postponing any total export of a fh Project data to Gedsite until the need arises. So I will wait for you and Mike and Calico Pie.

[ColeValleyGirl]

A 'Labelled Note' is simply a note, or part of a note (associated with a fact) that contains a specific starting string, so that the plugin can recognise it.

For example: [[ Sort Date: August 1900 ]]

[[ and ]] tells reports etc. not to include the note (privacy markers).

Sort Date tells the plugin to use the following simple date as a sort date.

[Linda Reinfeld]

I reported this to Calico Pie - no sort dates. The number is #206208.

Yes, it's true that RootsMagic imports sort dates, which makes it attractive for TMG users...

Thanks -

Linda Reinfeld

[ColeValleyGirl]

Mike,

In some circumstances, the plugin doesn't generate sort dates that align with what the user is expecting, which is entirely down to the different FH facilities for reordering facts; might it be worth documenting?

If you move facts around on the All Tab in the property box (so for example to put a census before birth), the Facts tab will still show them in a 'sensible' order; however, the export plugin generates sort dates according to the position on the All tab (not much else it can do, obviously) so the results when it gets into GedSite dn't match what's on the Facts tab.

Suggested 'resolution' : advise people who want to use the Sort Dates to only reorder things in the Facts Tab, and use the Labelled Notes e.g. [[ Sort Date: August 1900 ]] if they want something out of the ordinary.

[tatewise]

Helen, I will add some advice along those lines.
I'm surprised FH allows those adjustments on All tab, and would have expected it to enforce the same rules as on Facts tab.

Is an alternative to use Tools > Re-order Out-of-Sequence Data and expect undated Facts to retain their position within their Normal Time Frame?

[ColeValleyGirl]

Mike, if you do that you can end up with events on the same date 'randomly' ordered within the date. So if you always want to have Residence-Occupation-Event you have to move them manually.

[dewilkinson]

I just noticed this and am probably a bit late. But for what it is worth I migrated from TMG nearly a year ago and thought I would miss Sort Dates. However, I haven't, primarily because each Fact has a Time Frame, for example Burial being post death, so it always appears after death even if there is no date. You could of course put after dd/mm/yyyy, that way you are not estimating a date. For facts that occur during a life when I do not have a date I use between 1810 and 1815 for example.

The only Time Frame that annoys me is Occupation, I would rather it appeared first but its Time Frame is Life and cannot be changed. The reason for this being I use Occupation as a general description (e.g he was a butcher then a farmer from 1895) rather recording an Occupation Fact for each event such as a Census although I do include it in the Note narrative for such Facts.

[tatewise]

You can create a clone of the standard Occupation Attribute with an adjustable Normal Time Frame.

First use Tools > Fact Types > Fact Sets > Clone to create a copy of the Standard set and lets say it is called Clone.

Now in the main Fact Types dialogue tick Show Hidden and every Fact will be listed twice, once in the Standard set, and once in the Clone set but <eclipsed>.

Use Fact Sets > Move Up to position Clone set above Standard set and then the Standard facts are <eclipsed>.

Assuming you only want to adjust the Occupation Attribute then Delete all the others from the Clone set.
In Fact Set at top select Clone and you can select all those Facts and Delete them all in bulk in one go.
(Don't worry about the risk of deleting the Standard Facts because that is not allowed.)

Now only the Occupation Attribute in the Clone set <eclipses> the Standard set equivalent.
Finally, Edit the Occupation Attribute in the Clone set to adjust its Normal Time Frame.

Then you can place your Occupation facts wherever you like but they still use the standard Gedcom OCCU tag.

BTW: The same technique allows other Cloned sets for other purposes such as foreign languages, and simply using the Move Up/Down brings different sets into play.

[dewilkinson]

Mike,

Thank you, worked perfectly. With out some help the route needed to achieve something like this as a bit difficult to fathom out on your own.

Many thanks

[tatewise]

Agreed. It is a fairly advanced form of customisation, but that is what the FHUG is here for.

[tatewise]

Helen, following on from your earlier comments, I have added Plugin Help & Advice for
plugins:help:export_gedcom_file:gst_gedsite#sort_date_sdate|> Export Gedcom File ~ (GST) GedSite > ★ Sort Date (_SDATE)
and
plugins:help:export_gedcom_file:rmt_roots_magic_tree#sort_date_sdate|> Export Gedcom File ~ (RMT) Roots Magic Tree > ★ Sort Date (_SDATE)
referring to plugins:help:export_gedcom_file:sort_date_details|> Export Gedcom File ~ Sort Date Details.

Does that advice include enough details along the lines you mentioned?

BTW: A labelled Note such as [[ Sort Date: August 1900 ]] is currently only effective if the preceding fact has a Sort Date earlier than that date. i.e. The Plugin does not simply copy the date given into the _SDATE tag. But maybe it should, and then such facts may appear in the target product in a different order than in FH.