Data/infrastructure in the smart city: Understanding the infrastructural power of Citymapper app through technicity of data

Abstract

Over the last few years, smart cities have been a focus of scholarly attention. Most of these critical studies concentrated on the multinational corporations’ discourses and their implications on urban policies. Besides these factors, however, the data-driven city develops within a complex web of entanglements whereby data-driven technologies modulate the urban infrastructure in a multitude of ways contingent upon the social, political, material and technical aspects. As such, this article attends to the infrastructural implications of a smart city product, Citymapper, which is a transport app built on open data available as part of London’s smart city planning. In order to establish the relationship between data and infrastructure, I use Gilbert Simondon’s notions of ‘transduction’, ‘individuation’ and ‘technicity’ to explore this relationship in a processual and relational way. In constructing this relationship as co-generative, whereby infrastructure and data transindividuate, I subsequently posit the term data/infrastructure. Against this theoretical background, I study the ways in which Citymapper individuates and thereby gains infrastructural power through technicity of data by studying the ways in which the users’ contribute to data generation that feed back into the app. Specifically, by following the transformation of the app from initially mediating the bus timetable to transducing users into environmental sensing nodes through which the app collects behavioural data, I foreground the epistemological, infrastructural and social consequences of Citymapper’s infrastructural power for the data-driven city.

The impact of code, software and algorithms on the production of space and urban governmentality was already of interest before the emergence of the term ‘smart city’ (e.g. Crang and Graham, 2007; Graham, 2005; Graham and Marvin, 2001; Thrift and French, 2002). However, when in 2009, IBM registered ‘smarter cities’ as a proprietary trademark, many scholars turned their attention towards unravelling the corporate-led visions that perpetuate smart urbanism (Alizadeh, 2017; Hollands, 2015; Luque-Ayala and Marvin, 2015; McNeill, 2015; Sadowski and Bendor, 2018; Söderström et al., 2014; Wiig, 2015). These critical studies of smart cities focus on the shifting forms of urban governance by an inquiry into the discourses led by multinational corporations; particularly, they argue that the smart city technologies are driven by rigid and formal urban management in a top-to-bottom fashion (e.g. Greenfield, 2013; Sadowski and Pasquale, 2015) whereby these technologies are deployed to ‘securitising’ (Wiig, 2018) and ‘disciplinary’ (Vanolo, 2014) ends. However, the increasing number of studies on the nexus of ‘data assemblages’ and urbanism (Kitchin and Lauriault, 2014) and lived examples from ‘the actually existing smart cities’ (Shelton et al., 2015) show that the data-driven urbanism develops within a complex web of relations in multitude of ways that involve but also transcend disciplinary, governmental and corporate power (e.g. Leszczynski, 2016; Madsen, 2018; Raetzsch et al., 2019). Moreover, instead of being a universal project, smart city policies are adapted to the specific characteristics of their socio-political environment (Baykurt and Raetzsch, 2020; Datta, 2018; Guma, 2020), and besides the institutional actors, as Gabrys (2014, 2016) and Krivý (2018) show, city dwellers’ participation is essential to data-driven urbanism whose operation takes place within a cybernetic framework.

Together with the “‘platformisation’ of infrastructures and ‘infrastructuralisation’ of platforms” (Plantin et al., 2018: 295), besides the studies of smart cities and data-driven urbanism, there emerged another strand in the literature looking into the impact of digital platforms in urban context, namely ‘platform urbanism’ (Barns, 2020; Rodgers and Moore, 2018), which attended to the implications of digital platforms in urban realm. These studies explore how recently emerged platform companies such as ‘shared’ mobility services (e.g. Duggan and Arcidiacono, 2019; Stehlin et al., 2020) or ‘home-sharing’ services (i.e. Airbnb) (e.g. van Doorn, 2019) transform urban life by forging new social, regulatory and economic relations (Graham 2020). Similar to smart cities, most of the debate on platform urbanism so far has been on the large corporations operating across the world. However, there is now a view that platforms should not be reduced to a matter of political economy solely, nor should they be only encapsulated as interfaces and algorithms. For instance, Richardson (2020: n.p.) argues that platforms should be examined as ‘flexible spatial arrangements’ and similarly, for Barns (2018: n.p.) they should be examined as ‘everyday socio-spatial practice’. Smartphones, apps and data these generate and mediate, are at the intersection of the reconfiguration of everyday life in data-driven and platform urbanism and the new spatial arrangements and practices they offer (Barns, 2018, 2020; Perng et al., 2016; Rose at al., 2020). As Weltevrede and Jansen (2019) state, however, despite the much scholarly attention given to platforms – as well as the traction in app studies – how apps as ‘data objects’ operate between platforms is under-studied. This article then aims to fill this gap by looking into infrastructural implications of a transport app by studying its becoming through various data practices embedded in everyday socio-technical and socio-spatial processes at the intersection of data-driven and platform urbanism.

