* Importing from TMG - no sort dates in FH

[Linda Reinfeld]

I am trying to import a variety of 'tags' from TMG to FH. Unfortunately FH doesn't have sort dates. This is causing a tremendous problem for me. I understand that in FH you can identify the approximate position of an event or attribute - such as a burial event after a death (none of my burial events have a date). I am using GedSite to build my web site. The 'approximate' position of the events does not work in exporting a gedcom file. The 'tags' I have in TMG that have only sort dates that all come after death are: cause death, burial, obit, will, inventory, number of descendants.

I have described only the 'tags' that occur after death. I have many other tags with only sort dates that should sort in the proper order within the body of the text, but do not.

How can this situation be helped?

Linda Reinfeld

[ColeValleyGirl]

The problem is compounded by the fact that Gedsite doesn't look at the order of the 'tags' (Facts) in the GEdcom it loads, so any manual sorting of events in FH is lost, and it's random which of 3 events happening on the same date shows first (I like to put occupation before residence before marriage, for the facts derived from a marriage certificate, but in GedSite peope get married and then live at the address, for example, even though it's technically the address just before marriage, and the certificate doesn't prove they lived there afterwards.) Date ranges are unsatisfactory as well.

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).

The only partial way I found around this was to allocate tags in GedSite to different groups (Life and After Death) and show the tag sets in that order. I'd love to find a better solution). At least thenI didnt have dead people living somewhere and having an occupation!

[tatewise]

To put this in perspective, the primary reason FH does not have 'Sort Dates' is that they are not a standard Gedcom feature.

Linda, did you export TMG to GedSite and were the 'Sort Dates' honoured by GedSite then?

I am wondering if something can be done with the Export Gedcom File Plugin to improve matters.
Off the top of my head I have a few ideas:

1. Use the Tools > Fact Types > Normal Time Frame to synthesise 'Sort Dates' relative to other Facts that do have dates.
   i.e. If a Burial Event has no Date, then in the exported Gedcom give it a Date just after the Death Event Date.
2. Alternatively, another FH field such as a labelled Note could hold the 'Sort Dates' in standard Gedcom Date format.
   To hide that labelled Note 'Sort Date' in FH Reports it can be enclosed in [[privacy]] brackets.
3. The 'Sort Dates' could be added a standard Fact Dates in the exported Gedcom, perhaps with Calculated qualifier.
4. Alternatively, the TMG format for Gedcom 'Sort Dates' could be employed and persuade GedSite to recognise them.

[ColeValleyGirl]

Mike, Gedsite handles TMG Sort dates. There might be some interest in the export plugin solution, as a few FH users (mostly migrants from TMG) have asked about the topic on the GedSite forum...

[tatewise]

I have an expired trial version of TMG so cannot experiment as the File > Export command is greyed out.
What is the Gedcom tag structure for the Sort Date?
I imagine it will something like 2 _SORT or 2 _DATE followed by a standard Gedcom Date.

Would adding a labelled Note such as Sort Date: 1 Jan 1900 be the desired way of setting the Sort Date per Fact?

[jbtapscott]

In the Gedsite Help for Dates it states: ".....RootsMagic and The Master Genealogist use the GEDCOM tag "_SDATE" to specify the sort date, and that GEDCOM tag is the default used by GedSite. GedSite can be configured to accept a different GEDCOM tag.....". Hope this helps

[ColeValleyGirl]

Hopefully somebody with TMG will answer your questions, Mike. However, I've asked John Cardinal what GedSite would expect.

[tatewise]

So it looks like the Sort Date of 1 JAN 1900 for say a Burial would look like:
1 BURI
2 _SDATE 1 JAN 1900

So now you need to decide where to put the Sort Date in the Fact fields.

[ColeValleyGirl]

Ideally, the sort date would be populated from the 'FH' position (so standard FH mechanisms would be used to order facts?)

Alternatively would Descriptor be suitable if manual entry is required? Not sure if this exists for every fact though.

If something is wanted for which data entry is easy (from the Facts tab not the All tab), then a labelled note is probably simplest (although a need for adherence to a strict format could make it error prone).

[ColeValleyGirl]

@jbtapscott "GedSite can be configured to accept a different GEDCOM tag....."-- Any idea how? I can't find an option for this.

