Building NYC's Urban Sensor Infrastructure
A Governance Framework for the Office of Curb Management
NYC’s challenge with urban data infrastructure is not, at its core, a technology problem. The City has long possessed enough historical data and research to make crucial long-term planning decisions. What the City hasn’t built, however, is a comprehensive real-time data infrastructure layer that enables faster, more adaptive decisions – and what little real-time infrastructure does exist was built almost entirely around vehicles, missing out on pedestrians, cyclists, and other micromobility users. Even this data has its problems, however, as vehicle-centric data is fragmented across agencies and vendor platforms, with no shared governance framework or persistent institutional home.
To successfully build out an urban sensor infrastructure in NYC for everyone and made accessible to all, NYC government must work with the community to define the purpose of the sensors, build a procurement pathway for the pilot programs aiming to innovate, make the data more easily accessible, and establish a transferable system shared amongst agencies.
The recent April 2026 launch of the Office of Curb Management (OCM), aimed to manage sustainable and equitable curb policy across 6,300 miles of streets and approximately three million curbside spaces, creates both the opportunity and the urgency to fix NYC urban data infrastructure. Whatever OCM integrates or pilots will require real time data in order to iterate quickly or defend decisions made.




Urban data in NYC is typically collected through enforcement camera systems like Verra Mobility’s red-light cameras or TransCore’s congestion pricing Automatic License Plate Recognition cameras; or through commercial mobility analytics like Placer.ai which aggregates anonymized cell photo location data to produce foot traffic analytics.
Existing camera systems are often only focused on cars, ignoring the data-invisible pedestrians, cyclists, and delivery workers the Mamdani administration are redesigning streets for. Foot traffic analytics are directionally useful for broad corridor-level trends, but cannot answer block-specific operational questions. It undercounts populations less likely to carry smartphones, including elderly residents and children, and struggles with real time events like parades and construction. Most of this data collected also has mixed ownership, leading to challenges accessing and processing the data. In addition, when a subscription ends or a vendor exits the market, this data may be lost. Even a 2024 Comptroller audit found that DOT has restricted access to data vendors it is actively working with, including Verra Mobility.
All of this traces back to the same root cause – a city that has never built the governance layer to analyze its own data. The pattern manifests across three conditions: a real-time multi-modal data gap, pilot purgatory, and data dependency and fragmentation.
Problems with NYC’s Current Approach
NYC has no shortage of street data collection programs. The Partnership for New York’s Transit Tech Lab, Office of Technology and Innovation’s (OTI) Smart City Testbed, and Department of Transportation’s (DOT) own sensor and enforcement infrastructure collectively represent years of street-level data collection. But without a strong governance layer, it can leave these street data programs fragmented across platforms, siloed by agency, and largely inaccessible once a contract ends or a program stalls.



Launched in 2023 under the Adams administration to streamline piloting, OTI’s Smart City Testbed ran a number of pilot projects including running pedestrian counting at various street locations, tested air quality sensors, and deployed a number of LiDAR traffic scanners. But under Lisa Gelobter, OTI’s new CTO and Commissioner, all new applications have been paused and it remains an open question if this will continue. By design, all programs were early-stage experiments, running from six to nine months and self-funded by vendors, yet they lacked a defined pathway from a successful pilot to procurement. The Pilot: NYC report named this condition as pilot purgatory, where the City tests, learns, and then does nothing afterwards. The vendor-driven approach also compounds this problem as the focus tends to be solution-first instead of problem-first. Vendors proposed what their technology could do, with the city evaluating whether it was interesting or not, not necessarily solving an issue.
Two years ago, DOT also tested out a smart curbs pilot on the Upper West side through Transit Tech Lab’s Curb Activity Challenge with a qualified vendor, Populus, to digitize curb and parking regulations across the pilot area. But within the next year, City Hall paused the Smart Curbs parking reforms and deployment of curb activity sensors due to political pressure from drivers. All of that data remains solely on the Populus platform, and with Populus recently being bought out by IPS Group, it is unclear whether this partnership or access to the data will be feasible.
Numina is another company that illustrates a similar issue. A Brooklyn-built, privacy-first pedestrian sensor company, Numina partnered with many organizations including deploying sensors at Fulton Mall with the Downtown Brooklyn Partnership and running a 31-sensor network on the Brooklyn Waterfront Greenway with DOT and the Regional Plan Association. Yet it still was never able to secure a city procurement contract with the city. The procurement path for it to financially scale did not exist and the data it created currently does not persist anywhere.
The structural cause underlying all three cases is the same. Place-based sensor pilots cost between $20,000 and $250,000 to install, exceeding micro-purchase thresholds and triggering multi-body approval processes with no legal path to scale or continue managing the data. This is a lot of time and investment made, only to lose all of this data.
The Amsterdam Approach
Amsterdam is an instructive example to learn from given its approach to responsible data collection. They have set up the framework to identify who would own the data, how it would be governed, and how public accountability would be maintained. This applies to every sensor deployed in the city regardless of who operates and supplies the hardware.
Paired with researchers from the Amsterdam Institute for Advanced Metropolitan Solutions, or AMS Institute, this framework allows for pilots to have a defined path to scale, while also ensuring that the data outlasts the vendor, reaffirming Adler and Florida’s research on urban tech confirming that the most durable urban technology innovations emerge not from technology hubs alone but from cities that develop the institutional capacity to test, govern, and scale them.
During a site visit to AMS Institute in March 2026, Director of Innovation Stephan van Dijk walked through the institute’s background as an academic facility collaboration created by Amsterdam between TU Delft, Wageningen University, and MIT and their Metropolitan Analysis, Design and Engineering, or MADE, approach. The program structures pilots through living labs, as outlined in the AMS Living Lab Way of Working Handbook: real life experiments co-developed with relevant stakeholders, designed to accelerate adoption and generate solutions that are tested with constant feedback loops, before scaling successes.
Van Dijk also described how AMS works with communities and city agencies to co-develop the models and assumptions behind data collection, making explicit what the data can and cannot tell, building flexibility into the models so that multiple stakeholders can test scenarios and interrogate the results. This reflects Nico Larco’s sustainable urban design framework with interventions designed with measurable outcomes and clear metrics from the onset.


