But where will the cars sleep? Modeling parking metrics with ArcGIS Urban

Parking requirements are a vital aspect of zoning bylaws and can have a profound effect on the form that development takes. This blog explores how ArcGIS Urban metrics can be used as a tool to model parking requirements and explore how they impact development potential within ArcGIS Urban plans.

Parking requirements are a crucial component in many modern zoning bylaws and play a significant role in shaping the nature of future development and the character of neighbourhoods. As such, policy planners must pay careful attention to the potential impact of proposed parking minimums.

With ArcGIS Urban, planners are empowered to model the impacts of draft zoning policy on potential developments within their communities. So how do we configure Urban to model parking requirements, to better understand the concrete impacts of the minimums we are setting?

The answer is metrics - Urban’s powerful set of customizable calculation tools. When thinking about metrics related to parking, we are ultimately interested in two numbers: parking provided (by any parking areas we have modeled), and parking required (tied to residential units and non-residential space within a modeled site). We will address each of these in turn.

Note: This blog assumes that you have basic components of your Urban model already configured, in particular space use types. At a minimum, I recommend having space use types for both structured and surface parking, as well as for a range of residential and employment uses. For information on getting started with space use types in Urban, see here.

Calculating Parking Provided

Parking provided is the simpler of the two. To derive this value, we simply need to create a calculation that divides the net space area of all parking lots and structures by an average parking stall area. To do so, we will add three metrics from our header bar - Net Space Area, a Space Use Type Parameter and a division calculation.

Once added, connect the metrics so that the division metric calculates the Net Space Area divided by the Space Use Type Parameter.

Once this is in place, rename your division metric to “Parking Stalls Provided”. Then, open the Space Use Type Parameter and rename it to Parking Stall Area, setting a value for all of your parking related space use types (parking lot, parking structure, etc.) equal to your expected parking stall area. Your zoning bylaw’s minimum parking stall dimensions can be a good place to identify an appropriate number for this purpose.

Here I’ve assumed a parking stall area of 16 m2. Don’t forget to set the unit for this metric to area.

At this point you are probably wondering whether we are ignoring the significant amount of space taken up by drive aisles, walkways, access ramps and so on – all of those components of a parking lot/structure that take space away from the stalls themselves. Rather than accounting for this directly within our metrics dependency graph, we estimate the impact of these factors in the Net Area Factor associated with our parking space use types. This is a percentage value (expressed as a decimal) that allows us to specify the percent of total floor area that is available as ‘useful’ space. In my example, I have set the Net Area Factor for my parking space use types to 0.6, to reflect that approximately 40% of the total area of any parking will be given over to uses other than parking stalls themselves.

And with that, you’re done! When you begin to create parking lots and structures within a plan, Urban will automatically calculate the expected number of stalls within them.

Calculating parking required

Parking requirements are a little more complex. For one, within a bylaw they can vary significantly depending on the use they are associated with. For example:

• Residential uses might require a minimum:

• Number of stalls per household unit

• Number of stalls per resident

• Employment-related uses might require a minimum:

• Number of stalls per 100m2 of gross floor area (GFA)

• Number of stalls per job

• …and more!

To handle these different potential calculations within your metrics graph, I suggest configuring one calculation for each of the above associated with the applicable space use types and then creating a metric that sums all of these calculations together. The steps for each individual calculation are generally the same - add a metric to your graph to calculate the input number (jobs, households, population), take that number, and multiply it by a Space Use Type Parameter metric containing the specific stalls per unit/stalls per job/stalls per resident value for each space use type.

Let’s take a look at how we might create this calculation for parking required per household:

1. Add the built-in Dwelling Units metric to your graph, alongside a Space Use Type parameter and a multiplication calculation.

2. Rename the Space Use Type Parameter to “Parking Required per Household” and input values defined in your zoning bylaw for all your different residential space use types.

3. Configure the multiplication calculation to multiply Dwelling Units by Parking Required per Household and rename it “Parking Required (Households)”.

Creating a simple Parking Required per Household calculation.

These steps can then be repeated for each different calculation required by your bylaw, and then summed into a single Total Parking Required metric:

Here I have configured calculations based on Households, Jobs, and m2 of GFA, but you may need more or fewer calculations depending on your zoning bylaw’s approach.

Working with multiple parking areas/precincts

Many bylaws include variation in parking requirements across specific areas in a municipality, such as to capture lower minimums in denser and transit-oriented areas. While it is technically possible to build conditional logic into Urban so that Urban can dynamically identify which set of requirements to use, with current metric functionality this can be a little convoluted. For this reason, I recommend taking the simplest approach - configuring multiple sets of parking metrics and labelling them clearly to indicate which set of calculations applies to which parking area/precinct.

After building out one set of calculations as described in the previous section for your first precinct, simply copy the entire configuration you have created, and update the various Space Use Type Parameters in the copied section to reflect requirements in your other parking precincts.

Creating multiple versions of your parking requirement calculation can also be a great way to test out how multiple draft versions of parking requirements will play out differently. How much more parking is required overall if we specify 1 stall per unit rather than 0.5 stalls per unit?

Parking requirements in action

Now on to the fun part – it’s time to model some new developments within a plan and take a look at our new metrics in action. First, after creating a new plan, remember to enable your new metrics in your Metrics Dashboard (see here for steps). To keep things clean, I recommend only enabling the “Parking Provided” and final summed “Parking Required” metrics. If you have configured multiple Parking Required metrics to reflect different areas/precincts, consider the location of your plan and only enable the Parking Required metric relevant to your study area.

Now as you start to create some development, you can toggle back to the metrics dashboard tab at any time to explore the expected parking requirements for a given site, and whether you’ve provided enough parking to accommodate these stalls.

I’ve created a small apartment building with an exterior parking lot, but it looks like this lot is not big enough to accommodate all of the required parking stalls within my new draft bylaw. I’ll have to either consider adjusting my policy or add some substructure parking if I want to produce a building of this size on this lot!

Conclusion

Parking requirements can have a significant influence on the form and feasibility of development proposals, making them an important consideration when evaluating zoning policies. In this blog, we’ve explored how ArcGIS Urban metrics can be configured to calculate both parking provided and parking required, adapt to different bylaw approaches and precincts, and help assess the impacts of policy decisions within development scenarios. Whether you’re testing a new zoning framework or evaluating the implications of existing parking minimums, metrics can provide valuable insight into how policy choices may shape future growth.

If you have questions about ArcGIS Urban or would like assistance configuring metric calculations for your own planning workflows, the Esri Canada Community Planning team of consultants is here to help. Reach out to your Account Manager to schedule a call with us!