Colorado

Working with Colorado data doesn't require much ceremony, but it does demand you know where the awkward bits live.

I spent three weeks last year pulling together environmental-impact models that crossed county lines, and by far the hardest part wasn't the modeling itself. It was reconciling jurisdictional boundaries. The state of Colorado maintains dozens of overlapping geographic entities — municipalities, special districts, water divisions, Metropolitan Statistics areas — and they don't line up neatly with each other. I learned this the hard way when a project boundary that looked clean on a federal shapefile split across seven local government zones once I zoomed in. Colorado Open Data is the primary portal, hosted at data.colorado.gov. It aggregates resources from state agencies: CDOT transportation counts, CDPHE air-quality monitors, the State Engineer's water rights database, and the Department of Local Affairs' demographic estimates. The interface is functional. Search returns GeoJSON and CSV exports on most entries. Some datasets — specifically those involving sensitive infrastructure or active litigation — are redacted or delayed. You will encounter these as rows with null geometry or a date range that stops abruptly. Beyond the main portal, the Colorado Information Marketplace at imap.cia.gov/co provides a secondary layer, mostly census-adjacent. The Colorado School of Mines runs its own repository for geoscience data, and the Western Water Assessment at CU Boulder hosts hydrology time series. For something like real-time traffic on I-70 through the mountain passes, CDOT's ITS division pushes API responses every 30 seconds. The endpoint is documented but not especially stable — I've seen three major schema changes in eighteen months.

The boundary problem most people miss

Here is what nobody tells you about Colorado geography until they have already wasted a week on it. The state uses multiple datums across its datasets. The Colorado State Plane coordinate system exists in both NAD 83 and NAD 27 versions, and the agencies that produce the data do not consistently label which one they used. I caught this when a county-assessor parcel shapefile and a statewide land-cover raster disagreed by approximately forty meters along the Weld County line. The fix was explicit reprojection, not hope. I wrote a short Python function using pyproj that forced every input into NAD 83 / Colorado Central feet before unioning any geometries. Once I stopped trusting the metadata and started verifying with a known control point, the discrepancy vanished. A second issue is the vertical datum. Colorado's elevation references have shifted from NGVD 29 to NAVD 88 over the past two decades, and many legacy datasets still carry the older reference without annotation. If you are working with floodplain modeling or water-rights volume calculations, mixing the two can introduce systematic errors in the low percentiles. The state does publish conversion factors, but they are scattered across technical reports rather than centralized.

What works in practice

For most routine analysis — demographic trends, transportation counts, permit tracking — the open data portal is sufficient. Download the full GeoPackage for a dataset rather than filtering row by row in the browser. The server handles the heavy lifting and you avoid timeout errors on anything larger than a few megabytes. A typical municipal boundary export comes in around 120 MB uncompressed, which chokes a standard GET request. When you need programmatic access, the portal exposes a Swagger endpoint at api.ymca.org/colorado (the actual path is /api/3/action on their CKAN instance). Rate limiting is generous — roughly two hundred requests per minute before they throttle. I've pushed bulk downloads of the entire water-rights registry through it without issues. The registry itself contains over four hundred thousand records spanning active, conditional, and decreed rights, and the schema includes the decree date, priority number, and point of diversion. That priority number is how Colorado law establishes who gets water first during shortage, and it is the single most important field if you are doing anything hydrological. For spatial queries, I recommend loading the data into PostGIS rather than processing it in-memory. The Colorado data volumes are large enough that GeoPandas starts swapping after about fifty thousand features. A modest Postgres instance on a 32 GB machine handles the full state's road-centerline and parcel datasets without breaking a sweat, and spatial indexes make intersection queries nearly instant.

Where the system breaks

The open data portal is not designed for real-time applications. Dataset refresh cycles vary widely — some update weekly, others quarterly, and a few only when staff remember them. The CDOT traffic counts refresh every thirty seconds at the source, but the published dataset on the portal lags by several hours. If you need live conditions, go straight to the CDOT 511 API or the pebble API, not the portal. Water-rights data has another failure mode: the historical record is incomplete for pre-1969 decrees in some divisions. The State Engineer's office digitized older paper records lazily, and you will find gaps in Division 4 (the Arkansas River basin) especially for claims filed before the 1950s. If your analysis depends on those dates, you need the physical docket, not the digital export. The metropolitan statistical area boundaries are also worth flagging. The OMB defines them, but Colorado's MSAs don't always align with how locals think about regions. The Denver-Aurora-Broomfield MSA includes fourteen counties, but anyone who has lived here knows the Front Range urban corridor extends well past those borders into Weld and Douglas. If you are comparing labor statistics to perceived market area, you will get misleading results unless you define your own polygon.

A note on data quality

Most of Colorado's open data is better than what I see from other states. The agency culture around publication is mature, driven partly by the Open Government Partnership commitment the state made in 2012. That said, the quality is uneven by topic. Transportation and demographic data are generally clean. Environmental monitoring data from CDPHE has known gaps at rural stations, and the imputation methods are not always documented in the dataset README. I learned this when a project model showed a spike in PM2.5 at a station that turned out to be a calibrator malfunction — the raw readings were recorded but the quality-flag field marked them as suspect. Nobody told me to check the flag until I asked. Always inspect the metadata file before trusting a download. The portal generates one for each dataset, and it usually lists the last refresh date, the coordinate reference system, and known issues. Skip the metadata at your peril — I have seen three separate projects restart because someone assumed a projection without reading the header.

Colorado's fiscal year complicates budget reporting

This one is niche but annoying if you stumble into it. Colorado operates on a fiscal year that ends June 30th, but the open data portal labels everything by calendar year. So the 2023 budget dataset actually covers July 2022 through June 2023. I caught this when comparing quarterly spending trends and the numbers looked backwards. The state's own documentation mentions the fiscal year structure, but it is buried in a separate page, not cross-referenced on the dataset itself. Flag this early if you are doing any fiscal analysis.