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.

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.

What files does OpenCounter require?

  • Zoning file

  • Jurisdictional boundaries (i.e. city limits)

  • Parcel file

  • Overlays

Which formats does OpenCounter use?

All spatial layers provided to OpenCounter must be either:

  • a link to a Map/Feature Server providing JSON data over REST (HTTP/HTTPS),

  •  a shapefile,

  • GeoJSON

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

Geometry Requirements

All geometries provided to OpenCounter for portal configuration MUST be valid according to Esri and OGC/PostGIS standards.

OpenCounter staff does not generate geometries on behalf of client cities. Often, the text of municipal code will specify a boundary of some sort, but OpenCounter's interpretation of that language may differ from the City's conception of the same language, leading to different geometries.

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:

code: R-1

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.

  1. Code

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.

2. Name

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.

3. Geometry

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.

Optional attributes


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.

Zone descriptions

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.

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)

Did this answer your question?