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

WHO SHOULD USE THIS?

Anyone responsible for setting up a database to store land-use data classified according to LBCS. Although technical to novice database users, database administrators can setup an application easily using these models. The samples here are generic and can be setup using any standard relational database. They do not require a specific product or feature. We would also like to emphasize that suggestions here pertain to the concepts and do not imply any particular software or hardware usage.

SAMPLE MODELS

The samples illustrate implementation of LBCS concepts in a relational database. Some prior knowledge in relational database design concepts is a pre-requisite for understanding the diagrams and translating them into actual databases. They are industry standards that do not require specialized software or technical skills beyond those needed for setting up databases. Review these samples with the help of a database designer to see how to customize for a specific land-use application. Note that almost no one can use these samples "as is" without customizing for a specific implementation. We recognize that no land-use database exists independent of many of other kinds of data that go with land-use data. Consider these models only as a starting point for those developing land-use databases.

One table for parcel data and all LBCS dimensions (useful for assigning only one code per record):

• Recommended option only if you are migrating and this is an intermediate step
• An overivew of the data model. HTML format Visio format
• MDB file of tables for minimum coding (requires MS Access 2000 or ODBC drivers to read MDB files)
• A database dictionary in PDF of the above MDB file (useful if you cannot read MDB files)

Multiple tables, keeping the parcel data from the classifications separate and each LBCS dimension has its own table (useful for assigning multiple codes per record):

• Recommended model for new implementations of LBCS
• An overivew of the data model. HTML format Visio format
• MDB file of tables showing multiple coding (requires MS Access 2000 or ODBC drivers to read MDB files)
• A database dictionary in PDF of the above MDB file (useful if you cannot read MDB files)
• Keeping the dimensions in separate tables makes it easy for editing records using a GIS interface
• Altering the underlying database structure necessary if adding or dropping LBCS dimensions
• Extending LBCS attributes will require adding or dropping fields in one of the LBCS dimensions.

Multiple tables, keeping the parcel data from the classifications separate but all LBCS dimensions are in one table (easier to add more LBCS dimensions later while giving the flexibility of assigning multiple codes per record):

• Recommended model for long-term data manageability and flexibility in developing new dimensions.
1. Keep the parcel database table, say ParcelDB, separate from the land-use assignments, say LUCodes.
2. Copy the LBCSCodes lookup table from this website. It has a LBCSID unique field.
3. Create LUCodes table with two fields: ParcelID and LBCSID
4. Create one-to-many link from ParcelDB to ParcelID in LUCodes
5. Create one-to-many link from LBCSCodes to LBCSID in LUCodes
6. Assign as many codes as necessary to a parcel by populating the LUCodes Table
7. 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.

Note that these models can be implemented on most GIS platforms, typically, as attribute tables in a spatial database (or geo-database). GIS interfaces to the land-use data can be immensely useful to planners to code land uses. For instance, planners can use a GIS map with an aerial picture as a backdrop to quickly select parcels and classify them using no more than a series of simple mouse clicks. Even for complex areas, such visual interfaces can speed up the classification process, by many times the speed of editing individual records in a flat table. Think of maps not just as a way to present land-use data, but to actually edit the underlying database tables.

Ideally, a database administrator sets up the database, a GIS administrator sets up the interfaces, and planners use the GIS interface to add or update LBCS codes in the database. Whatever the interface, the design of any LBCS implementation should be based on ease of updating land-use codes. This updating should be integrated with routine planning operations, such as development reviews, comprehensive plan updates, demographic analysis, etc. In short, the more "data" is "captured" at the source, the better off in the long run. Land-use data should not be something one goes to collect, but should be a by-product of routine planning operations.

Implementation will no doubt depend on the technical resources available locally. This was indeed one of the main concerns in 1965 when SLUCM was first adopted. But we would like to think that by now, a generation later, our technical capabilities have matured to a point where planners can rely on relational databases.

GIS TEMPLATES AND TEST DATA

We have GIS legend files and test data for download.

WORKSHOPS AND TRAINING

For training on this topic, we recommend attending LBCS workshops offered at APA national and state conferences. LBCS staff and others also teach courses and conduct seminars at local universities. Agencies planning on having in-house expertise to speed the adoption of land-use standards, we urge two staff from the same agency attend LBCS training -- ideally, one planner and one GIS person. Usually it takes a one- or two-day refresher course. If enough local planners in a state or region are interested in hosting a customized LBCS training session, please send request to lbcs@planning.org.

Citation