To do so, I shift the focus from multinational companies that are mostly originated in Silicon Valley and study the ‘technical reality’ (Bunz and Meikle, 2018: 23) of a transport app that emerged in London, that is Citymapper. In doing so, my analysis provides insight into data-driven urbanism by exploring its very own product and thereby foreground how this product is embedded in larger socio-technical networks that include digital platforms. Citymapper is created as a result of Greater London Authority’s (GLA) experimental approach to smart city making in an ‘anti-planning’ framework (Cowley and Caprotti, 2018). When in 2013, the GLA set out their first Smart London Plan, they built their strategy on opening up public data (see Greater London Authority, 2013) in pursuit of fostering data-driven entrepreneurship and innovation (Barns, 2016; Cowley et al., 2018). Subsequently, this initiative prompted proliferation of hundreds of transport apps operating on open data retrieved from Transport for London (TfL) which is the administering body of public transport that is governed by the GLA. Among these apps, Citymapper stands out for becoming the shorthand for the success story that came out of London’s smart city policies. By focusing on the affordances of Citymapper, I explore how this app modulates urban infrastructure via technicity of data, as well as how urban infrastructure – in technical, material, social and political sense – facilitates and enables data technologies. Since digital data analytics are becoming ever more entrenched in urban governmentality, this study aims to provide insight into its implications critically by exploring the affordances of an app that is largely considered as a benign product of the smart city.

Being the direct outcome of GLA’s entrepreneurial and experimental smart city framework, Citymapper was initially built as a bus timetable app in 2012, but has since then become a ‘comprehensive everything app’ as the company’s founder and CEO Azmat Yusuf (2016) states. This means, the app is no longer merely an interface mediating bus timetable obtained from TfL; instead, it modulates the way users travel around their cities. This rapid and multilevel transformation that the app has undergone provides an excellent case to show how the implications of data technologies on spatial processes unfold. As I explore in this article, the development and transformation of Citymapper have taken place as contingent upon social, economic, technical and material constituents of smart city planning in London. Furthermore, together with the transformation that this app has gone through, it has also transformed the urban infrastructure, while the urban infrastructure is indeed what maintains Citymapper. In other words, the app has developed insofar as it has been datafying the infrastructure and infrastructuralising the data in multitude ways. As such, studying this generative relationality between the data infrastructure that this app is built on and the infrastructure it then transforms, helps reveal the process through which a transport app that started as a bus time table now relates to multiple domains such as tracking behaviour and facilitating platforms as well as claiming superior knowledge in urban planning and thereby experimenting with operating transport services. Subsequently, this study then explores Star and Ruhleder (1996)’ s famous analytical question ‘when is an infrastructure’ for data, as well as ‘when infrastructure is data’.

To show these, the article is divided into two main sections: in the first part, I will build on a range of theoretical approaches and concepts that study the intricate relation between code, software, space and urbanism. Following from Kitchin and Dodge’s (2011) comprehensive analysis of transduction of space by software into ‘code/space’, thereby showing how software ‘modulates the conditions under which sociospatial processes operate’ (p. 65), this article further draws on the work of Gilbert Simondon (1992, 2007), and uses his notions of ‘individuation’, ‘transduction’ and ‘technicity’ to explore the co-generative process between data and infrastructure. Whereas, the attention in Kitchin and Dodge’s work is on the impact of coding and software on spatial processes, this article will elaborate further on the relationality between data and infrastructure. As such, linked to their analysis of the relation of code/space, my aim is to posit the term data/infrastructure through which I am able to study data as infrastructure and infrastructure as data. By using a Simondonian approach, I join those who study infrastructures and data technologies in a processual way by developing their relationality as ‘contingent upon the environments, entities, and technologies that transindividuate together’ (Gabrys, 2016: 259). In other words, within this framework, data technologies emerge as produced concomitantly with the infrastructure as well as the urbanism they are born out of, instead of extrinsic entities that are applied onto urban realm after the fact. Furthermore, thinking through technicity enables grounding infrastructure/data transduction ‘in the material affordances of physically composed (complex) systems’ instead of abstracting them as immaterial (Kinsley, 2014: 376).

In the second part, I apply this theoretical conception on Citymapper app to show how data/infrastructure works. Here, my analysis focuses on the ‘infrastructural situatedness’ of Citymapper as a case study, which means that I attend to the app’s affordances in relation to social, technical and spatial processes in which it is embedded (Gerlitz et al., 2019). Since apps are ‘operational media’ that are ‘designed with behaviours – not meanings – in mind’, I carry out my analysis so as to study the infrastructural situatedness of Citymapper by examining what possible conditions it offers (Dieter et al., 2019: 5). To do so, I will adapt the walkthrough method ‘to critically examine the workings of [the] app as a sociotechnical artefact’ (Light et al., 2018: 886). Specifically, I will employ a version of ‘data-centric walkthrough’ and capture the app’s data input points systematically to study infrastructural implications (Dieter and Tkacz, 2020; Weltevrede and Jansen, 2019). Subsequently, this case study contributes to understanding an essential constituent of the data-driven urbanism at work: a ‘concrete software object’ that continually transforms ‘through interactions with diverse socio-technical situations’ (Dieter et al., 2019: 1).

Data/infrastructure in data-driven cities

