Privacy-centred data-driven innovation in the smart city. Exemplary use case of traffic counting

ABSTRACT As urban areas around the world seek to transform themselves into smart cities, new technologies are being interwoven into the urban fabric that surrounds us. This process is often technology-driven and revolves around issues of quantification, cost reduction, and efficiency. This perspective is increasingly being challenged by more inclusive perspectives that seek to empower civil society and which focus on its needs and demands. A major concern with smart city technologies in public spaces is the lack of protection for individual privacy as a result of surveillance. In this paper, we have chosen the use case of traffic counting as an example to illustrate how the use of advanced technologies and integrated planning strategies can shift the balance between administrative and business interests on the one hand, and privacy concerns on the other, towards a privacy-centric approach. We propose a privacy-centric planning and development approach for smart city technologies. Through our use case, we demonstrate a privacy-centric participatory development process that led to a prototypical technical solution for privacy-friendly and human-centric traffic counting. We conclude this paper by deriving suggestions for more privacy-friendly smart city development processes from our specific use case.


Introduction
Cities have become data generators fed by a plethora of sensors and smart devices. Monitoring movement patterns and real-time control of city processes shows promise for achieving the goals associated with a data-driven, green, inclusive, and livable European city. These terminologies are commonly grouped under the umbrella of the smart city.
In the European Union, the discussion of a human-centric smart city approach has moved from the margins to the core of the smart city debate (see e.g. (Ulrich et al., 2016;Engelbert et al., 2019;Smart Cities Information System (SCIS), 2021; Tadili and Fasly (2019); Berntzen & Johannessen, 2016)). Questions on data privacy and how to opt out of an all-encompassing system spanning smart homes, smart streets and smart administrations are at the forefront of demands and motivate new privacy-oriented policies and technologies (Eckhoff & Wagner, 2018;Li et al., 2016;Martinez-Balleste et al., 2013;Wright & Paul, 2016).
Traffic analysis and optimization of the transport system is a core topic of the smart city discourse. Actors involved in the adaptation of traffic processes operate in tension between a human-centered, privacy-based approach and the optimization of traffic management systems (Cui et al., 2018). There are two central reasons for this. First, the traffic system is a key development area for greener and sustainable European cities (European Commission, 2020). A main aspect of this policy approach is the reduction of CO2 emissions while at the same time enabling steady transport capacities. Second, more than any other planning system, the traffic system has internalized a rationalist planning model based on the idea that efficiency is the highest value (Deka, 2004). This view has only recently begun to change with the advent of integrated planning approaches (Schwedes, 2019).
Private companies and research programs often use smartphones or otherwise generated (smart car) personal data to understand spatio-temporal patterns. These, however, while being highly accurate, do come with privacy issues (Thompson & Warzel, 2020). Political goals to reduce air pollution, increase traffic safety, and maximize efficiency of the inner city traffic system as well as private sector endeavors in new technology such as automated driving create a growing need for accurate spatio-temporal traffic data on a particularly granular level. Furthermore, traffic and city planners need to legitimize their policy and management efforts to reduce the impact of individualised mass transportation. In order to adapt traffic flow in real-time and to create data-driven policies, it is necessary to empirically evaluate the effectiveness of targeted measures (road closures, driving bans, speed limits) and their impact on all traffic participants on the basis of data and to relate these to other measurements (e.g. air quality or noise measurements).
While private companies use technological and economically highly advanced measures to satisfy their need for location data, public administration often collects traffic data through tedious, inaccurate and expensive processes. Typically, a group of individuals is positioned at certain points of interest in the city with the task to count moving vehicles by hand, a task that tends to involve a single group for each point of interest; the more complex the traffic situation, e.g., big intersections, the more people that are required. In the state of Berlin, for example, the official traffic census is a recurring event taking place every five years on specified dates; the collected data is then extrapolated yielding an approximation of the median of travelling motorized vehicles during a given year (Steinmeyer, 2015). Additionally, car registration data is used in order to predict quantitative changes of car traffic. In addition to issues such as organisational overhead, spatio-temporal generalisation and the lack of data validation, this approach leads to the reproduction of the car-centric traffic planning approach. The counting of further traffic participants, such as cyclists or pedestrians, increases the cost of such manual procedures dramatically and is thus implemented only at selected locations (SenUVK. Senatsverwaltung für Umwelt).
In addition to the still widespread manual counts, there are various methods of automated counting used by public administration, such as inductive loops, thermal imaging cameras, radar, and laser technology. However, the installation and operation of such systems is usually expensive and complex. Moreover, the issue with many camera-based counting systems, which some cities have been operating for quite a while, is that video files need to be stored in order to evaluate traffic quantities. This makes them suitable for highways, as there are no pedestrians and cyclists. In cities, however, the storage of such video data raises privacy issues, especially when recordings are made over a long period of time in the same locations, as this could reveal detailed information about individuals and their mobility, routines and personal lives.
The highly differentiated approaches in traffic analysis and counting with respect to data privacy concerns can be seen as a field of experiment for different actors shaping the future of the European city (cf. e.g. (United European Commission, 2016a;Nations, 2017;Smart City Charta, 2017)). Comprehensive, reliable and openly accessible data can yield new understandings of traffic behaviour, its causes and the mobility needs of people, and thus provide a solid basis to inform not only private companies, but also policy makers and the general public. To achieve this, traditional perspectives of cost and data qualityor in this case, data granularity -need to be extended to include the dimension of privacy (see Figure 1). Along those dimensions concepts should aim for high privacy, high data granularity and low cost. Balancing data granularity and, thereby, its usefulness to stakeholders with privacy concerns is the central challenge.

