Part of Van Aardsfontein No. 109

Van Aardsfontein No. 109 Ptn 6

6/109 on the cadastre · show on the map

The farm's own history, the grant, the original survey, sits on that page.

Farm number: No. 109
Portion: 6
On the cadastre: 6/109, portionregistered as VAN AARDSFONTEIN
District: Prince Albert
Modern surveyed area: 1584.2 ha

Why this farm is here

A piece of a farm already in this model. 37 km from Klaarstroom.

parcel Cut out of Van Aardsfontein No. 109

What the record holds, in order

undated boundary change subdivision: from Van Aardsfontein No. 109

Also bordered by, as the modern cadastre draws it

Ground that touches this farm on the Surveyor-General's current polygons and that none of the diagrams held here names. Derived from the geometry, not read off a document.

Cadastre

Surveyor-General diagram index for this parcel

Surveyor-General diagram index for the whole farm — where the original survey of this ground sits.

Research notes

[1 Aug 2026] IN THE MODEL FROM THE CADASTRE PULL ONLY. The Surveyor-General has a polygon for it and this project has no document that names it, so it carries geometry, an extent and a name and no history. It is here because the parent farm PAR-000064 is on the map as a whole-farm outline and its own panel said in so many words that four modern parcels inside that outline were not in this model. These are those four. It was absent purely because nobody had made the row, not because anything was missing from the pull: data/geo/prince_albert_farm_portions.geojson has held this polygon all along and match_cadastre.py can only match parcels that exist. Cadastre: 1,896.2 ha, LPI C06100000000010900006. Van Aardsfontein is in the model because it is NAMED ON THE BOUNDARY of ground we hold, and as of 1 Aug 2026 the farm on the other side of that boundary is also in the model: Klipgat No. 114 (PAR-000103), whose 1911 diagram names "Remainder Van Aardens Fontein" as its eastern neighbour N-O.

[5 Aug 2026] extent_ha BLANKED. It held 1896.2 ha, which is this parcel's GEOM_AREA from the cadastre pull divided by 10 000 - the field the 5 Aug match_cadastre.py fix identified as inflated by 1/cos(lat), about 19.7% in this latitude, on 429 records. The fix corrected sg_area_ha (now 1584.2 ha, from Shape_Area) but extent_ha is hand-maintained and no check reads it, so the defective figure survived the correction and was being exported: extent_ha is in export_public.PUBLIC_COLUMNS. extent_ha means AN EXTENT A DOCUMENT STATES, and no document here states one for this parcel - this row's own note above says so. So it goes blank rather than being corrected to the polygon figure, which is what sg_area_ha already is.

[13 Aug 2026] Renamed to the one form this model uses for every portion - the portion's own name, then the parent farm, its number and the portion in brackets - so that a name is legible in a list, a search result and a map popup without the reader having to know which farm number is which. It read "Van Aardsfontein Portion 6 (No. 109 Ptn 6)" before. Nothing about the ground changed.

The research behind this page, kept separate from it: dated working notes, open questions, and what is not yet settled.

Open questions

141 people are on this site linked to nothing priority 1 · LEAD-0074
Which parcels and people exist on the site as dead ends - reachable by a list, but linked to no document, story, owner or neighbour?

What would settle it For the 106 tree-derived rows, a parentage pass merged from the family-tree on tree id - which 6 already names as the direction of travel and which would connect them wholesale rather than one at a time. For the three floating names, find the document each came from and link it.

What the record is missing

Nobody is on record as ever having held this third order · B8 never-held
Van Aardsfontein No. 109 Ptn 6 is in the model and drawn on the map, and carries no ownership record of any kind, not a grant, not a transfer, not an occupation.

What would settle it The Surveyor-General's diagram for the farm number names the grantee and the date; the deed reference on it opens the transfer chain.

Found by breaks.py reading the model against itself, not written by hand, each one is a shape of missing record, not a fault in the data. The whole set is on the questions page.