The co-generative relationship between infrastructure, information and data is not a recent phenomenon; for thousands of years, as shown by Mattern (2017b) diligently, cities have been made of information, data collecting and processing. However, what is new is intensity, speed, scale and automation of the ways in which data, now digital, transforms infrastructural processes. Likewise, the software woven infrastructure is generating unprecedented amounts of data, which then feed back into how the infrastructure works. This is a reciprocal relationship: software generates data and data feeds back to software. Although most of the resulting technical assemblages from this relationship are a combination of already existing technologies, their convergence produces new technical and cultural artefacts (Fisher, 2020). For example, while urban infrastructure used to be typically understood as water, electricity, sewage, transport and so on, as a result of the city being woven with cables, sensors and smartphones, software run data technologies have now become infrastructural elements too. Consequently, these new technical and material entanglements engender data assemblages whose effect on the infrastructure often happens through the application programming interfaces (APIs) that structure them – in fact, APIs can be considered as one of the key elements in this new form of data-driven behavioural change. This was stated, for example, by Raetzsch et al. (2019), who argue that city APIs need to be conceptualised as crucial elements of urban infrastructures. While APIs are working in the background of everyday life almost always invisible to users, they facilitate accessibility and operability of data, which is crucial for urban planners and managers to govern the city. Following this claim that APIs are essential constituents of the urban infrastructure, this article makes a case for conceptualising data as infrastructure by turning to transport.

Against a ‘calculative background’ (Thrift, 2004: 582), one of the consequences of these new technical and cultural artefacts is the changing forms of mobility across the city and the mediation of transport options via apps and APIs. As the intensification of data practices have enabled them to become constituents of urban infrastructure, its systems, for example transport, has begun to be governed in new ways and within different temporalities. For example, Dublin’s intelligent transport systems, as Heaphy (2019) demonstrates, are developed through data-driven experimentalism with an aspiration for ‘operational consolidation’. Heaphy states that this consolidation takes place as ‘new forms of data-driven behavioural change, based on the dynamic treatment of real-time data, are encoded into procedures and organisational technologies’ (2019: 3). Through this encoding ‘into procedures and organisational technologies’, the urban infrastructure is now not only generating data, but it is also being perpetually restructured and redefined within the urban data assemblages. Before exemplifying such a relation with a case study of Citymapper app in the following section, I will firstly present a theoretical discussion to conceptualise the relation between data and urban infrastructure. To do this, I discuss the co-generative and co-dependent relation between data and urban infrastructure using Simondon’s concepts of technicity, transduction and individuation thereby building on research that investigates the relationship between software and the spatial processes.

Transduction of data/infrastructure

One of the influential books to study the relation between computation, software and space is knowingly Kitchin and Dodge’s Code/Space: Software and Everyday Life (2011), which explores the production of space by means of software and coding with particular attention to the spaces that are only functional by means of code. While this book is not primarily concerned with the smart city, it provides a useful template to think about the urban space that is ever increasingly generated and mediated through software and data. Here, Kitchin and Dodge emphasise that software and space mutually constitute each other whereby the performativity of software is contingent upon the space it operates: ‘code/space’ is when ‘spatiality is the product of code, and the code exists primarily in order to produce a particular spatiality’ (2011: 16). One of the examples they use is a check-in desk at an airport: it is through the software that this particular space functions as a check-in desk (Kitchin and Dodge, 2011: 142). In the case of a software failure, the space fails too; it can no longer function as a check-in desk but transforms into a mere waiting room. Drawing on such examples, they argue that ‘code thus transduces everyday life, alternatively modulating sociospatial relations’ (pp. 72–73) because software ‘possesses significant degrees of technicity’ (p. 72).

In this work, Kitchin and Dodge use Gilbert Simondon’s theoretical thinking around technicity and transduction by following Mackenzie (2003) to shift the relation of space and code. Working with Simondon’s terms from ‘The Genesis of the Individual’ (1992) allows them to foreground the processual aspect of the relation between code and space. In this essay, Simondon explains transduction as the process by which the individuation (in-formation) occurs through ontogenetic modulation and re-iteration. Here, the term ‘ontogenesis’ designates ‘the development of the being, or its becoming – in other words, that which makes the being develop or become, insofar as it is, as being’ (Simondon, 1992: 300). Through this analytical framework, one explores space and code in a ‘non-representational’ mode: the focus shifts from exploring ‘what they are’ to ‘how they become’ (Dodge, 2010; Timeto, 2015). Due to the processual and iterative nature of transductive modulation, the transduction of space by code unfolds as ‘an individuation in progress’ and a ‘progressive iteration’ (Mackenzie, 2003: 10). This approach also foregrounds the degrees of code’s ‘technicity’: the code is ‘doing something’ because it possesses technicity, which enables it to ‘mediate, supplement, and augment collective life’ as its evolutionary power unfolds in its environment (Kitchin and Dodge, 2011: 42).

