Django model structure

Core concepts

A diagram of the components of the Deed Machine. To the left, an initial processing stage using AWS Step Functions is used to output a series of S3 files, which are ingested into a Django project in the center of the diagram.

The Django component of the Deed Machine can generally be thought of as the conductor or hub that turns raw processing results into structured data, facilitates the import and export to the Zooniverse crowdsourcing platform, allows for manual GUI editing, and manages final data exports.

The Django component of the Deed Machine is divided up into apps, and within each app, models.

The four Django apps are deed, parcel, plat, and zoon.

Main models that end users will interact with:

racial_covenants_processor
├── apps
    ├── deed
        ├── DeedPage
    ├── parcel
        ├── Parcel
        ├── ParcelJoinCandidate
        ├── ShpExport/CSVExport/GeoJSONExport
        ├── UnmappedCSVExport/AllCovenantedDocsCSVExport
    ├── plat
        ├── Plat
        ├── PlatAlternateName
        ├── Subdivision
        ├── SubdivisionAlternateName
    ├── zoon
        ├── ZooniverseWorkflow
        ├── ZooniverseSubject
        ├── ManualCorrection
        ├── ExtraParcelCandidate
        ├── ManualCovenant
        ├── ManualSupportingDocument

The Deed app

The Deed app houses information about historical property record images provided by records custodians to be searched for racial covenants.

After Uploading images/initial processing, management commands in the Deed app ingest metadata about these raw documents and whether or not they have been identified as potential racial covenants (i.e. the “hits”) into the Django/postgresql database.

See Ingesting results of initial processing for more about this process.

The Parcel app

The Parcel app is used to house information about modern, GIS-enabled property records, which are used to map historical racial covenants. The Deed Machine uses transcribed information about each historical covenant to try to link the addition, block and lot of each covenant to matching information in modern parcel records stored in the Parcel app. The Parcel app is populated by uploading parcel shapefiles into the GeoDjango Parcel model, with or without preprocessing.

See Uploading modern parcel data for mapping.

Mapping Prejudice counts racial covenants by identifying the earliest racial covenant document that is associated with a modern property. Thus, each row in Mapping Prejudice’s covenants exports represents one modern property, as opposed to each row representing one document, as the same racial covenant was often repeated in subsequent sales of the same property.

Logic for aggregation and export of racial covenants is mostly contained in the Parcel app through the CovenantsParcelManager.

The Plat app

The Plat app is used to organize information about historical plat or modern subdivision records provided by records custodians or county GIS offices. By uploading information about plats/subdivisions and by adding alternative spellings of plat/subdivision names, users can generate additional join candidates that may help to map covenants with unusual spelling variations in their addition names.

Though they are somewhat interchangeable terms in the larger property world, in the Deed Machine, the Plat model is for historical plat maps, while the Subdivision model is for modern, GIS-enabled data, which is more likely to be available, and can be used to spatially associate Parcel records with additional subdivision names.

The Zoon app

The Zoon app contains information related to Zooniverse transcription, including uploading of hits to zooniverse, and the processing of data coming back from Zooniverse Transcription.

Manual correction work is done by browsing the ZooniverseSubject list, using a combination of ManualCorrection and ExtraParcelCandidate objects that are generated by manual edits.

Covenants entered manually (not through Zooniverse transcription) are stored in the ManualCovenant model of the Zoon app.