In order to produce interactive zoning maps, OpenCounter relies on zoning data that meets specific standards. Most of the time spent with a new client city’s spatial data involves transforming the data from the city's format into OpenCounter's.
One way to reduce the time required to configure your city is to prepare your data so that OpenCounter can reliably and repeatedly transform City data to match our internal standards.
This article intended for technical staff in zoning, planning, and GIS, as they prepare base zoning, overlays, PDs, and other spatial data for OpenCounter configuration.
Which formats does OpenCounter use?
OpenCounter uses an in-house Extraction-Transformation-Load (ETL) solution to consume (extract) your data, prepare (transform) it to ensure it meets certain standards, then load it into the OpenCounter zoning database.
OpenCounter ETL (OETL) works best when consuming JSON data from Feature Services or Map Services using REST. These services are provided by Esri ArcServer, Accela, and other data portal providers.
If you are able to provide base zoning, overlay, and parcel spatial data via these services, please do so. Otherwise, please provide the files in shapefile format.
Read more about OpenCounter ETL here.
Which attributes should we include?
At the very minimum, OpenCounter data requires a geometry attribute, zoning district designations (“zone codes”), and zoning district names (“zone names”).
If your city does not have zones with special conditions such as planned developments, zones with special limitations, or conditional zones, these might be the only attributes required.
For example, one record from Las Cruces, NM would be:
name: Single-Family Residential
geometry: binary geometry data of a polygon in zone R-1
Please ensure that the following attributes are available on the dataset, as separate columns.
Zoning designations are usually represented as codes. Some examples from our client cities R-1 (for a residential zone), or M1 (for a manufacturing zone).
Some cities keep overlay designations in the zone code, such as R-WO-H (indicating a residential zone R with a Wetland Overlay and a Hillside overlay district). We request that overlays be sent as separate geometries, so please do not include any overlay designations in the zone code.
Make sure to include the name of the zone, as we present this information to users. Ideally, this will be in Title Case as opposed to ALL CAPS.
As part of the transformation, we titleize zone names, but automatic titleization can lead to less-than-perfect capitalization.
OpenCounter ETL consumes and stores data exclusively in the WGS84 projection, also known as SRID 4326. You may upload any type of geometry to your Feature Service / Map Service endpoint, but please ensure that your endpoint is capable of re-projecting geospatial data to WGS84 / SRID 4326. ArcServer and Accela offer this as a built-in feature, usually set through the "Output SRID" attribute in the query form.
4. Document references
Many of our client cities have a plethora of documents, usually in PDF format, that indicate modifications to the land uses and development standards on a collection of parcels. In most cities, these areas are called Planned Developments (PDs) or Planned Unit Developments (PUDs), but some cities refer to them as SLs (zones with Special Limitations), conditional zones (zones with special conditions), and so on.
In order for us to properly configure the land uses on these zones, it’s important for us to be able to know which documents belong with which polygons on the map.
At minimum, please include a reference to the document name or number. If you are able, please provide a web address linking the document in a separate column.
We ask that overlays be sent as separate geometries—and we’ll cover this in depth further down the article. However, you are free to indicate—in a column separate from the base zone code and name—codes that indicate any overlays that may affect a given polygon.
In order to provide users with helpful information, we include descriptions of zones, taken from the municipal code. If you are able to include the zone description as a text column in your data, we welcome that additional information.
Links to municipal codes
We think it's important to direct users to the city's municipal code, so they can get the detailed information they seek. If you are able, please include links to the municipal code describing and regulating that particular zone, as a separate column in the zoning file.
How does OpenCounter distinguish zones?
OpenCounter internally uses the concept of an "admin name" to distinguish distinct zones.
The admin name is usually a combination of zone code, zone name, and ordinance number. For example, using the zone attributes from Las Cruces above, the admin name would be "R-1 - Single Family Residential".
Any polygons in your zoning data that have a zone code "R-1" and zone name "Single Family Residential" will be considered part of the same zone, and the clearances set on all of these polygons will be identical.
Thus, spelling is very important. If one of your "R-1" polygons has its name spelled "Single-Family Residential" (notice the addition of the dash compared to the previous example), its admin name will be different, and clearances will not be set properly until the misspelling is corrected.
We often include additional attributes in the admin name, especially for planned developments and the like. In Gainesville, FL, planned developments have a code "PD", the name of the planned development (e.g. "Foxfield et al"), and the ordinance number, which we format to be in parentheses "(3417)".
Planned Developments and other special areas
One important edge case to note is that if uses differ between sub-areas of a planned development (or similar), these sub-areas distinguished by some attribute. We regularly find a planned development that has multiple sections, each with a different set of uses, but they are not sent to us as distinct zones.
For example, in the Foxfield planned development in Gainesville, Florida, there are two sections: one which allows office and business uses, and one which does not. Both sections have the same attributes, and therefore the same admin name: "PD - Foxfield et al (3417)".
Because these two sections are not distinguished by any attribute, we can't make the admin names distinct, and we are forced to set the identical clearances on what should be two separate sections. Thus, in this case, we are not able to perfectly model where the business/office uses are permitted, and where they are not.
If your city has zones like this, please include a column we can reference while forming admin names, so we can distinguish the areas.
In the above example, a column (perhaps "pd_subarea") could have had values "Office" and "Residential", enabling us to generate two distinct admin names:
- PD - Foxfield et al (3417 Office)
- PD - Foxfield et al (3417 Residential)
The following quality checks will reduce your configuration time by more moderate amounts. These checks are helpful both as internal data QA practices, as well as a way to ensure a smooth transition to OpenCounter
Distinct zone names
Zoning data is usually edited by multiple people, over a long period of time. This, quite naturally, leads to errors in the data, some of which can take a while to clean up.
The most common error we see is the misspelling of zone names. For example, one of our cities has a zone "EE - Equestrian Estates". When we received their zoning data for the first time, however, the EE zone had 5 distinct names, each a variant of "Equestrian Estates", but all referring to the same zone. To fix this, we had to find all the misspellings, find the correct spelling in the municipal code, and then run a transformation in our ETL system to correct the misspellings across the entire file.
To check for misspellings in your zoning data, run the following query. We've written it for SQL, but your data manager may have another query language you can translate this to.
SELECT DISTINCT(zone_code_column, zone_name_column)
ORDER BY zone_code_column, zone_name_column
This will display all of the distinct combinations of zone codes and names, and order them alphabetically. A quick visual inspection will allow you to notice duplicates pretty quickly. If you see two or more of the same code in a row, it means the zone name is spelled differently between those two codes.