A Model of Current and Potential Urban Development

Demonstrating Relational Database and Geoprocessing Fundamentals

Realtional database management systems form the basis of most of the information management systems that are used to record the properties of almost everything. Relational databses are a generic container for storing information about entities and phenomena, and for creating new information about how many different sorts of things relate to one-another.. Tables is used to store references to entities. A row, or record, in a table holds a collection of attributes that serve to distinquish one thing from another. Attributes may also be used to relate the entities of one class, to those of another. A set of assumptions about how things, rows, classes and tables are expected to be composed is discussed in our lecture notes. For now we will say that with an adequately designed set of tables, we can apply sequences of query, transformation, associative and summary operations that will yield useful new information about how things and ideas relate to eachother.

By running the same sequence of analytic steps on selections of records, we can learn things about useful differences between one place or class of entities and another. By altering the information in the database perform controlled experiments to explore alternative future scenarios. If we learn how to automate the workflow of our model procedure, then we can make a lot of experiments that will help us to understand the consequenses of one decision or another.

This tutorial will take a look at the fundamental operations of relational data models and also of developing well documented and repeatable workflow processing in ArcMap. This will all be put together around a buildout model for developpment in Somerville Massachusetts.

Prerequisites

This tutorial builds on ideas covered in the preceding tutorials: Beginning a Place-Based Data Collection and Thematic Mapping of Nominal Class Data, Thematic Mapping of Quantitative and Intensive Statistics

References and Deeper Reading

• Spatial Modeling for Scholarship and Decision Support
• Critique of Data and Metadata from the GSD GIS Manual.
• Using ArcMap particularly Chapter 10, Working with Tables.
• Building a Geodatabase
• Geoprocessing in ArcGIS

Download Sample Data

Right Click Here to download the sample dataset. Extract its contents to your C:\temp\yourusername folder.

---

Representing Development Intensity: Current and Future

As usual, we will not begin to use GIS until we are clear about what we are trying to represent. Without a clear formulation of a conceptual model, there is no point exploring data. Today we are concerned with development intensity near existing and proposed transit stops. Our conception of development intensity we will use the common planning metric: Floor Area Ratio (FAR), which is the amount of useable floor area of the building on a property, divided by the land area of the property parcel. We awnt to model existing intensity and potential development allowed by the zoning regulations. for individual parcels and for entire districts near transit stops. This will help us to understand opportunities and for infill. We would like to use this model to experiment with adjustments to the zoning ordinance or to the zoning of specific parcels to understand what the potential buildout impacts of these scenarios would be.

Our next step is to break this model into individual concepts and relationships and to think about how these might be represented with data and operations. Our property parcels will be represented by the 2006 Parcels Table from the City of Somerville Tax Assessor. Each parcel is represented as a row in this table, and has attributes including Lot area and gross floor area and a code that references the zoning classification that applies to that parcel. The potential development of parcels will be represented by the dimensional standards given in Article 8 of the SOmerville Zoning Ordinance (2006)These standards have been represented in a Zoning Class Table that represents each zoning class and its intensity allowances.

Naturally, we will want to explore these datasets and to critique them with regard to how well they represent our concepts. We should examine some of the questions described in Critique of Data and Metadata to asnswer the ultimate question about the errors of ommission or commission that may be inherent in our use of the data the way we hope to. This will also help us to understand how our data may be improved. One interesting aspect in this case will be to consider biases in the tax assessor's view of property, and also the fact that since the Zoning ordinance is itself a formal concept that may be almost perfectly represented by its map and its table. And yet, we know that in a mixed use parcel, should actually reflect the FAR for residential and commercial, and in our model we only have one number. We could probably fix this last problem.

We also should consider whether our schema complies with the fundamental expectations stipulated for Relational Database Management Systems. If our tables violate these rules then the tools that we create will generate false results. We can learn more about these in the lecture notes on Relational Database Management Systems.

References:

• Article 8 of the SOmerville Zoning Ordinance (2006)
• Modeling What's Important fom the GSD GIS Manual.
• Sorting Records in a Table
• Selecting Records from a table

Measuring Existing FAR

Our next step is to get summaries of exisitng FAR for specific areas of town that we define in our areas of interest layer. To do this we will have to add a new column to our table and use some relational database tools to update the value of that columnthat holds a value for FAR for each parcel. Then we will be able to calculate some summaries of the actual FAR being used in each zoning class. We will see that these summary functions can be requested to operate only on selected parcels. This will be a great opportunity to explore the utility of a spatial operation that lets us select the parcels within a particular area of interest. We will explore these functions with some Ad-Hoc tools in the ArcMap Graphic Interface. Then we will learn how to use and create geoprocessing tools that will let us create a repatable workflow that will both document and automate our routine for calculating exisiting FAR for a given zone.

