Question FAM:MARC doesn't appear for visitors (wt 2.1.20 PHP 8.3.9)

Bonjour, Je ne comprends pas pourquoi certains mariages (seuls les mariages, les autres événements apparaissent) ne sont pas affichés pour les visiteurs mais apparaissent comme membre.
Il n’existe cependant pas de règles spécifiques liées à ces personnes ou familles.
2 exemples apparaissent et n'apparaissent pas dans les fichiers.

autre problème, les événements n'apparaissent pas dans leur ordre chronologique.

Merci pour votre aide.

I see a marriage in 1923. A child could have been born up to ca 1943 which now is like 80 years old.

You should be aware that with default privacy settings in webtrees a family is considered private as long as one of the members is private.

The reasoning behind this is that a source on the family (eg most recent census record) may contain data that should be protected, eg full names and date of birth. This can be used for identity fraud.

So one missing death event of a child (or just a long living child) can cause that visitors won't see marriages, spouses, etc.

Merci beaucoup Bertkoor.

Et concernant l'ordre chronologique des évènements avez vous une idée du problème ?

Sure. There is no single correct way to compare a range of dates, so the end date of the range is taken in webtrees.

je comprend mais le recrutement militaire en 1905 apparait tout en bas alors que le recensement de 1931 apparait tout en haut.

The 1931 census looks misplaced.
Sorry, I cannot explain that.

if we could see the entered data, we would find an answer.

The raw gedcom export is attached in the first post. I can even view it on my phone.

merci pour la prise en compte de mon problème. Pour plus de visibilité, je n'ai laissé que les deux fichiers en rapport avec ce problème

sorry, i did not see that you gave a part of a gedcom file.

But it would be much more easyier for us, to have an export, that can be imported/merged into an existing one, or completely used.

So I entered the events and their dates into my test database. See here  , what now seems to be correct, after I inserted some more events by help of the normal GUI, whereas I inserted the other events by copy and paste raw gedcom from the original in a nearly arbitrary sort order.
You can see in the screenshot, that the census dates are handled for their own and shown direct after birth.
I think Greg can explain, why that is handled that way.

 

I send you the gedcom file by email.
Regards
Brozer

I too have instances where the date order appears random, and certainly not in the correct sequence.

I suspect it has something to do with the fact there are date ranges in other events, ie occupation or residence. Using Abt. Also seems to sometimes confuse the software.

MartinM wrote:

I too have instances where the date order appears random, and certainly not in the correct sequence.

I suspect it has something to do with the fact there are date ranges in other events, ie occupation or residence. Using Abt. Also seems to sometimes confuse the software.
 

I think it does relate to how the date is added. Certainly date ranges bet - from to have an impact. Also using just a year.
It seems date ranges work on the end date rather than the beginning date. There is also something that alters when using residence and occupation rather than Census and Occupation.. Full dates seem to make an bigger impact (sort better) than ABT or year only dates.. Not sure it is a software issue, but could be.. Hopefully Greg will chime in with his comments..

Franz Frese wrote:

sorry, i did not see that you gave a part of a gedcom file.

But it would be much more easyier for us, to have an export, that can be imported/merged into an existing one, or completely used.

So I entered the events and their dates into my test database. See here  , what now seems to be correct, after I inserted some more events by help of the normal GUI, whereas I inserted the other events by copy and paste raw gedcom from the original in a nearly arbitrary sort order.
You can see in the screenshot, that the census dates are handled for their own and shown direct after birth.
I think Greg can explain, why that is handled that way.

 

@Franz,
If you look closely at your attachment, every pair of adjacent items is "correctly" sorted.

1. Residence (line 4) continues after the censuses in lines 1-3.
2. Occupation (line 5) starts after Residence
3. Military (line 6) is inside the range for Occupation
4. Everything beyond Military is in chronological order

The evidence suggests two things about the sorting method.

First, it is a "stable" sort that preserves the original order of items that compare equal. That seems important, for there are many situations in GEDCOM when multiple versions of an object are allowed (name, birth date, etc) and the FIRST ONE is preferred.

Second, the method used for date comparison can't handle the variety of date formats allowed in GEDCOM. In particular, all practical sorting algorithms assume that the pairwise comparison operator "<" satisfies the transitive property: "A<B, B<C implies A<C". Otherwise, the sort can't make any forward progress because it must continue to compare everything to everything else at each step. 

I honestly don't think that there exists a pairwise comparison operator that satisfies the transitive property and can handle the full generality of GEDCOM dates because the answers "A<B" and "B<C" could be determined by different parts of the date expression than the ones needed to answer "A<C".

Anyway, when I run into such garbled sorting orders, I use the "edit the raw GEDCOM" form to reorder the blocks the way I want them. (Remember that if this is a stable sort, then it will preserve my decisions.) It looks like moving "Residence" and "occupation" below "Marriage" would do the trick.

Its about the 1931 census.

Have a look at 
dfrese.de/webtrees/tree/ahnen/individual...avier-Amedee-McMyers
And the comment for1891

Les dates des évènements de l'individu et de sa famille devraient être lues, puis comparées, puis affichées quelque soit l'ordre dans lequel elles sont inscrites dans le gedcom.

Pour une plage de dates, la date de début doit être comparée aux autres.
Pour les dates sans précision jour mois, il faut considérer qu'il s'agit du 1 (1906 = 01/01/1906).
Enfin pour des dates égales, la naissance devrait apparaitre en premier puis le baptême, enfin le décès puis la sépulture.

J'ai ajouté en pièce jointe comment cet individu est traité par heredis qui s'affiche correctement.

What I found in webtrees code is that all events are gathered: from the individual, from his families, and from the relatives.

This big list is split in two lists:
* events with a date (with year after a minimum and before maximum of Julian dates)
* events without a date

First the events with date are sorted on their date. A range takes its start date. Only a year is interpreted as 01 JAN, only a month as day 01. When dates are equal, events are compared by type.

Then events without a date are taken and sorted on their type: first birth & baptism, death and buriel come last.

In short, I fail to see why census is not sorted as expected. Must be something unexpected somewhere.

I'll add links to the actual code tomorrow (when not om my phone) and perhaps create an issue on github.

> In particular, all practical sorting algorithms assume that the pairwise comparison operator "<" satisfies the transitive property: "A<B, B<C implies A<C"

This is a good explanation of the issue.

When we have overlapping dates, we treat them as equal. Events with "equal" dates are sorted by an "event order". i.e. BIRT comes before BAPM, DEAT comes before BURI.

Events with long date ranges cause the issue, as they overlap many other dates, and are thus considered equal with all of them.

It might be worth investigating whether we could have different logic for facts/events. i.e. for events, keep the same logic, but for facts use only the start date.

@Greg: the census entries are all dated with a simple year, but yet the sorting is odd. Why is this census put before the affectation and marriage?



Even if a simple year is interpreted as "BET 01 JAN AND 31 DEC", that is not a very long range. It does not explain why these are always put directly after the birth, as confirmed by Franz, and I don't see it happening in the code.

This is where that's happening, right?
github.com/fisharebest/webtrees/blob/fab...tsTabModule.php#L147
github.com/fisharebest/webtrees/blob/fab...3c/app/Fact.php#L707

Census is not always sorted wrong.
I deleted some events. (Cant remember the last deleted)
Now sorting of cesus is ok.