Approaching privacy issues in traffic counting
Through significant advances in computer vision in recent years, video-based technologies are being used more and more for real-world object detection and counting (Naphade et al., 2017;X. Xu Liu et al., 2016;Xu et al., 2020), which enables the analysis and monitoring of traffic situations using a multitude of devices. The technological solutions range from prototype-level implementations (Fei Liu et al., 2017) to enterprise systems "("DataFromSky" 2021) (Miovision, 2021). Proprietary enterprise products are often the first choice, as the technical expertise needed to integrate and maintain opensource solutions is often not available, and the need for technical support is high. At the same time, in addition to the often high costs, this leads to dependencies on tech providers and makes use case-specific and explorative approaches almost impossible. Furthermore, the customer must rely on the promises of the manufacturers regarding functionality, accuracy and privacy of the purchased systems as those are often not transparently documented due to trade secret policies.
The need for highly granular data on traffic flows and spatial patterns of movement thus has to be addressed with inclusive requirements that put people and their privacy needs at the centre. Accordingly, in this paper, we employ a technology that (1) can be built using affordable hardware and open-source software, (2) utilizes deep learning algorithms which store no video data and thus aim to preserve privacy by design, and (3) offers high data granularity. In the following sections we describe how we made use of a privacy-centred multi-stakeholder development process to develop a prototypical traffic counting system in real-world scenarios in the city of Berlin. Furthermore, we evaluate the usage and usability of the prototype as well as its accuracy under real-world conditions. Besides the concrete performance results and recommendations for the usage of the prototype, our approach shows how corresponding experiments could be implemented for similar technologies. Beyond the technical and analytical aspects, our work places an emphasis on the process, including participatory and regulatory aspects, and discusses how smart city projects can simultaneously address the needs for insightful data and the citizens' need for privacy and data protection.