Van Dijk shared how Amsterdam’s existing city sensoring technology worked, including a recent pilot project on scan cars equipped with LiDAR and other sensors that collect data on parking, waste, and street conditions, currently undergoing its own governance challenges. This was developed in part through the prototyping program led by Fabian Geiser, Project Manager of the Responsible Sensing Lab, a research facility focused on how social values including privacy, inclusion, autonomy, and transparency can be integrated into the design of smart technology before deployment begins. Its six-step Responsible Sensing Toolkit structures this process from defining use cases and goals, through public engagement and data collection, to impact analysis and reflection.
Walking through Amsterdam’s streets during the visit, it was clear to see this toolkit in effect, as cameras throughout the city were visible and notable, just as much as the signs notifying residents of the cameras. This is because of a mandatory Sensor Register, enforced since December 2021, which requires all sensor owners in Amsterdam — private companies, research institutions, and government organizations alike — to register every sensor deployed in public space on a public online map showing the type of sensor, the owner, and whether personal data is processed. Residents have the right to know where data is collected.

It is crucial to note that Amsterdam operates under a different municipal approach. As David Dolowitz and David Marsh warn, not every policy from another city is easily transferable. Unlike NYC, Amsterdam is not separated across DOT, DEP, DSNY, and DCP, making it easier to manage procurement.
Amsterdam also operates under GDPR, which provides a clear enforceable privacy framework, in which NYC does not have a federal or state equivalent. There is also a higher level of trust and political cultural difference in government data use, contrasting NYC’s digital rights advocacy and surveillance scandals. Amsterdam is also smaller, making sensor coverage much more straightforward, whereas NYC is considerably larger with much more extreme density variation. Despite all this, there are a few takeaways NYC can hybridize.
Recommendation: A Four Stage Framework
The framework proposed here addresses the three main conditions: the real-time multi-modal data gap, pilot purgatory, and data dependency and fragmentation. To successfully build out an urban sensor infrastructure in NYC, I propose a four stage framework: working with communities to define the purpose of the sensors, build a procurement pathway for successful digital sensor pilots, make the data easily accessible, and establish a transferable system across agencies.
Step 1: Define the Purpose
DOT, working with OTI, Business Improvement Districts, and other agency & community organizations in designated pilot zones, should conduct a 90-day community data needs assessment that defines the operational questions the sensor data must answer. This upfront planning and success defining helps make it clear to NYC who they are serving, leading OCM to identify who should be prioritized with sensor infrastructure, including pedestrians, cyclists, and delivery vehicles.
This also addresses the political vulnerability and culture that killed the Smart Curbs pilot. When a community co-defines what gets measured and why, the data serves the community’s stated interests rather than being experienced as surveillance imposed from outside. Pilot zone selection here is critical as an equity decision, as communities that are both data-invisible and most directly affected by OCM, particularly lower-income neighborhoods with higher concentrations of cyclists, delivery workers, and pedestrians with truck traffic and air quality burdens. Answering a South Bronx block’s own questions about truck noise near a school is substantively and politically different. This is the same design logic embedded in Amsterdam’s Responsible Sensing Lab, ensuring the data serves populations with greatest need.
It is critical manage this partner relationship carefully, requiring careful consideration who is at the table and who has access to the data. Without community support, there may be strong opposition pushing against any future rollout or testing of any kind, not to mention it loses the diversity and color from the very residents OCM aims to track.
Step 2: Build a Procurement Pathway
Mayor’s Office of Contract Service (MOCS) should work with the Deputy Mayor for Operations to establish a challenge-based procurement pathway, specifically for urban sensor infrastructure, modeled on the Transit Tech Lab’s Curb Activity Challenge, but with three critical additions: a data persistence clause, requiring raw data delivery to city-controlled infrastructure; a defined scale-up criterion that converts successful pilots into procurement decisions rather than archived reports; and BIDs or other community organizations as eligible co-funders of sensor deployments, splitting installation costs between city procurement and BID capital budgets the way BIDs already co-fund streetscape improvements.
PilotCity’s Pitchfest, launched by Cornell Tech’s Urban Tech Hub and NYCEDC as a direct implementation of the Pilot:NYC report, already demonstrates that the problem-first, agency-academic partnership model is feasible at scale, with DOT’s own computer vision roadway inspection project moving toward procurement consideration. NYC should also structure more research capacity in the same way Amsterdam has done with the AMS Institute, potentially alongside existing institutions like NYU Tandon, Columbia, or Cornell Tech.
The legislation and legality around updating the procurement pathway, as well as the co-funding mechanism to scale these programs sustainably in the budget, will require a major overhaul to change this approach. This problem extends past digital data pilots, but given the urgency required for OCM, this is a prime opportunity to test what pushback could be received and what is required to change it.
Step 3: Ensure Data Persistence and Accessibility
The city must gain legal access to data rights and have it be readily accessible. Every data sensor contract going forward must include some form of data persistence clause. Raw data must be accessible with city-controlled infrastructure, in addition to a structured handoff protocol ensuring data services vendor exit.
OTI must enforce standardized data schemas so that there is supported technical capacity to normalize and act on future incoming data. This should all feed into a centralized urban sensor data repository, with a similar Sensor Register inspired map noting where all of this sensor technology is physically located across NYC, identifying type, owner, and data collection purpose. This opens up an equity opportunity for community organizations, academics, and environmental justice advocates to access the places where street-level data is collected.
Vendors may oppose this data reform, especially as it will require them to meet city-defined standards. Their opposition, lack of enforcement, and funding required in this recommendation are all high risk blockers for this step and will require strong technical expertise from within the city to make the right decision going forward. The culture around data management must change for the city to uphold any sense of longevity and control.
Step 4: Share & Coordinate Across Agencies
The three steps above require a single cross-agency authority to hold them together across budget cycles and administrations. The Deputy Mayor for Operations should establish an inter-agency sensor working group convening all required City and community stakeholders. The working group’s mandate should include aligning procurement cycles, sharing vendor vetting across agencies, publishing a unified sensor data standard, and reporting publicly in the Mayor’s Management Report on at least three accountability metrics that together measure progress: Street Coverage Rate, Sensor Deployment Rate, and Data Persistence Rate.
An implementation timeline would phase across three stages: a 90-day community data needs assessment funded through existing operating budgets; a 12-month procurement pathway buildout requiring MOCS legal updates and inter-agency alignment; and a 24-month data repository launch, requiring OTI capital and vendor contract renegotiation.
The primary risk of failure for any of the suggestions I made above is project management and communication breakdown, as OCM is new and the proposed OTI data collection framework will be created for the first time. Ensuring that all agencies collaborate and that digital data governance should be a top priority for the Mayor’s Office.
Takeaway
NYC does not need to invent a new approach to urban sensor infrastructure. The technology is here already, especially seen from pilots the city itself has tested with. Rather, it needs to build the governance layer that makes this approach and the data it collects durable. To deliver on the promise of the OCM, the data infrastructure and governance needs to be there to back it up.
Without real-time, multi-modal street data the office can own and act on, OCM will make consequential decisions about public space on data it does not own, at a pace the city was never designed to support, without the ability to defend those decisions when opposition comes. It needs this new innovative digital infrastructure to track pedestrians and micromobility and to share this information across all agencies, built with community support.
Amsterdam proved that the institutional design problem is solvable and provided the toolkit to do so through the Responsible Sensor Lab. Adapted for NYC, my proposed four-step framework — Define, Pilot, Persist, Coordination — is a process design proposal, asking all of these key offices to play a role in hybridizing Amsterdam’s model. Done well, it is also an equity proposal: a commitment that the populations most affected by street conditions and most invisible in the data NYC currently collects are the ones the infrastructure will serve first.






