Ockert Almero Oosthuizen

about 1854 – 15 July 1937 · Oosthuizen line

Descends from the root couple, 2 generations up

Names

Given: Ockert Almero
Surname: Oosthuizen

The formal baptismal name and the name a person was actually called are both kept, and neither is derived from the other. Spelling drift between records is evidence, not noise.

Immediate family

Father: Jacobus Daniel Johannes Oosthuizen
Mother: Sophia Johanna Mocke
Brothers and sisters: 1844Nicolaas Frederik Hitge

1846Aletta Catharina Maria Helena Hitge

1848Adriana Cecilia Oosthuizen

1850Sophia Johanna Oosthuizen

1852Cornelia Francina Magdalena Elizabeth Oosthuizen (infant)

1852Fredrica Johanna Oosthuizen

1856Frederik Simon Oosthuizen

1858Jacobus Johannes Oosthuizen

1860Margaretha Appollonia Oosthuizen

1863John Peter Oosthuizen

1867Pieter Marincowitz Oosthuysen

A life in the record

about 1854 born Born
15 July 1937 died Died

Others of the same name

Afrikaans naming repeats hard, and the Cape Dutch naming pattern reuses a name on purpose, a child who died young has the name given again to a later sibling. These are different people. Never match on a name alone.

What we don't know

No dated record ties this person to a specific piece of ground.
7 other people in this model carry the same name. Never match on a name alone.

A sourced gap beats an unsourced fill. These are the open questions on this person, stated rather than papered over.

Research notes

[TREE] Added 29 Jul 2026 under the people-related-to-the-land rule: child Jacobus Daniel Johannes OosthuizenM (PER-000004). Thin record; dates as in the tree. Tree also holds duplicate record(s) for this person.

30 Jul 2026 [FS]: FamilySearch G899-7S6, 1854-1937, agrees. FS also lists a SECOND Ockert Almero among the same siblings: 1859-1911, PHJ9-HS1 - either an FS duplicate or a second brother of the name; not created as a person here [TO VERIFY].

30 Jul 2026 [SRC-126/DOC-0086] Listed third among the five surviving children on his father's 1903 death notice.

[31 Jul 2026] MERGED PER-000542 into this row. PROVEN DUPLICATE, resolved on the FamilySearch id. Both rows carry G899-7S6; an FS id names one person, so these are one person recorded twice. Created by the 31 Jul 2026 one-degree tree pull, which matched on tree id alone - and 255 model people carry no tree id, so any of them one hop from a tree-linked person was added again. Survivor is the pre-existing row; it carries the prose, sources and land links. DISAGREEMENTS, kept rather than resolved - the FamilySearch id settles these in one click: birth_edtf: kept '1854~', PER-000542 said '1854-07-17'; tree id: kept '', PER-000542 said ''. Retired ids kept for the trail: tree - a merged FamilySearch id still resolves, so it remains a usable door.

These are working notes, not finished prose: they carry the reasoning, the corrections and the things still marked to verify. They are kept here so the page itself can read as what is known.

Open questions

Duplicate candidates from the one-degree pull, settled on FamilySearch ids priority 2 · LEAD-0035
38 people added on 31 Jul 2026 share a name AND a birth YEAR with somebody already in the model, and 32 share a name with no date at all. Are they the same people?

What would settle it A full birth or baptism date on either side of a pair. Name plus YEAR is not enough here and must not be treated as enough.
Nine people carry a different FamilySearch id here and in the tree priority 2 · LEAD-0036
For nine people the model records one FamilySearch id and the family-tree's _FID records another. Which is the live profile, and are the two ids two profiles for one person that want merging on FamilySearch itself?

What would settle it Loading each id and seeing whether it redirects.
Seven people carry a hand-entered FamilySearch id that the family-tree disagrees with priority 3 · LEAD-0019
Backfilling familysearch_id from the family-tree's _FID tag agreed with the hand-entered value on 103 of 110 people and disagreed on 7. Which id is current for each - or do both resolve to the same person after a merge?

What would settle it A redirect proves a merge and the survivor id is the one to keep. Two live, distinct profiles means one of them is the wrong person, and the vitals decide which.

Elders

FamilySearch profile G899-7S6