Inclusive smart city requirements
As highlighted in the introduction, many approaches to a smart city put the focus on technology, data and algorithms. Accordingly, aspects such as scalability, technical robustness and the ability to provide real-time analyses of large and interconnected data sets can be found among the requirements of most projects in the smart city context (Nam & Pardo, 2011). (Kitchin, 2014) roughly divides the specifications of what makes a city 'smart' into two distinct yet related approaches: one focusing on the increasing usage of pervasive and ubiquitous computing and digital devices, and the other referring to the development of a 'knowledge economy'. According to Kitchin, both approaches share 'an underlying neoliberal ethos that prioritises market-led and technological solutions to city governance and development' and 'the prioritization of data capture', making data produced in the city an 'essential constituent material to realising a smart city version'. Based on a number of projects, he raises concerns with respect to various aspects, including the politics of such data, technocratic governance, and ethical issues with respect to surveillance, 'dataveillance' and control.
As scientists and citizens, we find the approaches that focus on people and their needs and perspectives most appropriate for contributing to a fair and sustainable urban development that is beneficial to residents (see e.g. (Thomas et al., 2015), (Gaved et al., 2012), (Berntzen & Johannessen, 2016), (Nam & Pardo, 2011) for possible participatory approaches). Technology and innovation should be used to transform our cities into 'livable, democratic, just, responsible, and innovative ones' (Green, 2020). Moreover, a city should be a place where people are active creators and not objects; accordingly, one needs to bring the citizens into the picture and put them at the centre of urban debates (March & Ribera-Fumaz, 2016). This has implications on the processes chosen to implement a smart city project, the technologies and algorithms used, as well as on the collection and provision of data.
A central question of all smart applications in an urban context that collect personal data is the protection of the privacy of individuals. The sensitivity of certain data sources is often not immediately apparent; it is only through further analysis or linkage with other data sources that the potential of data becomes apparent. This is particularly true for movement data ( (González et al., 2008), (Schneider et al., 2013), (Tu et al., 2018), (de Montjoye et al., 2013), which is often used in an urban context. In the European Union, the General Data Protection Regulation implements far-reaching legal regulations to ensure high protection of privacy, for example, by formulating strict rules for the usage and storage of personal data and offering citizens extensive rights to decide whether their data should be used for a certain purpose (including the right to withdraw a consent) (European Commission, 2016b). In Germany, the law provides an even more strict concept of how personal data should be handled by companies or other organisations, which is specified in two principles. First, §71 of the Federal Data Protection Act (Bundesdatenschutzgesetz) (Bundesdatenschutzgesetz (BDSG), 2017), demands that the data collecting party is only collecting as much information as is required for a certain task. This principle is known as data-avoidance and data-austerity (Datenvermeidung und Datensparsamkeit). Second, the German Federal Constitutional Court (1 BvR 209/ 83, 1983) has ruled that individuals have the right to decide how to disclose and use their personal data. This concept was described as informational self-determination (Informationelle Selbstbestimmung).
A people-centric approach to innovation in the context of smart cities in general, and traffic analysis, in particular, needs to go further and move people's perceptions on privacy to the foreground to maintain their support and participation (Townsend, 2013). The emphasis on individual and perceived privacy concerns has been highlighted by various authors. (Habib et al., 2020) have empirically assessed factors that affect residents' intentions to use smart-city services, with the result that 'perceived security and perceived privacy are strong determinants of trust in technology'. van Zoonen (van Zoonen, 2016) constructs a framework to address citizens' concerns regarding privacy in cities across two dimensions -one representing perception of particular data as more personal and sensitive than others, and one reflecting privacy concerns of individuals depending on the purpose of the data collection, ranging from service to surveillance. The resulting quadrants describe levels of concern 'ranging from hardly any (impersonal data, service purpose), to extremely high (personal data, surveillance purpose)' (Van Zoonen, 2016) (see Figure 2).
Traditional video-based traffic counting systems are typically located within the second quadrant -collecting personal data for surveillance purposes. Despite the fact that video recordings focus on 'impersonal crowds' rather than individual behaviour, as soon as these are stored and made accessible to others, the therein contained personally traceable information together with associated geo-positions poses additional risks for the disclosure of sensitive information, such as place of residence or place of work. A privacy-centered approach focussing on needs and perspectives of people, like the approach we are aiming for, should instead belong to the fourth quadrant, producing non-sensitive data for service purposes (see Figure 2).
We will show how the protection of privacy and compliance with legal requirements can be brought into focus without restricting the planning, innovation or development processes.

Privacy-centred planning & development: Traffic counting use case
As elaborated in Section 2, we consider the perceived protection of privacy and a peoplecentered, participatory approach to the development of smart city projects to be essential. In a real-world implementation, these objectives need to be operationalized and supplemented by additional requirements provided by participating stakeholders. In the following section, we take a closer look at our participatory process to (further) develop and test a traffic analysis system based on an existing software solution.

Technology stack: OpenDataCam
The open-source project OpenDataCam 1 (ODC) provides an exemplary way to create prototypical mobile systems that can track and count various types of objects, including passenger cars, buses, bicycles and pedestrians. The ODC software processes an incoming video stream in two steps. Objects are detected and classified per video frame using a pre-trained 'You Only Look Once' (YOLO) model. YOLO is a Deep Learning approach that has led to extremely fast and accurate models (Ouaknine, 2018;Redmon & Farhadi, 2018). The objects are tracked across subsequent frames using the V-IOU Tracker (Bochinski et al., 2018). The result is the path, or trajectory, of each object, labeled by the predicted object category. ODC processes a video stream in real time without storing any video or image data. As such, ODC by design gives high priority to the protection of privacy. The software and hardware setup are extensively documented and supplemented by videos 'to underline transparency and full disclosure on privacy questions' (OpenDataCam, 2021).
Users can define one or more so-called screenlines and ODC will store the number of objects per category crossing it (see Figure 3). Lines can be drawn, edited and deleted through a graphical user interface (UI). The UI allows tracking and counting to be monitored in real time and the collected data to be downloaded as JSON files. Further configurations can be made through an API.
The software runs on Linux and CUDA GPU-enabled hardware and is optimized for the NVIDIA Jetson Board series. Various boards can be used, ranging from Jetson Nano, a credit card-sized GPU computer that costs around 100 Euros, to more powerful computing boards, such as the ones we used in our experiments. The complete hardware setup consisting of a standard webcam, connector-cables (and a weather-proof camera case if the camera is supposed to be mounted outside a building) currently amounts to up to 1000 Euros and is thus affordable for most city actors.
Being an open-source project with an active community of developers and applicants, ODC allows for adaptations to particular requirements. The possibility of adding further hardware, such as sensors measuring noise or air pollution, or implementing new features, such as the exclusion of certain areas (e.g. entrances to buildings) from monitoring, enables high flexibility and agility. Furthermore, the immediate access to locally collected, rich data can enhance the active participation of citizens and foster citizen science projects and collective learning for manifold applications. Being a lightweight mobile product, ODC can be used to collect data at individual points of interest as long as access to power and data storage is available, enabling sustainable and flexible usage.

Participatory process
From a technical point of view, ODC is thus able to deliver on the promise of affordability, flexibility and extensibility while being fairly open and transparent. Fine-grained data on the movement of traffic objects is collected without storing personal data, which already ensures a solid degree of privacy protection. Hence, the OpenDataCam satisfies many of the requirements that we worked out in Section 2. Nevertheless, it is important to note that most of the projects in which ODC has been used so far have been implemented under specific conditions, typically by technically experienced people, and an evaluation of various aspects 'in the wild' is still pending. This concerns in particular: (1) Compliance with administrative and legal requirements (by Berlin city administration) (2) Meeting the requirements of potential operators and data (output) users (stakeholders) (3) Requirements regarding the accuracy of the tracked data (4) Technical robustness and scalability for a possible 24/7 utilization at multiple locations (5) Accessibility (ease of setup and usage) by technical and non-technical users As part of an iterative process, we tackled these aspects and developed our solution at each phase in collaboration with different partners and stakeholders. For clarity, we have structured our presentation in this paper by stakeholder; the linear process is shown in Figure 4.

Administrative process and privacy regulations
In order to understand the legally binding requirements concerning data privacy, we presented our general ideas at a very early stage to Berlin's data protection office. A lawyer helped us guide and structure our conversations with the involved institutions. Our goal was to work out operating conditions that would be suitable in a regulatory sense for two different scenarios: (1) regular setup: operating the ODC to collect and provide trajectories and counts, and (2) evaluation setup: conducting experiments to evaluate the algorithmic accuracy by recording and checking video sequences (see Figure 5). We consider the latter scenario to be relevant also in a potential regular operation, since performance evaluations should be run regularly by those who provide or use the technology.
A first important finding was that even the millisecond-long intermediate storage of the images in the hardware's RAM, which happens in both scenarios, requires security precautions; for example, a near-time forwarding of the count data to a cloud server via a WLAN does not readily comply with legal requirements. Furthermore, the storage of videos is problematic in itself. Overall, from a legal perspective, the use of ODC requires ensuring the following: (1) no image data can be accessed by third parties (2) information is provided to the public through signs at the camera's location, linking to (3) a website that presents information about the associated research project Based on the first requirement, we adjusted our operating scenario as follows (see Figure 5): • ODC is not connected to the Internet • Resolution of the videos is reduced so far that faces of persons or license plates are not recognizable • Only limited personnel directly involved in the project have access to the system • Videos for the evaluation setup are stored and processed on encrypted hard disks Contrary to expectations, the second requirement (provision of information to the public about the camera at the location where it is being used) is at least as complex to implement. There is no general information about what kind of permits one would have to apply for in order to provide signage. The responsibilities are unclear for the administration at the district and state level, as such, it took us several weeks to understand the administrative requirements. Ultimately, we had to apply for three permits at three different administrative offices: • Two permits (one per district because of the chosen experiment locations) to place street information signs • One permit to attach a sign to a building under historical preservation order The legal and administrative requirements thus have far-reaching implications for a possible large-scale deployment of camera-based counting systems. The administrative process needs to be streamlined and clarified to non-government actors who provide or maintain privacy-sensitive systems. Physical and network access to the full system, in particular its video feed, need to be secured and monitored. This is especially important when commercial uses of such a system are to be deployed. For numerous applications, a near-time provision of the collected data is necessary, so offline operation of the system is not feasible. The provision of a VPN would be an alternative for this, requiring additional technological infrastructure and safety provisions. Additionally, if videos need to be recorded for evaluation purposes, the obstacles might be significantly higher if the application is not part of a research project, as in our case.

Stakeholder participation
In the project, we implemented four participation formats: a stakeholder workshop, two prototyping workshops for students, and a one-day hackathon. In the following section, we will focus on the one-day participatory design workshop with stakeholders consisting of two urban and traffic planners from the District of Pankow, two technologists from ReachNow, one expert from the local public transport agency BVG, one scientist from the university HTW Berlin, one scientist from Technologiestiftung, and two representatives from the public waste disposal company BSR. During the workshop, the requirements and expectations for a data-driven approach to traffic data analysis were gathered based on the various perspectives of the participating stakeholders.
In the first part of the workshop, we focused on each stakeholder's immediate goals and the data they had available to achieve them. We asked participants to complete a form that identified their current data use, their respective tasks, and their overall goals. They were also asked to map current data use to existing goals.
We were able to identify four main objectives, with no suitable data sources available for three of them. We then discussed the results and moved into an open ideation phase. Here, participants were asked to design a traffic count use case specific to their particular needs. In the third and final section of the workshop, participants were grouped across disciplines and allowed to freely brainstorm and develop use case ideas.
During the process, it became clear that all participants relied heavily on data-driven approaches to advance their business interests, advance their cause, and to improve their public services. At the same time, a discrepancy between the need and the availability of validated, easily accessible, and comprehensive datasets became apparent. Figure 6 shows the relationship between stakeholder goals and the current corresponding data obstacles. Data obstacles describe missing data dimensions, which were perceived as necessary by the stakeholders to drive goal reaching processes.
The workshop further revealed various stakeholders' specific data needs. Public transit and public waste management representatives were keenly interested in using live monitoring of spatial patterns to create more efficient operations related to intermodal traffic as well as the impact of travel bans and traffic flow changes on their services. Planners took a more strategic approach, requiring data for spatiotemporal analyses for ex ante evaluations of transportation interventions and experimental approaches to road traffic management to be used as empirical support for new mobility concepts consistent with sustainability goals.
Non-profit stakeholders participating in the workshop argued for very narrow policy purposes of transportation data. Their need could best be described as collecting traffic data independent of public counts to draw attention to spatial and temporal patterns of movement at specific spaces and times. Unlike the other participants, they were also interested in engaging private citizens in counts to increase public engagement with their cause. Therefore, usability of the system by non-technical individuals can be identified as a key requirement for this actor. Table 1 lists the central use cases that were developed in the workshop, together with the central requirements for the overall system based on ODC. Here, we do not mention those requirements that ODC already fulfills, such as the low costs or the mobile use of the system.
As shown in Table 1, stakeholders at the workshop specifically identified the following additional requirements for ODC-based applications: compatibility with other data sources, real-time data transfer, usability by people without technical expertise, and reliable counts of different transport modes. The ODC data (trajectories, counts) are  compatibility with other data sources such as subjective input and weather data; solid detection of different means of transport Live monitoring of public spaces to adjust own operations (e.g. bus traffic) to changes in near-time.
strong privacy concept; near-time data transfer Enable traffic counts for citizens in their own neighborhoods, for example, to support demands for redesignation of car to bike streets.
solid detection of different means of transport; usability by laypersons; solid detection of different means of transport, in particular bicycles temporally as well as spatially highly granular machine-readable data and are thus easily linked with other data containing similar information (such as weather data). What is missing is the possibility to capture the geo-position (in terms of latitude and longitude) of the scene recorded by the camera and an automatic transformation of the position data in terms of relative pixel distances to real geo-positions. Real-time data transfer is possible with ODC, but this requirement represents a potential point of attack in terms of data protection, as described in Section 3.3. In our project, we worked with a privacy concept that rules out this attack vector; further experiments would have to be conducted to robustly test such a data transfer using a VPN, for example. We thus focused primarily on evaluating the accuracy of the system as well as its usability by non-technical people. The latter aspect also emerged as central in the course of the subsequent workshops, because many people interested in using ODC have no technical expertise and are dependent on an understandable system with easy configurability.

Experimental evaluation of accuracy
As elaborated in the previous section, for many use cases it is important to know how well the different transportation modes are detected and tracked by the system. Furthermore, dependencies on weather and light conditions are crucial to assess robustness for 24/7 deployment. In addition to providing a reliable evaluation of the performance, our goal was to develop recommendations for the most efficient use of the system. For this purpose, we designed four experiments at two locations: one on the second floor of a building in Berlin-Mitte with a bird's eye view of an intersection (location 'ECDF'), and one on the ground floor of a building, mounted in a plastic box outside, with a side view of a multi-lane street with an intersection (location 'CityLab'). The location ECDF thus allows for the camera's performance to be evaluated in situations where the camera is mounted on a window inside a building (such as to monitor the traffic in a roundabout, or on a high mast in a weather-protected fixture). Both locations are in the center of Berlin and are frequented by cars, bicycles, buses and other transport modes.
For all experiments, a short video was recorded every 30 minutes over a period of 7 to 9 days. A random sample comprising approximately half of the data was then drawn and manually analyzed by at least one human evaluator. Table 2 displays the settings of the four experiments. It is worth mentioning that the ODC software does not allow for video sequences accompanied by YOLO detections to be recorded. To be able to perform the experiments, we had to access the video stream directly and detect the correct time frame in the trackings recorded by ODC via the logged timestamps. 2 We then compared the manual evaluations with those of ODC and generated videos with annotated bounding boxes 3 for qualitative sample checks. For the quantitative analysis, we compared the manual counts with the ODC counts per recording and assessed the relative differences between the two. We performed suitable statistical tests in order to assess whether ODC counts differ significantly from the manual ones. Depending on the experiment, we measured the effect of additional factors such as light conditions or direction. Brightness was estimated by converting the video frames to grayscale and computing histograms based on a division of the image. 4 In addition, we added data on weather condition that we retrieved from Brightsky, 5 using the weather stations closest to our experiment locations.
The number of buses, trucks, and motorcycles per video was usually too small for a statistical evaluation, so we focused our analysis mainly on cars and bicycles and analyzed the detection and tracking of the other objects qualitatively.

Cars versus bicycles
In almost all experiments conducted, the count of cars was much more accurate than that of bicycles. However, the precision of the car counts by ODC strongly depends on the camera position. Both experiments at ECDF, taken from the bird's eye angle, resulted in higher accuracy than the experiments at CityLab with a sideways view at street level. More precisely, in the first ECDF experiment, the manual count observed an average of 3.5 cars crossing one of the two screenlines within 30 seconds; ODC counted an average of 3.49. A paired T-test yielded a p-value of 0.94, indicating that the evidence from our data does not suggest an effect between the ODC car count and counts produced by humans. The Bayes factor of 0.115 implies moderate evidence that both counts follow the same distribution. In the second experiment at ECDF we recorded two-minute videos (mainly to reduce the fraction of vehicles that are on the screenline at the beginning or end of a video, since it is not clear how to count them), yielding very similar results.
In the CityLab experiments, one of the two lanes was considerably closer to the camera. The vehicles in the lane further away were less well detected and tracked, mainly because the further away lane had a higher frequency of vehicles and thus more frequent overlaps. In the first of these two experiments, we considered the two lanes separately, accounting for different traffic directions. However, even for the closer lane, the count by humans differed significantly from that by ODC, albeit with a small effect size (p-value = 0.017, Cohen-d = 0.267). Qualitative analysis of individual video sequences revealed that overlapping vehicles (especially when turning vehicles lead to a partially obstructed view for the camera) and confusion with other object classes were among the most common causes of incorrect counts of cars.
The overlaps and confusions did not exist for bicycles in the closer lane: in the first experiment at CityLab, the counts by humans and by ODC did not show a statistically significant difference (p-value = 0.138, anecdotal evidence for the null hypothesis). In the corresponding 162 recordings, ODC detected an average of 0.91 bicycles (standard deviation = 1.58), while the human annotators counted 1.18 (standard deviation = 1.7). In turn, the bicycles in the back lane were hardly detected at all due to the significant distance from the camera.

Sight and distance
In contrast to its results at CityLab, ODC did not manage to count the majority of bicycles in the first experiment at ECDF. One of the reasons for this is the fact that YOLOv3 is not able to recognize bicycles as well as cars. The bird's eye view of the camera causes further difficulties: the bicycles cannot be seen from the side, so that the typical distinguishing features (such as the wheels) cannot be seen well. The distance of the camera also caused the objects to be very small. The tracking algorithm caused further problems in connection with this camera position. People set the screenlines depending on the street scene, i.e. according to viewpoints of the plane. However, the center of the bounding box also depends on the height dimension and shifts depending on the viewing angle. For example, the turning bus in the upper left frame of Figure 8 may not be counted, even though in reality, it has completely crossed the screenline that ends at the sidewalk. This is because the trajectory of the center of the bounding box may run outside the screenline. This issue arose especially for bicycles in our first experiment, since the screenline ended at the sidewalks, so as not to count pedestrians or parking bicycles.
We tried to solve this problem in the second experiment at ECDF by setting the lines appropriately and counting people instead of bicycles and motorcycles. The second modification was motivated by the fact that while ODC wasn't able to distinguish these two categories of vehicles particularly well anyway, it could hopefully detect the individuals on them and thus yield a good approximation of the overall number of bicycles and motorbikes. The result improved with the new inputs, but not sufficiently: ODC counted on average 2.52 persons (i.e. bicycles and motorcycles) crossing the corresponding lines, but the manual counting had an average of 4.33, i.e. around 40% more individuals counted.
In the first CityLab experiment, we also considered the effects of limited visibility (due to trees, bushes or parked vehicles, for example) and small spatial area between the frame boundary and the screenline. For this purpose, we set the screenline as depicted in green in the left of Figure 7. The result was that the vehicles in the rear lane were detected significantly worse; ODC missed on average about half of the vehicles.

Weather and luminosity
In most of the experiments conducted, the weather conditions were quite good; there was little precipitation and no severe weather events. Because of this, additional experiments   are necessary to evaluate the camera's robustness in the face of snowfall or strong storms, for example. For the indoor camera at ECDF, rain had no effect; for the camera at Citylab, which was mounted in a plastic box on the outside of the building, moisture sometimes formed inside the box and on the camera lens. This partially clouded the view or caused reflections through oncoming vehicle lights, which in some cases led to non-recognition of driving objects.
The night scenes confirm YOLO's bias for cars. Various lights are interpreted as car lights, but also objects without lights (see Figure 9). This is less problematic for static objects, because they do not cross the screenline. Also, for many moving objects, the effect of individual misclassifications is partially mitigated by the robustness of the tracking algorithm, so they are not reflected in the counts to the same extent. Nonetheless, lighting conditions have a statistically significant effect on car counts as well.
As part of the second experiment at ECDF, we compared the effect of light intensity on the relative error of bicycles and cars. For this purpose, we defined a threshold value for the brightness and analyzed the relative error in the corresponding groups. The relative error showed a different distribution for cars than for bicycles depending on brightness: in contrast to cars, brightness had a significant effect on the correct counting of bicycles.

Pedestrian counting
As mentioned above, in the second ECDF experiment, the class 'person' was configured to be recognized instead of 'bicycle' and 'motorcycle'. Two of the screenlines crossed a pedestrian traffic light, allowing for the detection of pedestrians to be evaluated. The average number of persons detected by ODC was 2.74, which is significantly less than the average of 3.66 counted manually. Similar to the case of bicycles, the detection rate at night is a lot lower. Also, sun reflections on window glass can make the area on the road darker and thus reduce the detection rate during daytime. Additionally, overlapping persons often could not be detected, highlighting the importance of the camera angle.

Recommendations to improve accuracy
The results from the evaluation show that ODC's accuracy is comparable to that of humans, 6 but in order to reach that accuracy, certain criteria regarding the setup of the system must be met. The bird's eye view yields better results than the side view, mainly since there is less overlapping. The distance of the screenlines to the camera should not be too large, as objects in the back lanes on a road with more than three lanes are not well detected. Care should also be taken when drawing the screenlines so that these catch the center of gravity of the 2D projection of objects.
The differentiation of larger vehicles does not work reliably with YOLOv3. Buses and trucks are often confused with each other; likewise, minivans are sometimes assigned to cars and sometimes to trucks. ODC also performs significantly worse in detecting bicycles than in detecting four-wheeled motorized vehicles. If one of these distinctions is relevant in a particular use case, one should consider either labeling additional data and retraining the neural network model used for object detection, or experimenting with the new version of YOLO, YOLOv4. Moreover, the tracking algorithm can also be fine-tuned towards robust tracking of bicycles. Pedestrians can be detected to a certain extent in daylight as long as it can be ensured that no bicycles are expected to cross the same area as those are frequently confused with the person class.
The detection rate at night is generally worse than during the day. This is in line with the results of (Tung et al., 2019) who demonstrated that YOLO struggles to identify darkcolored objects and yields false positives when there is little light using recordings from network cameras. It is, however, worth noting that in our experiments, the lower recognition rate affects objects with strong front light less than bicycles or motorcycles, for example.
The weather was not particularly variable during the period of our experiments; thus, we cannot make any claims regarding accuracy of ODC under severe weather conditions. Rain, however, did not have a significant effect on accuracy in our experiments. It is worth noting that retraining the YOLO model using additional data such as blurred, pixelated or darkened images can improve the detection quality of images under poor sight conditions to some extent (Jiang & Wang, 2016). This, however, requires manual labour and a certain level of expertise in Computer Vision.
As with many machine learning-based systems, there are performance degradations under certain conditions. The accuracy of a classifier cannot be better than the data it was trained on. Additional requirements, such as near-time processing to achieve more privacy, place additional limitations on the utilized algorithms. This makes the recommendations for the configuration of the system, including positioning of the camera and screenlines, all the more important in order to achieve the best possible performance. In this context, the importance of a GUI should be emphasized: the ability to watch live object detection and counting is a major advantage of the ODC software. In a real-world application scenario, we recommend making extensive use of this in order to familiarize oneself with the tool and perform evaluations.

Requirements for productive usage
Like many free and open-source frameworks and technologies, the OpenDataCam is not a ready-made product that can be started and operated at the push of a button. Rather, it is a project that is under heavy development and which requires manual assembly and setup as well as oversight during operation. In short, it requires both a significant time investment and significant technical knowledge to set up and maintain. However, the question is which steps require what kinds of technical or algorithmic expertise and where, if anywhere, there is potential for more empowerment of non-experts.
Setting up ODC requires technical skills that fall into the realm of system administration. Requirements for operating systems, memory capacities, and network configurations play a role here and can slow down the implementation process considerably. Depending on the microcontroller and our own technical equipment, the setup itself took us a few hours to a few days. This presents an entry barrier especially for Citizen Science projects, unless technical expertise is available. In the IT departments of most companies or administrations, there are likely to be people who would be able to successfully set up the system based on its detailed documentation. The need to install and upgrade software (as a result of bug fixes) is also a constant component of implementing ODC; we performed such an upgrade process 2-3 times during the project.
The storage of the accumulating data in a medium-to long-term planned operation requires technical adaptations. While relatively small amounts of data are generated for counts alone, the trajectories quickly fill up the boards' already small storage space. An operation that goes beyond short experiments and collects trajectories from objects thus requires either additional data storage capacity or the transfer of data to a cloud-based data storage service. Both alternatives entail certain disadvantages: the software is not designed to use external data storage and thus again requires considerable technical expertise in order to set this up; additionally, data transfer to a cloud requires additional security architecture and is not covered by the data protection concept developed in Section 3.3. This reflects the current character of OpenDataCam, which is (still) designed for prototypical application.
While setup, operation and maintenance of the system require significant technical expertise, initial experimentation, evaluation and configuration of the software is possible via the GUI and API. The GUI allows live object detection and the classification and counting to be observed; based on this, the position of the camera or screenlines can be optimized. Configurations beyond this are only possible via the API endpoints and are thus again difficult to use for non-experts. This applies, for example, to the specification of the object classes, the selection of the concrete model for object detection or the frame rate.

Conclusion and discussion
As we highlighted in the introduction, there is a trend in western smart city planning towards the development and planning of new urban technologies becoming more people-and privacy-centred. While this point is made in agendas and proposals, it usually lacks an outline of how to apply those concepts in real-world implementations. In this paper we have shown through the use case of traffic counting how an integrated people-and privacy-centred planning and development process can be structured and applied (see Figure 10).
The inclusive and participatory requirement analysis with stakeholders ranging from urban service providers to civic society (Section 2) brought to the fore the normative, legal, social, business, administrative and technical requirements (Section 3.4) these groups have. Those requirements were combined with an existing open-source system, the OpenDataCam (Section 3.1) and concluded in an integrated concept. In quick iterations a first prototypical setup was developed (Section 3.5) and evaluated towards its applicability in a real-world context (Section 3.6). This helped highlight limitations and advantages of the system and builds a basis for further research and iterations towards privacy-first traffic counting.

Integrated participatory-and privacy-centric planning
In our integrated and inclusive planning approach, we highlighted that putting stakeholders and privacy at the center from the beginning of the planning process helps identify restrictions, requirements and needs early in the process and ensures they can be addressed throughout the planning and development process. Legal and ethical requirements like data avoidance, data austerity and informational self-determination set high standards for smart city systems in the public realm. Engaging legal experts and the local data protection authority early allows for streamlining administrative efforts and creating a necessary privacy concept. Following the concept of agile, iterative development, it is necessary to retain a certain flexibility in the above mentioned privacy concept, in order to adopt the requirements of all stakeholders along the participatory planning process.

Potential of open source machine learning and computer vision for privacy
Recent advances in machine learning and computer vision allow us to process information in real-time, without the need for persistent storage of image or video dataa development that opens up interesting privacy-centric applications beyond our traffic counting use case. Well-trained machine learning models can often work with privacyfriendly low-resolution images and still detect objects. But the data used to train the models is not necessarily representative of the real-world situations in which the models are to be applied. To test whether such a model meets data quality requirements, one needs to evaluate it in a real-world setup. In our use case, we performed an accuracy evaluation through four experiments and thereby derived recommendations for the best possible utilization. For the specific use case of traffic counting with the ODC system, which makes use of the YOLOv3 object detection model, our results suggest that the counting of cars is comparable to that by humans as long as the camera position and the screenlines meet certain requirements (Section 3.6). At the same time the results also highlight that the accuracy of tracking deteriorates at night or under low-light conditions that the object class of pedestrians is not as accurately detected as cars, and that vehicle sub-classes like trucks, busses, cars and minivans are often confused.
In our use case, the accuracy of ODC's overall algorithm falls short of what commercial vendors promise, 7 except for the results on counts of cars under the conditions we recommend above. It is, however, almost impossible to check self-reported performance results of proprietary tools or to evaluate them under new circumstances; thus, users must rely on the promises of manufacturers. Here we see a clear advantage of open-source solutions, which can be transparently evaluated. Furthermore, with commercial solutions, it is rarely the case that one can modify such solutions or adapt them to new scenarios. Commercial traffic counting systems, for example, seem to focus on motorized traffic, leaving the question open as to how well the same system can be utilized to monitor the movement of bicycles and pedestrians. Also, in the context of privacy-centric development, the accuracy of low-resolution videos remains highly unclear, which we consider essential if trying to implement privacy by design. ODC, as other open-source solutions, on the other hand, gives the possibility of direct evaluation, optimization, and adaptation.
While open-source software is free, it comes with a high cost in terms of expert personnel for setup and maintenance. In our use case, as we highlighted in section 3.5 and following, the open-source software we used needed to be adapted and fine-tuned to meet our technical and legal requirements. Subsequently, the costs for experts and transparency of such systems have to be weighed against each other.

Vision
The trend for big data in the city brings to forefront the fundamental issue of a humancentered privacy-driven approach as a core element of a smart city designed by and for people. While there are still limitations in deploying ODC as an open source traffic counting system, we found that an open-source system such as the ODC allows for transparent and adaptive participation-centered implementation approaches.
While our use case showed a path to utilize an open-source system for a specific task, it has become clear that the above-mentioned limitations, particularly the need for expert personnel, continue to foster an environment in which primarily proprietary systems are implemented. To overcome this, we need to provide clear legal and administrative guidelines that are in line with recent technological developments. Such guidelines would allow for the transparent control of proprietary systems, while still allowing cities to enjoy the economic stability and efficiency provided by commercial software development. Additionally, however, we need to empower civil society and city administrations to be able to implement open-source solutions themselves, such as through employing the experts required to implement such solutions. City administrations and civil society actors should also work to standardize their requirements toward opensource solutions to make these solutions easier to implement in the future. Some organisations, such as OpenSourceEcology e.V Berlin and the DIN e.V, are already tackling this issue by providing an open-source DIN Norm for open-source hardware projects (Open Source Ecology Germany e.V, 2021). These kinds of efforts should be put into a legal and administrative framework for systems providing privacy by design. This process of standardization should ideally be embedded in a participatory process itself in order to help understand requirements and to support users and creators in utilizing these standards and technologies. Notes 6. Detecting no significance in the comparison of counts by ODC and humans does not prove that the groups are equal or that there is no effect. It primarily suggests that the evidence from the experiments is not strong enough to suggest that an effect exists in the population. 7. Miovision, a proprietary provider of a system for classification and counting of objects in videos, reports to achieve an accuracy of over 95% in various counting scenarios, including intersections and traffic circles. The high accuracy is achieved, among other things, through data services technicians who check ~12% of the data (Miovision, 2021). Another provider in this field, DataFromSky, reports that their license-free desktop application 'TrafficSurvey Viewer' achieves an accuracy of 98-100% "("DataFromSky" 2021).