Computing FAR per Parcel: Transforming Attribute References in a Table

The referencing systems used in a dataset may not immediately lend themselves to representing our concepts. In this case, our concept is FAR, but we have only Lot Area and Gross Area measurements for our parcel. This isn't too bad, since we can reasonably expect FAR to be a simple function of these two numbers. ASo we need only to create a new column on our parcels table and to populate it with a value of floor area divided by lot area. We will immediately encounter a difficulty in that ArcMap won't allow us to divide by zero. So we will do an attribute query to select only those rows that have a gross area greater than 0, and to the math. Then we will invert the selection and calculate 0 for the FAR of those apparently landless or unmeasured parcels (perhaps condos or tax exempt land) We will then map the result and see if it is logically consistent with our thematic map that did its normalization in the symbology properties.

References

• Selecting Records from a table
• Making field calculations

---

Making Summaries on Tables and Subsets of Records

So, we've made maps before, and they are useful for portraying data graphically, but what we really need now is Numbers! We want to know what the existing FAR in the entire city and in particular zones and in different parts of the city. This will be a good opportunity to explore table summaries. These are great but even greater when we learn how to do these with particular subsets of records that we can select. We will learn a new way of selecting parcels that fall within particular areas of interest to create summaries of development denisities by zone within specificly defined areas of town.

References

• Summarizing Records in a Table
• Selecting Features by Location
• Making a Spatial Selection with a Graphic

---

---

Calculating Buildout FAR

So, you have an idea of what the existing development density is in different zoning districts across the whole city and in specific parts of town and in alternative development scenarios. We sould keep in mind that in reality we can't always simply boost the FAr of a parcel if such increases are not permitted in the zoning. Perhaps we want to make recommendations to change the zonign ordinance and investigate the potential impacts of this, on the wholesale development capacity of the city or of districts? This requires a build-out model, and forces us to a slightly more complicated model. Each of our parcels is assigned to a zone with its Zone_ code. we know the actual FAR. What we need to know is the as-of right FAR per the zoning ordinance. Luckily we have this information in another table.

The table Zonecode_LUT has a record for each zoning code, and each zoning code is distinquished by a code, a name, an permitter FAR, and other attributes. The Code field is a unique key for the rows in this table. We can look at the Parcels Table and see how the values in the Zone_ field are references to the Code in the lookup table. This column of references is known as a Foreign Key This relationship can be used to create a new table view that dynamically joins these tables together. This will effectively add a new FAR field to our parcels table that we can use to calculate new developable square feet numbers for each parcel.

References

• Joining Tables

---

Creating New Zoning Scenarios

The next and last thing to think about is what if you wanted to change the zoning and investigate the buildout impacts. I will leave you with these two thoughts. There are a couple of simple ways of doing this. The simple way of doing this would be to select specific parcels and up-zone them by selecting a bunch and calculating a new value for the zone field. If you did this you would notice, upon closing and opening the parcels table, that the joined attributes from the Zoning Lookup Table have rearranged themselves automatically! Rather than writing over the information about existing zoning, we would create a new field, named New_Zone, and initialize it by calculating its values to be equal to the current zoning. Then we can select specific parcels to upzone, and calculate new values for New_Zone, which would become the foreign key for our new join.

Alternatively, you could take the big gesture of up or downzoning entire zoning districts by changing the allowable FAR for a district in the Zonecode_LUT (or creating a New_FAR field in the lookup table to represent proposed changes. You will notice if you close your parcels table and reopen it that these changes will also cascade dynamically to the joined view. IN reality, the way upzoning often happens is by the proposal of new special districts or Planned Unit Development areas. The way you would do this is by adding new districts to the Zonecode lookup table (you will see I have already added some. Then you can assign groups of parcels to these districts. This workflow has advantages of allowing you to try different scenarios without destroying the old ones.

To add rows to a table, you need to be in edit mode.

References

• Overview of Editing
• Editing Records in a Table

---

Automating the Process

The previous exercise was fairly rewarding, but could also become tedious if we had to do it too many times. With tedium also comes all sorts of potential errors that we may not catch (those are the worst kind!) So it would be nice to be able to automate this procedure. To actually script this workflow will also have the added benefit of allowing us to very easily share our method with other people. Thankfully ArcGIS provides a nice mechanism for doing this.

References

• Overview of Geoprocessing Environment Settings
• What is Geoiprocessing"
• A whirlwind Tour of Geoprocessing
• An Overview of Model BuilderYou may want to read this: Setting Up Models for a Collaborative Environment