Trouble tracking land use over time

[Sunnylew]

I'm trying to track land ownership over time but running into trouble when I try to make the relationships meaningful.

In this village I am researching, a large stretch of land may have been subdivided into many smaller fields. Some of those smaller fields may then be further subdivided, and some others may be combined into larger fields, perhaps combined with areas which were not part of the original very large field they started from.

So for example in 1800 there is a field A. In 1846 this breaks into many fields: AA, AB, AC, AD ........ In 1860 AL and AM combine. In 1865 they combine with part of another originally larger field system - AL + AM + BD. This larger field splits into five different pieces,  and so on and so on

I'd like to be able to track the ownership and the various uses/descriptions of a piece of land tracking forward and back in time from any point. I can do this manually by looking at the maps, but can't see how to simply show the various incarnations that field AM was part of throughout time by using relationships.

Can anyone help me figure this out?

Cheers

[Tom R.]

Hi,

This is an interesting problem, and one that I've given some thought to in the past in the context of my work as a title attorney creating chains of title to parcels of land. I'm curious what the nature of your research is?

Also, when you say you'd like to "show" the various incarnations, what exactly to you have in mind? Something like a map, or more of a narrative/textual history or report? Also, are you dealing with metes and bounds described tracts or PLS sections, quarter-sections, etc (assuming the lands are even in the U.S.)?

At any rate, this is a classic many-to-many relationship, where a given tract of land could potentially have multiple child tracts and/or multiple parent tracts. This is usually dealt with using a join table. Taking this approach, you would need a table for Tracts (or parcels, or your preferred naming convention), that would include an ID field, a legal description field, and whatever other data you might want to track, maybe acreage, etc. You would need a second table to use as join table; I can't think of a meaningful name for it, so you could call it something like TractJoin. This table would have at a minimum a field for a parent tract foreign ID and a child tract foreign ID. You would then handle creating new records by script - for a tract that is subdivided into smaller tracts, save the ID of the parent tract in a variable, then in a loop create a new Tract record, save its ID in a variable, then create a new record in the Join Table, and set the parent and Child ID fields with the appropriate variable. For combined tracts, it would be the opposite - save each of the parent tract IDs in a variable, create a new tract record and get its ID, then loop through and create records in the Join table.

I hope this helps! 

[comment]

1 hour ago, Tom R. said:

You would need a second table to use as join table; I can't think of a meaningful name for it, so you could call it something like TractJoin. This table would have at a minimum a field for a parent tract foreign ID and a child tract foreign ID.

In this case it would also need StartDate and EndDate fields.

[Sunnylew]

Hi Tom and Comment,

Thanks for your help.

I'm doing a One Place Study of a village through the 19th century in the UK. My idea is to represent a social history of this village using a 3D game engine to power interactions.

Visually, it might end up something similar to that old game SimCity, where you can watch people go about their business day to day. I aim to leverage knowledge of, for example where someone lives and where they work to automate wayfinding scripts to have them wander to and from their daily work, or to show specific events which I would have to generalise using tags with basic animations tied to locations and dates in the village. With enough information - mail routes, train times, newspaper reports etc - I hope to be able to represent life in a 19th Century english village.

It would also be a way of exploring sources that are related to either places or to people within the village. You could click on a building and see a history of who lived there and how it changed in a side bar. You could also click on a person who lived in a building and see a history of their life.

Once I have a base of locations, any further research can be tied to specific locations relative to time - e.g. if I tag an event as occurring at the residence of Joe Bloggs in 1856, and know he moves house in 1854, it will be the later residence.

I need a solution that, if I choose a particular (grassy) field will be robust if later on I discover that that field split into three for 5 years before rejoining.

I've played with many to many relationships, but it always falls apart, because I don't actually yet know every permutation of change for each field. My research is ongoing, and I am creating shape files for the filed boundaries as I find new maps and tying them to a specific time. There are gaps of twenty years or so between some maps, so I will have to accept the grey nature of any field change and probably just calculate an average date between known boundaries for the date of the change.

If I knew every permutation of change for a field, I feel I could make an arbitrary string like a family tree for each field that would track it, but I just don't know enough information for that, and may never know every change that would be required.

I need some objective way of referring to a field that is independent of further research discoveries. 

I've has some more time to consider this, and thought that as my shape files are all georeferenced, I may be able to create a virtual subset of grid squares or points that would act as a cloud of locations within any (grassy/arable etc) field in the village. These are fixed lat/long points that would not change, so a calculation based on the shape file might be able to create a cloud of points that could be matched to any area over time.

That last paragraph may not make much sense, because I am now way over my head. I feel like this is heading towards what might work, but to tell you the truth it's all a bit overwhelming and confusing for me now.

Semantically, how would I go about this? Do I break up the entire area of the village into 1m square blocks ( or similar) and use that as the master table for locations?

I don't know how I would link this, but perhaps some function could calculate the best match for the range of 1m blocks in its area and assign the appropriate (grassy) field based on time and the latest research.

Sorry of this is a bit of a ramble, but my brain starts leaking whenever I think to hard about how to implement this.

Cheers,

Lewis

[comment]

IMHO you should track only the information that you have. If you have a reference to a piece of land, then enter that piece of land to your database. If you learn that this piece of land is (or was at some time) part of a larger tract, then enter the larger tract too, and connect the two in a parent - child relationship (via a join table, as described by Tom R. above).

Eventually, for every documented piece of land you would have a portal showing its various parents over time, and another one showing its various children over time.

 

Edited June 30, 2016 by comment

[Sunnylew]

Hi Comment, that makes sense, though I'm still uncertain what would happen if I added records for a particular piece of land without knowing what came afterwards.

For example, I have lists of tithe payments, which are based on the area of the land occupied. I have a map of the land in 1846 recorded in my database, and a map of the two parcels it becomes by 1906 as well. These are linked via a child-parent relatinship.

If the tithe record for 1847, with all areas, names, and the land description is identical to the 1846, I can confidently link the tithe to the 1846 database record. 

Where I get stuck is seeing how a view of the tithe record can then show the 1906 children of the 1846 map. Won't the tithe record then be unrelated to the 1906 map unless viewed from the point of view of the 1846 map itself?

[comment]

I was referring to the way you enter pieces of land - specifically to the idea of treating every square meter as an object to be tracked by your solution.

WRT to other objects, such as documents or events: if a document relates to more than one piece of land (including multiple incarnations of the same lot), then obviously you want to enter it as such. This would be another many-to-many relationship, requiring a join table. Otherwise you could just enter it as a child of the referenced piece of land.

With some effort, you could have a portal showing documents that relate not only to currently viewed piece of land, but also those that relate to its ancestors and/or descendants.