Knowledge Center
  1. Home
  2. Knowledge Center
  3. Applied Research

LBCS Implementation

Mirroring the multi-dimensionality of land-use in databases requires a database scheme that can store multiple codes. Relational databases offer an easy platform for implementing such a schema.

Although most land-use coding can be done using flat files, such as spreadsheets or simple text files, assigning multiple codes to a single parcel (or spatial unit) requires a relational setup where the tables allow assigning multiple codes to a single record. In LBCS, multiple codes refers to both codes from the same dimension and codes from other dimensions. This is similar to assigning multiple phone numbers to one person in a contacts database.

It should be noted that implementing LBCS concepts is not contingent on a relational database or even having a database. LBCS can be applied anywhere land uses are employed. Take for instance lists of permitted and prohibited uses in a zoning ordinance. They contain just a list of uses. LBCS can be applied to developing such lists. Because many planners ask for help in implementing LBCS using databases, we have provided these models. They are neither mandatory nor required to implement LBCS.

Quick Implementation

For most common land-use applications (land-use surveys, local comprehensive plans, regional land-use data aggregation, etc.), LBCS implementation can be distilled to the following steps:

Step 1: Refer to the top level classification scheme.

Step 2: Create five new fields, one for each dimension of LBCS, in your land-use database (assuming each record in the database is a parcel or its equivalent) and name each field as follows: LBCSActivity, LBCSFunction, LBCSStructure, LBCSSite, LBCSOwnership

LBCS Data Model One Table

Sample LBCSOneTable (zip)

Step 3: For each parcel in the database, assign a top-level code (1000, 2000, 3000, etc.) for each of the five dimensions. That is, every record will get five land-use codes, one for each LBCS dimension. For any unknown dimensions, use the code 9999. It stands for unknown or not applicable. Remember, in LBCS there is no vacant land category.

Step 4: Reference the color coding standards and use those colors for online viewing of maps, rendering or plotting on map plotters, or printing using color printers. They should look consistent across most formats.

Implementation Using Multiple Tables for Parcel Data and LBCS Dimensions

Instead of creating five new fields in your land-use database, create five new tables, one for each dimension. Then link the parcel database to each of the five tables using a one-to-many relationship. Such a setup allows assigning as many activity codes to a single parcel in the Activity table, as many function codes as necessary in the Function table, and so on.

LBCS Data Model Multiple Tables

Sample LBCSMultipleTables (zip)

Implementation Using One Table for Parcel Data and One Table for All LBCS Dimensions

Instead of creating five new fields in your land use database, create a new table with fields for each of the five LBCS dimensions. This is the recommended model for long-term data manageability and flexibility in developing new dimensions.

  • Keep the parcel database table, say ParcelDB, separate from the land-use assignments, say LUCodes.
  • Copy the LBCSCodes lookup table from the quick implementation sample LBCSOneTable (zip). It has a LBCSID unique field.
  • Create LUCodes table with two fields: ParcelID and LBCSID
  • Create one-to-many link from ParcelDB to ParcelID in LUCodes
  • Create one-to-many link from LBCSCodes to LBCSID in LUCodes
  • Assign as many codes as necessary to a parcel by populating the LUCodes Table
  • Add or remove Parcels in ParcelDB table without affecting how to assign land use codes

To add or drop dimensions, add new categories to LBCSCodes lookup table. Altering the underlying database structure is not necessary. Once the database is setup, planners can extend it without specialized skills in managing or designing databases.

Implementing on an SQL server with automatic dumping of summary tables would greatly help in managing the data for both operational needs (editing and updating) and analytical needs (data summaries, tabulations, etc.). Canned SQL queries can be re-used over longer periods in this model than the others as there's not much by way of changes to the database structure.

Extending LBCS attribues will require creating tables and making the appropriate links to them, a method preferable if the data is being updated by other departments that have their own systems. For instance, the tax assessors update the function dimension, the engineering department updates the structure dimension, the site plan division updates the site development character, the long-range planner updates the activity dimension, and so forth. The idea is that no matter where the data is "produced," land-use applications can use them when needed without recollecting or reclassifying the data. This method also offers a way to manage land-use changes from year to year by using separate tables for each year for each dimension.