Ockert Almero Oosthuizen

omstreeks 1854 – 15 Julie 1937 · Oosthuizen line

Descends from the root couple, 2 generations up

Name

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.

Naaste familie

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

'n Lewe in die rekord

omstreeks 1854 gebore Born
15 Julie 1937 oorlede Died

Ander van dieselfde naam

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.

Wat ons nie weet nie

Geen gedateerde rekord bind hierdie mens aan 'n bepaalde stuk grond nie.
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.

Navorsingsnotas

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

Die werksnotas op hierdie werf word in Engels gehou en word nie vertaal nie. Hulle verander met elke navorsingsessie, en 'n vertaling sou uit pas raak met die oorspronklike. Alles anders — die stories, die getranskribeerde dokumente en die koppelvlak — is in Afrikaans.

Oop vrae

Duplicate candidates from the one-degree pull, settled on FamilySearch ids prioriteit 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?

Wat dit sou uitmaak 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 prioriteit 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?

Wat dit sou uitmaak Loading each id and seeing whether it redirects.
Seven people carry a hand-entered FamilySearch id that the family-tree disagrees with prioriteit 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?

Wat dit sou uitmaak 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-profiel G899-7S6