The relation between code and space that Kitchin and Dodge study is also valid for data and infrastructure: during the transduction of infrastructure together with data, the technicity that pertains to both data and infrastructure is realised. As Easterling notes: ‘infrastructure space, with the power and currency of software, is an operating system for shaping the city’; thereby it also becomes a medium of information itself (2016: 13). Subsequently, infrastructure, just like software, has technicity as it is ‘doing something’, or, in this case, producing data that feeds back into urban systems. In other words, while infrastructure operates through software embedded, it also produces data that feed back into the systems. This is exactly the point where the analytical separation between data as infrastructure and data infrastructure starts to blur. On the one hand, infrastructure produces data that feed back into urban management systems; on the other hand, infrastructural systems run on data that possess technicity to reiterate the infrastructure progressively. This mutuality is akin to the relation between space and code that Kitchin and Dodge observed: code/space denotes a dyadic relation whereby they co-generate each other since code transduces space, and code is dependent on the space it operates. Similarly, individuation of data and infrastructure occurs through their transduction together in a dyadic way, hence, I posit the term data/infrastructure.

Data/infrastructure transduction occurs in relation to the environment they are in: when they individuate through the progressive (re)iteration, ‘relationality’ emerges as key to transduction. However, as Mackenzie (2003) warns us, relationality in the context of transduction does not refer to coming together of separate substances in a contingent way. Because, that would mean that these substances are pre-constituted entities, whereas, for Simondon, individual things within a transductive domain individuate in relation to each other. Data/infrastructure is therefore a term that signifies that a data-driven city is not a combination of two distinct beings, the city and the data, where data technologies develop discretely, and then get applied onto the city to generate a quantitative representation of it. Since they all posses degrees of technicity, the relation between data, software and the urban infrastructure cannot be explored separately from the spatial processes they facilitate. To understand the implications of data-driven technologies on the infrastructure it runs with, we need to think through software and data in the context of the urbanism they are enacting, because, individuation is never a standalone process but always an ‘ontogenetic process in the development of the larger entity’ (Simondon, 1992: 300).

As Gabrys (2016: 197) argues, observation of software as an agent thus needs to be situated within – not above or prior to – the ‘material-political-technical operations of the computational dispositif, since programmability necessarily signals more than the unfurling of scripts that act on the world in a discursive architecture of command-and-control’. This means, what software does when operating on infrastructure is not simply actualising the commands that are inscribed within the lines of codes. Instead, software performativity is contingent upon the material, political and technical assemblages. Hence, Thrift and French (2002: 325) observe that while the lines of code provide the rules of conduct in the context of spatial processes, how this conduct manifests does not necessarily match those that are inscribed during the production of code. Since this is a bilateral relation, the same code can perform differently in different environments. In the data-driven city, computational technologies that produce data, develop as part of urban governmentality, and as I will show further, enable spatial processes that are operational as the extension of urban governmentality.

The data-driven city is thus conditioned and performed along the lines of transindividuation of data and infrastructure into data/infrastructure. As Dodge (2010) notes, code brings city into being in particular ways due to its technicity; here, I suggest that, similarly, data possesses technicity to bring urban and its infrastructure into being in particular ways too. However, this does not mean that the data-driven city is exclusively the combination of data technologies and infrastructure; instead, it’s becoming takes place within a larger network of diverse realities and latent potentials that might be geographical, political, economic, affective and cultural (Mackenzie, 2002). Therefore, individuation of an entity (i.e. data and infrastructure) can only be a partial solution to a relational problem in a transductive domain (i.e. data-driven city):

Individuation must therefore be thought of as a partial and relative resolution manifested in a system that contains latent potentials and harbors a certain incompatibility with itself, an incompatibility due at once to forces in tension as well as to the impossibility of interaction between terms of extremely disparate dimensions. (Simondon, 1992: 300)

As such, data solves relational problems while transducing the infrastructural space. However, with each proposed solution to a problem, there emerges another relational problem that requires more and new data practices. Transduction of data and infrastructure generates new relational problems pertaining to different domains of urban life that require more data technologies to be implemented onto urban realm. For Simondon (2007), this process is the condition of technical progress (which should be thought as distinct from human progress).

It is nonetheless important to note that transductions do not occur in a technologically deterministic way; they are always underpinned by discursive practices that legitimise their production (Kitchin and Dodge, 2011: 19). Therefore, within the smart city discourses, the urban is defined through relational – not essential – problems. The urban is always associated with some larger crisis that might relate to migration, pollution, sickness, employment and so on, which are presented to require more innovation and new (data) technologies. This is why, ‘the smartness mandate’, as Halpern et al. (2017) called it, ‘understands crisis as a normal human condition and extends itself by means of a field of plural agents – environments, machines, datasets – that interact in a complex manner’ (2017: 111) whereby data-driven solutions perpetually defer the impending environmental, security and financial destruction (Halpern and Günel, 2017: 2). Thus, the very process of transduction of urban infrastructure with data becomes critical: data/infrastructure in the smart city emerges as the space to mitigate, or at least postpone these pending crises. Nevertheless, when the propagation of data/infrastructure is presented as a solution to all sorts of problems – e.g. financial, environmental, social – this is always in the way of ‘demoing’ or ‘testing’ without ever actually solving the problem they are aimed at (Halpern, et al., 2017). Because with each transduction, there emerges new problems that will be said to require new technologies.

