TLDR: Texas_Oklahoma_GodsEyeRepo Forked Bilawal Sidhu’s open-source God’s Eye View into “Smart Zones”: pick a state, every interstate recolors by traffic exposure from the DOT’s own live AADT feed, and clicking a segment estimates what a lane closure does to your drive. TX + OK live from Esri FeatureServers, nothing re-hosted. Open data. Two questions for the group: how would you style a statewide GeoJsonDataSource by attribute, and what standard would you build live work-zone-feed ingestion around?
Work zones killed 850 people in the US in 2024. A lot of the data that could make them safer already exists in public feeds. It just lives in separate systems that don’t talk to each other, so it rarely reaches the driver, the navigation app, or the automated vehicle in time to matter. The emerging Connected Work Zone standard (built on WZDx) is the policy answer to that. I wanted to see how far you could get on the visualization side with nothing but open data and CesiumJS.
So I forked Bilawal Sidhu’s open-source God’s Eye View, which fuses live public data streams onto a photorealistic 3D globe, and pointed it at state DOT roadway feeds. The result is a “Smart Zones” view: pick a state, and every interstate recolors by traffic exposure, drawn straight from the agency’s own published AADT feed. Click a segment and it estimates the human consequence of a lane closure there, using standard FHWA/HCM planning factors. Texas and Oklahoma are wired up now, both from live Esri FeatureServer endpoints, no data copied or re-hosted.
The thing I keep coming back to: the data was never the moat. These agencies already publish this. The work is in fusing open feeds into something a person can actually read. And the same view has a second act. Point it at a live WZDx feed and the hypothetical closure becomes the real one, same interface, higher confidence. That is a pretty direct argument for why an agency should stand up an open feed in the first place.
What’s in the fork (Smart Zones module):
- A small
src/smartzones/module that stays out of the base app’s layer system, so it’s easy to lift into your own build. Three files plus a two-line hook inmain.js. states.js— a per-DOT registry. Each entry is just a FeatureServer query URL, a list of candidate WHERE clauses, and the field names for route and AADT. Adding a state is filling in one object.esriGeoJson.js— a dependency-free ArcGIS FeatureServer to GeoJSON loader that handles the three things that actually break these pulls:maxRecordCountpaging, schema drift between agencies (it probes WHERE candidates with a cheap count query and picks the first that returns features), and geometry weight (server-sidemaxAllowableOffsetso a statewide interstate pull stays browser-friendly).index.js— the state selector panel, Living Atlas state boundaries, the AADT choropleth ramp (green to red by daily volume), and a click readout that turns route, AADT, and roadbed type into a plain-language “if one lane closes here” estimate. It’s directionality-aware, since single vs. divided roadbeds report AADT differently.
A couple of open questions I’d genuinely like input on:
Has anyone here styled a large GeoJsonDataSource polyline network by attribute at statewide scale? I’m recoloring per-entity after load, which is fine for interstates but I suspect won’t hold up for a full functional-class network. Curious whether folks reach for a custom primitive, per-feature batching, or 3D Tiles from vector data at that point.
And more broadly: if you were fusing live work zone or incident feeds onto a globe like this, what open standard would you build the ingestion around? WZDx feels like the obvious spine, but I’d like to hear where people have hit its edges.
Happy to share the repo link and setup notes if there’s interest. Grateful to Bilawal Sidhu for the open-source foundation this builds on.