More detail on the RootMagic sort dates as used by GedSite:

Sort Dates
GedSite supports RootsMagic "dash numbers" in sort dates such as the "-1" in the date 12 JUN 1900-1. 12 JUN 1900-1 will sort before 12 JUN 1900-2 which will sort before 12 JUN 1900-3, etc.
GedSite supports dash numbers only as follows:
Dash numbers must use a dash character ("-") or an EN-DASH character ("–").
Dash numbers are supported in sort dates only.
Dash numbers are supported in unmodified sort dates only, i.e., 12 JUN 1900-1 is OK, BEF 12 JUN 1900-1 is not.
Dash numbers must be between 1 and 100.
Dash numbers only work with dates whose year is greater than 100.
When the dates are the same, a sort date with a dash number sorts before a sort date without a dash number.

[tatewise]

The Type Descriptor does exist for every Standard Event & Attribute, but NOT Custom Facts as they use it for the Name of the Custom Fact.
Using it for 'Sort Date' would also compromise the Wish List Ref 559 Fact Descriptor for Civil Union, two Place Travel, Preferred Occupation, etc..

Populating the 'Sort Date' from the Fact position in FH Gedcom also has complications.
Does it take the Date from the preceding or the succeeding Facts?
What if there is no such Date recorded?
There are a lot of Date formats: Simple, Qualified (ABT, CAL, EST), Range, Period, etc.
How must those formats be employed in the 'Sort Date'?
Especially if several adjacent Facts need a 'Sort Date' and thus need the 'dash numbers' that are only valid on Simple Dates.
That means there must be some rules for converting every Date format to a suitable Simple Date.

Also, not everyone might want 'Sort Dates', so that would need to be a tick option, especially as John Cardinal strongly prefers unmodified Gedcom by default (so direct FH Gedcom behaves the same as Plugin exported Gedcom). Thus having an explicit labelled Note is much clearer. Getting the Date format correct is not such a problem as the Plugin can use the SetValueAsText(...) function that tolerates a wide variety of Date formats.

[jbtapscott]

Helen - I've spent some time this morning and I also cannot see how it is configured!!. Will keep looking but hopefully John C will get back to you later today in answer to your question.

[ColeValleyGirl]

Sounds like Descriptor won't work then, and a labelled note might be the way forward.

Re automatic population, I understand the difficulties, but does not supporting this either mean every fact for a person will have to have a sort date, or none of them?

I was thinking along the lines:

• If the fact has a 'simple date', use that as the sort date.

• If one or more sequential facts don't have any date, or have 'complex dates', use the nearest succeeding 'simple date' and add 'dash numbers' based on the FH sequence (sort dates with a dash number sort before sort dates without a dash number). If there isn't a succeeding fact with a 'simple date', use the last preceding 'simple date' and add 'dash numbers' to that until you hit a simple date again.

• If multiple facts have the same 'simple date', use that with 'dash numbers' based on the 'FH sequence' starting after the last dash-number (if applicable) on preding fact sthat have that sort date

• If there are no facts with 'simple dates' add a standard 'sort date' and 'dash number' starring from 1 from the beginning of the fact list. If you end up with a dash-number of 100 and still have facts to go, increment the date and start again.

• If a fact has an explicit sort date, use that instead of the 'calculated sort date'

No doubt there are holes in this, and programming it wouldn't be simple.

[ColeValleyGirl]

A brute force approach would be to generate sort dates for every fact!

[tatewise]

I can certainly see the attraction of automatic 'Sort Dates' and you have highlighted some cases I had not thought about.
SNAP!
On reflection, since Facts with identical Dates do not retain their order in GedSite, every Fact needs a 'Sort Date'.
Assuming the 'Sort Date' does not need to be displayed in GedSite, that 'Sort Date' can take any arbitrary value.
So could the Plugin simply use your last suggestion everywhere unconditionally?
i.e.
Use any arbitrary date such as 1 JAN 1900, or maybe even just 1900, and add a 'dash number' from -1 to -100 to every Fact, and then move on to the next arbitrary date such as 2 JAN 1900 or 1901 and repeat.
That would be really easy to program.

[ColeValleyGirl]

I'll double check with John Cardinal, but I'm pretty sure the sort dates aren't displayed. Watch this space.