To summarise, the concept of a data-driven city can be understood as the transductive domain for the genesis of data, software, infrastructure and the urban. Software transduces urban space; thereby it is modulated into a data generator. In return, data re-iterates the space, and/or infrastructure space, while also introducing new problems pertaining to both urban and data. That generates relational problems that require more data; but these problems will always be solved only partially. As such, data/infrastructure denotes the dyadic relation between data and infrastructure: as they transduce each other, they also mutually construct each other, in a continuously evolving way, towards no particular end. This means, data and infrastructure co-generate each other in a transductive process as a result of which they individuate, while also modulating each other as part of a larger network of diverse realities within their associated milieu.

Turning back to the main topic of this article, this relationality can be clearly observed in transport data, where the transport system is the infrastructure from which the data is extracted. Firstly, the process through which TfL opened up its data took place within a larger political and a technical context. As a result, the available transport data provided insight into London bus network. Then, built on this data, numerous transport apps emerged, and subsequently got installed on mobile phones. Then, being distributed environmentally, these apps also started to collect various types of data, which then feedback to transport systems. As we will see in the case of Citymapper, this recurrence not only reiterates infrastructure and data, but also creates new relational problems pertaining different realms of urban governmentality.

Citymapper: “Making cities usable” ¹

Founded in 2011 as a company, Citymapper’s preliminary version ‘Busmapper’ app was launched to provide bus timetable for Olympic London in 2012. Within a few years’ time the app has become a contender of Google Maps in London, ‘the ultimate transport app’, as they describe themselves on their website. ² Soon transcending London’s borders, it continued to include one by one different cities around the world; as of December 2019, it was available in 40 cities and metropolitan areas. While the exact number of users are deliberately not disclosed (Yusuf, 2016), according to Google Play app store, this app has been installed on over 10 million Android mobile phones as of June 2020. ³ Despite this worldwide success, however, London, where its headquarter is, remains a special focus and is therefore central for this analysis. Having experimented in London with operating its own transport services circa 2017 and currently offering a transport card, Citymapper Pass, as alternative to the Oyster card, ⁴ it aims to become a rival to the city’s own TfL too. Citymapper’s primary function is providing its users with information on transport options for a given destination and alerting them in the case of disruptions (Figure 1). Besides this main function, it also offers various other services dependent on data/infrastructure available in each city. Since this research focuses on Citymapper in relation to smart city making in London, the walkthrough approach used here reflects the interfaces and the services that are available in this city.

Figure 1.

Main page (screenshot May/2020).

Methodologically, to understand how Citymapper collects data in relation to users, I adapt the walkthrough method critically to identify data input points. To the contrary of the great majority of the free apps, Citymapper does not depend on in-app advertisement, neither do they sell data to third parties. For this reason, my focus here is to understand how data flows from users to Citymapper and back to users again through different ways rather than tracing data outflows to third parties. These data inputs occur when users generate data via the app's interface. Therefore, similar to Weltevrede and Jansen’s (2019) research on dating apps and their embeddedness in platform infrastructures, I document the data exchange points with the app’s interface, however, due to the different business models that these apps are built on, I deviate from their approach by not tracing data outflows through APIs. As Dieter and Tkacz (2020) note, data-centric walkthroughs usually skip screen annotations, by, instead, focusing on quantifying and categorising data input points at the expense of the experience of the screen itself. Consequently, this may result in understanding the relation between apps, data and platforms as a matter of technical issue neglecting the social values embedded in these assemblages. Similarly, Ash et al. (2017) also argue that there has been a tendency to reify and privilege algorithms, data and code as the primary site of analysis, whereas for them interfaces are ‘relational systems’ that are designed ‘to modulate user action with the aim, hope and promise of producing desirable outcomes for those that own and operate interfaces’ (p. 3). Keeping these in mind, therefore, I adapt walkthrough method to attend to the ways in which the app collects data from the users by going through the app’s interfaces systematically. As I will show, some of these data points are easily detectable as the app’s interfaces are designed in a way to invite the users to contribute to data collection rather than obfuscating it since Citymapper presents participating in data collection as a matter of ‘helping the city’. As for the data input points that are rather inconspicuous, I follow the app’s information pages on their privacy policy, terms of service and data sources.

Citymapper’s ability to do something in the world is realised through the convergence of the app’s technicity and its discursive underpinning. Therefore, besides capturing the app’s interfaces and data points, the walkthrough method I follow here includes an analysis of publicity materials (e.g. company’s own blog entries on Medium and editorials in tech periodicals such as Wired) and a video-recorded interview with the company’s founder and CEO, Azmat Yusuf, at the ‘Disrupt London’ tech-event that took place in December 2016 in London (Yusuf, 2016). Since both the company ⁵ and Azmat Yusuf ⁶ keep a low profile, these recordings provide insight into the ways in which the company leverages data analytics since Yusuf tells the story of Citymapper and the direction that the company is willing to pursue in an informal setting to audiences who are highly familiar with the app and London’s transport network.

