* Viewing Gedcom with Android

[donone]

I have a few Android apps for gedcom etc. and notice that (for example Gedstar Pro) the events data and relations data per person is displayed out of sensible order and not the same order for each person.
I tracked this down to possibly (probably) due to the data being ordered by the date it was entered in FH. On viwing the Gedcom in an editor this seems? to be the case.
Is there a non manual way to re-order the Gedcom, say, in ahnentafel order and then changing the DATE of data entry to the same date for every entry (since I do not use that date)?
I assume I would have to move and re-name the @??@ links.
Any suggestions please?

[Jane]

Use the Reorder out of sequence data tool on the tools menu to re-order events and children into date order.

[donone]

Thank you Jane but I already tried that.
The data in Gedstar pro is shown in the following order...
Name, Note, Son, Birth, Baptism, Dau, Marriage, Dau, Dua, Death, Burial

and for another person...
Name, Note, Birth, Marriage, Dau, Dau, Son, Dau, Dau, Death

My concern is a son and a daughter in the first example appearing before the marriage; which did not occur.

I am trying to narrow down why this would occur and correct the ged.

[donone]

Sorry to have wasted your time Jane. I have just discovered an error by testing the gedcom file, but does not show up in FH views.

[EDIT] The error was caused by having a child with known name but with no known birth date. That obviously caused it to appear before marriage date. Not sure what else could have been done, but there we go.

[tatewise]

If you assume children are born after marriage of parents then set their 'unknown' birth date to After Date of Marriage.

You also might find the Export Gedcom File plugin useful to convert/remove FH custom features to produce a more compliant GEDCOM 5.5 format.

[jimlad68]

Some Genealogy programs give the option of a sort date (not Gedcom standard though), in my case I used them a lot in TMG but they do not export, and of course FH does not have sort dates, even with a Gedcom Extension. So I have started using ESTimated dates to give some semblance of chronology, but it is important to realise that on exporting/sharing some people might take them too literally. This is also helpful when trying to decide if someone "might" still be alive for export/privacy issues.

Not tried it yet, but there is Vivify (BIRTH YEAR ESTIMATOR) http://gigatrees.com/toolbox/vivify
ALSO mentined on FHUGKB http://www.fhug.org.uk/wiki/doku.php?id ... ythe_tools
I am sure there are others. I had started doing manual ESTimates, but you have prompted me to look at something like this that might save some time.

[tatewise]

There is the FH function =EstimatedBirthDate() which takes many factors into account using Facts from the Individual and their relatives to offer an earliest/middle/latest Date.

[jimlad68]

Yes I had looked at that after looking at the "estimated alive at" query but I got some strange results (many BC, 900 etc, possibly due to my using dates like 0150 in order to sort some of my "admin" facts) so played around with the generation parameter, but not much better. I found using the "Ancestor and Descendant" Diagram easier. As there is now much more data online since I entered these individuals originally it has also given me the impetus to look them up again, but it is so easy to get side tracked!

[Jane]

0150 in order to sort some of my "admin" facts

Why not simply use the Fact Time scale to move them to the top or bottom of the list.

If you really want to use sort dates rather than putting in an estimated date, you can always use a date phrase with as interpreted as value.

[tatewise]

But won't the function use the interpreted as date value just the same?

[donone]

Some interesting views have been expressed, my having presumed the thread as dead due to my response.
I shall try the Export Gedcom plugin and if that does not provide a solution I think having unknown dates calculated will, as suggested, be taken too literally because they are not recognisable.
I may try using one day after marriage as an instantly recognisable solution.

[jimlad68]

Thanks Jane; yes I did consider the fact time scale and it works very well within FH, but I wanted even more control. Also I'm not sure how it would import to other programs, I suspect that as long as it is in the right position in the Gedcom file it might be OK, but some sites/progs put "no date" facts at the beginning, some at the end. The date phrase looks interesting so I might check that out re exporting. Of course, if FH had a sort date (like TMG), that would not export either, so more and more my use of dates like 0150, 9950 etc look most flexible for my purposes.

If I wanted to progress my estimated dates with the function =EstimatedBirthDate(), I could easily test it on a copied Gedcom stripped of potentially offending data, after all, it would be a one off.

[tatewise]

Perhaps, to allow the EstimateDate functions to ignore "sort" dates, then a valid date range needs to be defined in FH.
Then dates like 0150 and 9950 would be ignored because the valid date range would be say 1000 to 2100.

[jimlad68]

Mike, I'm suspecting your

allow the EstimateDate functions to ignore "sort" dates, then a valid date range needs to be defined in FH

cannot be done at present. However, I did my test of using a copied Gedcom file, stripped of potentially offending date data, and this seemed to work much better.