[ColeValleyGirl]

Ideally, the solution will care for sort dates that come over from e.g. TMG, so that needs a bit of thought.

[tatewise]

As far as I can tell the _SDATE tags do NOT import into FH via the direct import.

Also if the 'Sort Date' tag can be configured in GedSite then it does not matter.

[ColeValleyGirl]

Mike,

John says:

1 – If Mike adds a sort date to the GEDCOM file, he should use "_SDATE". GedSite can be configured (by me) to accept some other tag, but the convention followed by other programs is to use _SDATE and there is no reason to use a different value.

2 – The _SDATE value should contain a date in standard GEDCOM format

3 – The sort date determines the sort sequence when GedSite is sorting by date. GedSite does not display the sort date. It is possible to show it, but you'd have to go out of your way to do so.

4 – You described a suffix that would act as a sequence number. That is not part of a standard GEDCOM date and GedSite won't accept it without some customization. [...snip...] I can configure GedSite to apply the same rules to FH files, but that doesn't make sense to me. If Mike is going to programmatically assign sort dates based on an arbitrary start date, he should just increase the date by one day for each tag. That way, he doesn't have to bother with keeping track of a separate sequence number, doesn't have to roll over when it reaches 100, etc. Increasing the sort date by one day for each tag doesn't require any changes in GedSite, and it's easier to implement on his side.

So I think we have a way forward?

Helen

[tatewise]

OK, that sounds promising.
I've chosen an arbitrary 'Sort Date' of simply a year starting at 1000 per record and incrementing by 1 year for each Fact.
That is much easier than stepping through full day/month/year dates.

Note that Individual Facts (BIRT, OCC, DEAT, etc) will have 'Sort Dates' starting from 1000.
Also that Family Facts (MARR, DIV, etc) will have 'Sort Dates' also starting from 1000.
So not sure how that will work out.

Nevertheless, try the attached Export Gedcom File Plugin ZIP file Version 3.2.11 Date 07 Jul 2017. [Now Deleted]
(Too big for FHUG Attachments so It will need to be Extracted before loading into FH.)

Use the (+) Full Data mode in conjunction with (GST) GedSite GEDCOM Export mode.

[ColeValleyGirl]

Is there an option I need to tick to turn it on? I've run it and I'm not seeing any _SDATE tags in the output.

You might also want to look at the version number -- shouldn't this be a development of 3.3?

[tatewise]

No, this is still a development of Version 3.2 as V3.3 has not been published yet.

On the Other Options tab try clicking on Reset these GST+ Options button bottom right.

(If that does not work, try the same on the Extra Options tab.)

That will be fixed in the Plugin Store published version.

[ColeValleyGirl]

That seems to work, although I had to completely reset my options and recreate them.

However, family facts (as I think you suspected) sort in the wrong order -- they float towards the top.

Second think required... Will sleep on it.

[Linda Reinfeld]

Thanks for the discussion on this - I have come in late - I thought I would receive an email when someone replied to my topic....
-
The ideas are interesting - and sort dates would apply also to FH users that use GedSite (something I highly recommend) other than those importing from TMG. Adding an arbitrary sort date in the order the events occurs in FH wouldn't help me because the events do not occur in the correct order in FH. As you pointed out the sort date doesn't import from TMG into FH. I know you can identify events relative to various dates, but the ranges are very large. I have lots of 'life' events and attributes, some of which don't matter where they come, but many of which do. I can have an education tag that just identifies a high school graduate (in TMG I have a sort date). To assign a life date to this event could put it anywhere. And a residence tag that has no date - assigning a post-marriage would be difficult if there were 2 marriages - to show only a couple of examples.

So for me things aren't great in FH due to no sort dates, and they are really not great in GedSite. Of course the best would be to change the direct import and put the sort date somewhere in FH so it could then be accessed in the Gedcom to GedSite.

Linda

Thanks for all the thoughts

[tatewise]

Linda, maybe you do not realise that there are methods in FH to organise the order of Facts manually where necessary.
I suspect that is what Helen uses and leave her to explain the details.

But certainly a 'Sort Date' feature in FH would be useful.

BTW: You will get an Email if you tick Notify me when a reply is posted in the Options below the text message box.