It is not surprising that this app was created and developed in London; not only because of the availability of open transport data published by TfL, but also because, it is a city with a highly complex public transport network used by highly connected city dwellers. Due to the availability of a legible tube map, the train network is relatively easy to navigate whereas grasping the other modes of transport, such as buses, can be difficult for a long-time habitant or a tourist alike. Citymapper helps navigating this complex network as a freely downloadable app. When the user logs in their start and the end point on the opening screen, the app lists route options which are a combination of multimodal transport services (Figure 2). This includes both public transport services run by TfL and other mobility alternatives such as docked shared bikes and shared cars or private hire vehicles such as Uber. Additionally, it displays a detailed information on the total cost of each transport option and the duration they would take, as well as reporting the disruptions on each route. One of the app’s merits is its ability to appeal to users even with advanced knowledge of London’s transport network since it provides a real-time list of transport disruptions, availability of shared car docking points, and in addition to simplifying the complex bus network, it also provides information on the time left to each bus arrival at the bus stop (Figure 3).

Figure 2.

Multimodal transport options within Citymapper for a given destination (screenshot June/2020).

Figure 3.

(Left) list of disruptions on the network; (in the middle) real-time bus arrival times at the bus stop; (right) shared car dock stations (screenshot May/2020).

Becoming of Citymapper

Citymapper was never designed as an app which simply mediated bus timings but has rather considered itself as ‘designing experiences’ by showing ‘what is thought to be inaccessible suddenly becomes accessible’ (Yusuf, 2016). As Tkacz and Velasco Gonzalez (2018) argue, ‘designing experiences’ has been a key factor in bringing apps into being as well as a ‘value proposition’ in their evaluation. While experience design is a multifaceted issue, it is essentially a cognitive attempt to prompt a change or a designed outcome by acting upon users (Tkacz and Velasco Gonzalez, 2018: 33). This is also the case for Citymapper. By way of technicity of data, Citymapper becomes an infrastructure through which the users move around in their cities opting in for different modes of transport following the suggestions from the app. In this way, the app is able to facilitate spatial processes through the transduction of data/infrastructure. Moreover, as we will see, these spatial processes that Citymapper generates are always embedded in a larger network of other social and technical spheres.

When the preliminary version, Busmapper, was designed, it was one of the many apps at the time that were operating on open bus data retrieved from TfL. The distinctive property of Citymapper emerged when the app transitioned from Busmapper to the version that included virtually the entire multi-modal transport options that are available in each city. What prompted Citymapper according to its founder, Yusuf (2016), ‘was this idea that city is a place where, if you can generate multimodal options, you can change the mobility, you can change the move-around’. Now, the highly complex transport network in London could be navigated through one app linking across various transport modes available, thereby, creating ‘experiential effects of smoothness’ which make these apps and platforms indispensable for users (Leszczynski, 2019: 22). Multimodal options include docked shared bikes and cars (e.g. Uber, Zipcar, Kapten, Virtuo, Santander bikes etc.) that are digital platforms on their own account operating through their own apps. When the user sets their destination, the interface, which displays all the transport options, lists two private hire car services on top (i.e. Ola and Free Now) and once these options are selected, it allows the user to download these apps easily (Figure 4). As a result, Citymapper’s ability to facilitate spatial, economic and social processes is realised through modulating other mobility apps (and/or platforms) that are the products of their own data/infrastructure transduction. This is a nonetheless mutual relationship: Citymapper facilitates mobility platforms through which the app too increases its source of data when the users reach these platforms via the interfaces of Citymapper. This means, as well as Citymapper’s data/infrastructure transduction, its interfaces are also highly contingent on the services provided by these diverse platforms. Thus, the app’s interface is different for each city as it reflects the data/infrastructure it modulates. As will be detailed in the following section, the app generates behavioural data by tracking when these external services are accessed in-app: the infrastructure becomes its data and data becomes its infrastructure. In return, this infrastructural relationality means that Citymapper’s individuation is contingent on the availability of two aspects in each city it operates in: mobility and transport services, and the transport data.

Figure 4.

Private hire car services options and the app download option (screenshot August/2020).

‘Fixing and creating data’: Users become infrastructure

Citymapper mediates transport data it retrieves from TfL and other sources (e.g. OpenStreet Map, Google, Apple, Uber etc.) to its users, but this data flow is not unilateral. In addition to embedding multimodal transport options into the app, another source of their success is their ability to ‘fix’ and ‘create’ data as Yusuf (2016) states: Citymapper has gone beyond a design company ‘that takes up open data and design good experiences’ to cleaning (or as they refer, ‘fixing’) and even creating some of the data they use. ‘Fixing data’ is the way to repurpose and render locative media data in order to make it ‘actionable’ by creating new values and computing techniques (Perng et al., 2016). When it comes to ‘creating data’, the app achieves this by transducing its users into distributed sensing nodes (see also Krivý, 2018) that require both active and passive user participation. This happens through the interface that modulates users’ action so as to collect data on behalf of them through two options available on the screen when a certain route is selected (Ash et al., 2017) (see Figure 5). The active participation is when the users provide feedback through the tools embedded in the app’s interface: firstly, users can ‘report issues’ on their chosen route, thus, help fixing and cleaning the data as well as the routing algorithm should they encounter an issue on the route displayed by the app. Secondly, there is another function, ‘improve data’, through which users can submit the types of data Citymapper otherwise does not have access to; an action that is creating data on behalf of Citymapper. The action of ‘improving data’ is captioned as ‘help your city’.

Figure 5.

