[Solved in 5.3] Adopted / Foster / Step child

[kintree]

Huub

I find that a non-biological child can be mistakenly shown by HuMo-gen on the DNA chart of adoptive/foster/step parents.

I am working on a test to prevent this - it's quite easy with a GEDCOM from FTM, because a child's relationship (Natural/Adopted/Step/Foster/Guardian) to each parent is recorded:
0 @Fnnn@ FAM
1 CHIL
2 _FREL [relationship to HUSB (parent/guardian, not necessarily male)]
2 _MREL [relationship to WIFE (parent/guardian, not necessarily female)]

While studying this problem, I am also studying HuMo-gen's code dealing with Aldfaer's use of PEDI:
0 @Innn@ INDI
1 FAMC
2 PEDI [values: adopted, steph, legal, foster]

It seems that the INDI.FAMC.PEDI method can only record a relationship with BOTH parents.

Can you please tell me what Aldfaer mean by 'legal' ? (I understand 'adopted', 'steph' and 'foster' OK)

Thanks

[Huub]

I don't use the Aldfaer program, I think "legal" is a legitimate child. Eeh, I don't know why this is used...

It seems that the INDI.FAMC.PEDI method can only record a relationship with BOTH parents.

I think gedcom isn't a very good protocol, it's more a guideline. Adoption is one of the many problems in gedcom...

These codes were allready prepared in the HuMo-gen gedcom read script (admin/include/gedcom_cls.php):
2 _FREL [relationship to HUSB (parent/guardian, not necessarily male)]
2 _MREL [relationship to WIFE (parent/guardian, not necessarily female)]
But it wasn't finished yet...
Also see topic: http://www.humo-gen.com/genforum/viewto ... =15&t=1486

[kintree]

Huub

Yes, I saw your commented-out code for _FREL/_MREL in gedcom_cls.php. I don't think it will quite do the job: it is vital to translate from GEDCOM all the information which is there - GEDCOM is a pretty good way of transmitting child-parent relationships, provided that FAM.CHILD._FREL is used as well as (or instead of) INDI.FAMC.PEDI. Ideally there should be date information too: FAM.CHILD._FREL.DATE would be a suitable GEDCOM hierarchy, so perhaps we should program for it.

How I have used _FREL/_MREL
To be consistent with HuMo-gen's conversion of INDI.FAMC.PEDI,
event_gedcom carries any text on the same line as _FREL/_MREL [eg Adopted, Step, Foster]
event_event carries the 'adopting' family ID [Fnn]
event_connect_id carries the 'adopted' child's ID [Inn]
One more piece of information is vital:
event_event_extra carries the 'adopting' parent ID [Inn]
[if you have reserved event_event_extra for some other conflicting purpose, it may be necessary to introduce another column to humo_events]

As to Aldfaer's 'legal' type: legitimacy is certainly a fascinating subject which has over the years made plenty of money for lawyers. But as it only implies a biological relationship, it isn't of great use to a DNA chart! Any condition devised for DNA-chart purposes will have to ignore the 'legal' type.

[kintree]

Huub

While sorting out adopted/foster/step etc (more or less complete now, I have got them off the DNA charts), I found a suspicious line of code which I believe was causing an infinite loop with resulting memory-crash.

In family.php at line 1650 is the line:

Code: Select all

$genarray[$place]["fams"]=$childDb->pers_famc;

I have replaced $childDb->pers_famc with the empty string, and the problem has gone away.

[Huub]

Kintree,

I checked the line, I didn't wrote that part of the script, but it looks like the code isn't in use at the moment.
The graphical descendant chart is generated in report_descendant.php, and the code to use variable $genarray[$place]["fams"] is disabled.

For the next version I will disable this line, thanks for checking the code!

[kintree]

Huub

While on the subject of faulty code:

family.php Line 634:
I'm pretty certain that for
$descendant_main_person[2]=0;
the intended code was probably
$descendant_main_person2[]=0;

Better choice of variable-names might have avoided the confusion.

family.php Line 685:
I'm completely certain that
$genarray[$arraynr]["nrc"]==0;
should be
$genarray[$arraynr]["nrc"]=0;

[kintree]

Huub

The memory-grab problem I reported was NOT due to the line I identified - it was something completely different (I had mis-coded a variable-name). It seems that family.php line 1650 may be deliberately inserting a dummy non-empty value, perhaps to avoid failing some test elsewhere. I have now made the dummy value more explicit: 'F000', so that it can be easily identified if it causes problems!

[Huub]

Kintree,

Thanks for reporting the bugs! I have changed the lines.