(Left) user’s choice of a route for the given destination on which ‘improve data’ and ‘report issue’ tools can be found at the bottom; (in the middle) the ‘improve data’ option; (right) the ‘report issue’ option (screenshots June/2020).

In addition to active user participation and their cleaning (i.e. ‘fixing’) and creating of data on behalf of Citymapper, the app also collects large amount of mobility and behavioural data. For some, users need to opt for in-app services to provide this, whereas the others are collected by default while the app is in use. According to the most recent privacy policy that was updated in February 2020, Citymapper processes three main types of ‘information’ from users: (1) information users provide, (2) information created when the features in the app or CM Pass are used and (3) information from third parties (Citymapper, 2020).

The first category refers to the data users create when they sign up for an account; contact and payment details when users book a cab service through the app; saved travel preferences and information on particular places such as ‘home’ and ‘work’; type of phone, service provider, location data when the users respond in-app surveys, report issues and raise queries. The second category is the default data collection by the app such as location data, which is particularly crucial in maintaining and developing the app. Depending on the users’ phone settings, this data can either be the starting and the end point, or the real time location data throughout the journey. Additionally, this category also includes how and when the app is used, what pages have been visited, as well as the data gathered by the cookies. The last category, the information from other sources, involves the data that the app collects when the users sign up for the Citymapper Pass and make bookings or payments via in-app services. As they summarise in their privacy policy, all these data (to which they refer as ‘information’) are used for various purposes such as improving the design, the functionality and the content of the app. In other words, the company uses these data to develop, fix and provide new features.

These mentioned types of data collected by Citymapper are not unusual or distinct for a navigation app. However, unlike other apps that use these data for targeted advertisement or make profit from selling them to third parties, Citymapper leverages these datasets to transduce its data/infrastructure. When the users are modulated into somewhat GPS routers or sensing nodes that generate data feeding into the app’s software within the logic of cybernetic feedback loops, they are then transduced into responsive nodes that become part of its infrastructure. Subsequently, users are modulated into what Gabrys (2016: 201) termed as ‘ambividuals’: ‘ambient and malleable urban operators that are expressions of computer environments’. In this case, the malleability manifests in the diminishing demarcation between the user, the data and the infrastructure whereby all of them are transduced to data/infrastructure. While the app started as a tool that mediated open data from TfL to its users, it now also relies on its users to maintain its data collection as the users (i.e. ‘ambividuals’) have become its distributed data infrastructure. As such, through environmental data collecting nodes, Citymapper is able to collect, analyse and leverage behavioural patterns. As Gürses et al. (2018: 1) observed, the type of data that locative technologies like Citymapper collect and store with the help of ‘ambividuals’ become an issue of optimisation – rather than an issue of user privacy – as they move from generating spatial intelligence to ‘leveraging this information to manipulate users’ behaviour and create “ideal” geographies that optimise space and time to customers’ or investors’ interests’.

Likewise, seeing the opportunity in data behaviourism, in 2017, Citymapper introduced a feature called ‘GO’ (Figure 6), which tracks the user throughout the journey and thereby records the exact transport mode chosen, including the exact bus stop the user got off. The feature also tracks whether they walked or cycled the last mile and provide a feedback to user. Through this feature, when the user chooses to walk or cycle instead of using transport, at the end of the journey, it shows the number of calories burnt in addition to the number of trees and the amount of money saved as opposed to driving a car. Thus, Citymapper also taps into self-quantification market by helping users ‘learn about themselves’. In addition, this tool tracks the user’s journey and alerts them when they need to change the transport mode or when they arrive at the right stop. Consequently, through this tool Citymapper collects real time data on the traffic thus calculates more accurate journey durations while also cumulating behavioural data on the user. Similar to Rose et al.’s (2020) observations on the smart city apps, Citymapper’s behavioural data is also built on valuing corporeal mobility: the more mobile the user, the more calories are burnt and the more trees are saved. These data are not only stored on the mobile phone but are also stored by Citymapper; in return, users can see their cumulative performance. Thus, the demarcation between the user, infrastructure and data is once again blurred as the app works to optimise all these categories by modulating each of them into any of these categories at any point. As a result of the ‘environmental–behavioural control’ (Krivý, 2018: 22) that data analytics facilitate, how urban dwellers commute becomes a political, or even a moralised issue, which in return prompts more ways of collecting data to address the problems foregrounded by data. This is one of the primary ways this app creates solutions insofar as it creates other relational problems.

Figure 6.

Citymapper’s GO feature and the cumulative user performance feedback through the feature (screenshot June/2020).

From fixing data to fixing infrastructure

Citymapper is an app that is always in-formation. Yusuf (2016) says that on top of improving cities by fixing their data, the company’s aim is now to be involved in the ‘re-planning’ of the cities. Since Citymapper does not feature targeted advertisement, nor the company sell the data they collect from their users to third parties, the app works to utilise their data/infrastructural power with a view to ‘fix the urban infrastructure’ in London (Citymapper, 2019). Following the prevailing ‘techno-scientific urban ideology’ (Brenner and Schmid, 2015), by means of the epistemological output of their data analytics, Citymapper sees its future in ‘re-planning what to do with the infrastructure’ and finding ‘better ways to utilise resources of the city, not just for transportation, but for planning the city’ (Yusuf, 2016). As Leszczynski (2016: 1692) reminds us, ‘we should further engage with modes of urban algorithmic governance and governmentality as material-discursive projects of future-ing’. Her argument resonates with Citymapper: as Yusuf (2016) concludes, ‘I think the data we have, tools we have and insight we have, can actually help us make our cities better prepared for future’. The future in question here is already being made within data/infrastructure of Citymapper (see Gabrys, 2016: 244). As the app is becoming, so is the smart city. Within the convergence of the app’s technicity and its discursive underpinning lies the infrastructural and data power of Citymapper through which the app claims ‘unique superior knowledge about the space’ (Fisher, 2020). Consequently, suggesting a superior epistemological output generated by its data/infrastructure, Citymapper is able to claim authority to build ‘an efficient London’ (Yusuf, 2016). In following this pursuit, in 2017, Citymapper started its own transport services, namely ‘smartbus’ and ‘SmartRide’ on the fixed routes that it identified as missing from TfL’s bus network despite the demand that the app identified. Seemingly, struggling with the regulatory compliance, in July 2019, the company had to drop its ‘responsive’ bus initiative as it was forced to transform into shared cabs, which, according to the company blog, is not a business model that the company is willing to pursue (Citymapper 2019). Following this, the company’s new direction was announced as ‘reinventing ticketing’ with Citymapper Pass which allows the users to travel in Zones 1 and 2 for a cheaper price than the weekly travel card Oyster offered by TfL. While these efforts have proven to be highly prone to ‘glitches’ in the sense that Leszczynski (2020) suggests, it is clear that Citymapper is working towards playing role in the planning of the cities it operates in.

Conclusion

In this article, at the intersection of critical data studies, philosophy of technology and the emerging field of ‘multi-situated app studies’ (Dieter et al., 2019), I studied the ways in which a transport app gains infrastructural power in relation to data-driven urbanism. Furthermore, the case of Citymapper provides insight into understanding both data-driven and platform urbanism as the transduction of data/infrastructure sits at the intersection of both. To this end, I explored becoming of Citymapper, which is created by the release of open data from London’s transport network within the frame of London’s smart city policies. Although this is not the only app that was created as a result of opening up transport data by the GLA, as I have shown in this article, Citymapper works to transduce its data/infrastructure in multiple ways which enabled the app to accumulate infrastructural and data power (Gerlitz et al., 2019). Consequently, within the processes of transduction of its data/infrastructure, Citymapper is not simply mediating the transport timetable, but through technicity of data, it accumulates infrastructural power while also transducing its users into environmentally distributed sensing nodes in the data-driven city (Krivý, 2018; Gabrys, 2016). Therefore, this analysis thus explored ‘when data is infrastructure’ together with ‘when infrastructure is data’.

Theoretically, I studied this transformation by constructing the relation between data and infrastructure as dyadic and co-generative and posited the term data/infrastructure by advancing Kitchin and Dodge’s (2011) conception of code/space. With this, I suggested thinking of infrastructure as data, and data as infrastructure when the data-driven city is in-formation. This relationship has enabled me to explain the ways in which Citymapper accumulated infrastructural power since the technicity pertaining to data is released through the transindividuation of data/infrastructure. By using Simondon’s processual and relational approach of individuation, it has become clear that, as data technologies unfold in urban environments, they gain infrastructural power in two ways: firstly, by modulating the urban infrastructure through technicity of data, and secondly, by becoming infrastructural themselves. This is important to understand the implications of data-driven urbanism beyond the grand narratives of multinational companies, which have been hitherto at the forefront of smart city making, thus have been studied extensively. The case of Citymapper, on the other hand, foregrounds the implications of data/infrastructure transduction in everyday socio-technical and socio-spatial modulations.

The study of transindividuation of data/infrastructure through the case of Citymapper also foregrounded in what ways the app is able to transduce its users into sensing nodes so that they help collecting data on behalf of the app. Through the app’s interfaces, users have become app’s infrastructure that generates data for its software, while the app also acts upon the users’ behaviour through technicity of data. As such, actively or passively, users’ participation in the processes of data/infrastructure emerges as essential to the app’s successful development. Consequently, Citymapper is no longer a transport app that mediates open data on bus timings but rather is increasingly embedded in other socio-technical domains that include digital platforms.

Lastly, we have seen that, through its infrastructural and data power, Citymapper is now able to claim an epistemological superiority, and thereby nominates itself as the organisation to ‘replan’ the future of London so as to make it ‘usable’. Against the backdrop of the dominant socio-technical paradigm that tends to see cities as computers, their advancement of data analytics led tech companies designate themselves as the most apt urban planners (see Mattern, 2017a). However, the epistemological superiority attributed to digital data has many adverse political, social and technical consequences as it usually takes place at the expense of other types of epistemologies that are not digitally encoded but are essential nonetheless. Subsequently, the way Citymapper constructs relation between its data power and infrastructural power is not comprehensive but rather is one dimensional and simplistic that does not take into account the social and cultural complexities of urban life that cannot be captured by digital data analytics.