Autark: A Serverless Toolkit for Prototyping Urban Visual Analytics Systems

Autark: A Serverless Toolkit for Prototyping Urban Visual Analytics Systems

arXiv:2604.20759v1 [cs.HC] 22 Apr 2026

Lucas Alexandre, João Rulff , Talisson Souza, Gustavo Moreira , Daniel de Oliveira Claudio Silva , Fabio Miranda , and Marcos Lage

,

Fig. 1: Urbane [22] is an urban visual analytics system that supports multi-resolution exploration. It enables users to characterize urban areas based on data and identify sites for new development at the neighborhood and building levels. This Figure illustrates a remake of Urbane using Autark. (A) On initialization, the system fetches OpenStreetMap data and computes sky exposure values via the GPU. It also loads the Manhattan neighborhood GeoJSON and CSV files containing thematic data, such as arrests and noise complaints, and joins them to the neighborhood polygons. (B) Users can define weights for each attribute to compute a score in real-time using the GPU. A choropleth map, a parallel coordinates chart, and a table allow users to explore data distributions and perform interactive multi-attribute filtering. Selecting a neighborhood triggers a drill-down to the building level. (C) At the building level, the system joins all datasets to the building footprints within the selected neighborhood. The 3D map displays buildings color-coded by thematic data or scores. Users can identify sites of interest using the same linked and interactive visualizations available at the neighborhood level. Abstract—The development of visual analytics (VA) systems has traditionally been a labor-intensive process, balancing design methodologies with complex software engineering practices. In domain-specific fields like urban VA, this challenge is amplified by heterogeneous data streams and a reliance on complex, multi-service architectures that hinder fast development, deployment, and reproducibility. Despite the richness of the urban VA literature, the field lacks a consolidated toolkit that encapsulates the core components of these systems, such as spatial data management, analytical processing, and visualization, into a unified, lightweight framework. In this paper, we introduce Autark, a serverless toolkit designed for the rapid prototyping of urban VA systems. Autark provides domain-aware abstractions through a self-contained architecture, enabling researchers to transition from design intention to deployed, shareable systems within hours. Furthermore, Autark’s structured, tightly scoped interfaces make it well-suited for AI-assisted coding workflows, where LLMs produce more reliable code when composing from well-defined abstractions rather than generating complex solutions from scratch. Our contributions are: (1) the Autark toolkit, a serverless architecture for rapid prototyping of urban VA; (2) a comparative study of LLM coding effectiveness with and without Autark; and (3) a series of usage scenarios demonstrating its capability to streamline the creation of robust, shareable urban VA prototypes. Autark is available at https://autarkjs.org/ Index Terms—Urban visual analytics, Urban analytics, Urban data, Visualization toolkit

1

I NTRODUCTION

The creation of visual analytics (VA) systems is at the cornerstone of visualization as a field. Over the past decades, hundreds of systems have been proposed tackling domains, data, and problems as diverse as biological pathways [45] and transportation routing [27]. Given that • Alexandre, Souza, de Oliveira, and Lage are with Universidade Federal Fluminense. E-mail: {danielcmo,mlage}@ic.uff.br • Rulff and Silva are with New York University. E-mail: {jlrulff,csilva}@nyu.edu • Moreira and Miranda are with the University of Illinois Chicago. E-mail: {gmorei3,fabiom}@uic.edu Manuscript received xx xxx. 202x; accepted xx xxx. 202x. Date of Publication xx xxx. 202x; date of current version xx xxx. 202x. For information on obtaining reprints of this article, please send e-mail to: [email protected]. Digital Object Identifier: xx.xxxx/TVCG.202x.xxxxxxx

one of the main objectives is a software artifact, this creation process is not only guided by design methodologies [44, 50], but also heavily influenced by software engineering practices and tools. This software engineering dimension has been shaped by the tools available to visualization researchers. Visualization libraries [14], grammars [49], knowledge bases [42], and collaborative canvases [12] have each redefined what it means to prototype a VA system: how fast an idea can be instantiated, validated with users, and discarded or refined. Today, we are in the midst of what may be the most disruptive such shift yet: the rise of large language models (LLMs) and AI-assisted coding. Tools and services have fundamentally altered the programmer’s autonomy, compressing the distance between a design intention and a working implementation. AI-assisted coding qualitatively changes what a single researcher can sustain alone; components that once required hours of careful engineering can now be generated and adapted much faster,

shifting the bottleneck from writing code to specifying intent. Yet, this new generative capability also surfaces new structural challenges, as LLMs produce more reliable code when composing from well-defined, reusable abstractions rather than generating complex solutions from scratch [52]. A promising strategy is to then provide well-scoped software libraries that encapsulate complex low-level implementations into high-level abstractions that can be reused to build systems. This approach carries a dual benefit. On one hand, consistent conventions and narrow interfaces reduce the search space an LLM must navigate, leading to more predictable and correct code generation. On the other hand, the same structure serves human developers: codebases built on coherent abstractions are easier to read, verify, and extend, a property that becomes critical in agentic workflows, where a developer must inspect and maintain code they did not write themselves. The visualization community has long proposed general and reusable toolkits [14,28], frameworks [13], and component libraries [57] that encapsulate analytical, rendering, and interaction logic. This approach of structured abstraction has, over time, lowered the barriers to visualization prototyping, with users assembling visualizations and systems from known primitives rather than writing from scratch, which is precisely the mode of development in which AI-assisted coding thrives [52]. These general libraries, however expressive, leave a gap for domainspecific tasks, as their data types, analytical pipelines, and visualization encodings fall outside any general approach. Urban VA is a particularly salient case. Cities generate heterogeneous data streams from trajectories, point-of-interest distributions, real-time sensor feeds, etc, each carrying its own spatial scale, temporal resolution, and analytical constraints [10]. Building VA systems on such data requires not only specific rendering capabilities but also a coherent set of domain abstractions: data loaders, spatial operators, and coordinated views tied to the urban data and the problem at hand. Despite the richness of the urban VA literature [20] and several targeted contributions [37], the field lacks a consolidated, reusable toolkit for rapid prototyping, leaving researchers to reassemble the same foundational components with each new project, often leading to complex architectures where multiple disconnected components handle data ingestion, spatial aggregation, and queries, instead of lightweight, unified architectures that lower deployment overhead and improve reproducibility. While effective at scale, this pattern has become the default, even for research prototypes where scalability might not be the primary concern. The result is a growing body of systems that are difficult to reproduce, share, or maintain; prototypes that carry their own infrastructure dependencies, deployment steps, and operational overhead that rarely survive beyond the life of the project [24, 61]. The aforementioned convergence of AI-assisted coding, library development, and simplified architectures opens a new design space for urban VA prototyping, enabling us to quickly move from intention to a deployed, shareable system within hours rather than weeks. Realizing this potential, however, requires the necessary tooling that is simultaneously domain-aware, lightweight, and structured to leverage AI-assisted workflows. To realize this opportunity, we present Autark, a serverless toolkit for rapid prototyping of urban visual analytics systems, designed around these three principles. Autark integrates the core components of urban visual analytics systems into a high-level, structured, and unified codebase. By consolidating essential components, such as spatial data management, parallel computing, and multi-scale visualization into a cohesive framework, Autark simplifies prototyping and experimentation. This integration allows developers and researchers to focus on defining analytical goals and interaction logic rather than managing complex multi-service infrastructures, while also providing developers and LLMs with a structured context environment to generate more reliable, higher-quality code to support development. The contributions of this paper are threefold. (1) We first introduce the Autark toolkit, highlighting the advantages and limitations of its serverless architecture. (2) We then present a set of usage scenarios implemented with Autark of systems that would traditionally be implemented using more complex architectures. (3) Lastly, we provide a comparative evaluation of agentic system development with and without Autark, demonstrating the benefits of domain-specific abstractions for AI-assisted development.

2

R ELATED W ORK

Urban visual analytics systems: Urban VA systems have been developed across a wide range of data domains, including human mobility [9], noise pollution [48], environmental simulations [16], public safety [26], and energy consumption [47]. Despite this diversity, these systems share the requirement for a non-trivial combination of sophisticated modules responsible for tasks such as data management, interactive visualization, and analytical processing. TaxiVis [23], a foundational work on urban VA, exemplifies this complexity. To enable the interactive exploration of a massive dataset of taxi trips, the system requires a custom storage manager for efficient spatiotemporal retrieval, a visual query module, and multiple linked views, including maps with adaptive level-of-detail, heatmap overlays, scatterplots, and time series. These systems become even more complex when three-dimensional data is required. Urbane [22], for instance, was designed to support architects in evaluating the impact of new building developments in NYC. It integrates 2D and 3D data layers across components responsible for tasks such as impact analysis, landmark visibility, and sky exposure. Miranda et al. [37] conducted a comprehensive survey of visual analytics for 3D urban data, covering applications including sunlight access, wind simulation, flood management, and view impact analysis. Their survey reveals that these systems must address challenges such as occlusion from dense geometry [19], navigation across spatial scales [15], and integrating volumetric simulation outputs with the physical built environment [56]. These additional demands compound the integration burden, requiring yet more specialized modules and further increasing the complexity of system development. Recent studies have introduced systematic methods for characterizing system complexity. Ferreira et al. [21] developed VA-Blueprint, a methodology for extracting and organizing visual analytics components from research papers. Their analysis reveals that a typical urban VA system comprises 25 distinct components, and this complexity has been growing over time. These findings empirically demonstrate that building urban VA systems requires designing and integrating many specialized modules rather than just assembling standard parts. Tools for urban VA systems development: Traditionally, GIS platforms, such as ArcGIS [11] and QGIS [43], have been the default tool for urban data analysis. Their monolithic design, however, hinders the development of new custom interactive systems, making them improper for the rapid prototyping cycles of visualization research [61], where researchers need to experiment with different visualization designs, data processing techniques, and interaction mechanisms. More recently, multiple web-based tools and libraries [2, 3, 5, 6] have begun to address this limitation, offering modular, customizable building blocks for various components of a VA system. Deck.gl [1] and Mapbox [4] are geospatial visualization libraries providing layer-based spatial rendering capabilities. Moreover, general-purpose visualization grammars, such as Vega-lite [49], support geographic projections and mark types, thereby enabling the declarative specification of spatial visualizations. Tailored to urban use cases, Urban Toolkit [39] proposes a grammar-based framework that integrates thematic and physical data layers across multiple spatial scales using a client-server architecture. Interactive Urban VA also demands efficient data management techniques, particularly as datasets grow very large and span heterogeneous spatial and temporal scales. Early systems such as imMens [32], Nanocubes [31], and Falcon [41] introduced precomputed data structures for scalable interaction with large spatiotemporal datasets. More recently, Mosaic [29] and its selection model [30] provide an architecture that facilitates linking interactive views by constructing preaggregated data views, enabling low-latency cross-filtering. The technology behind Mosaic is DuckDB [46], which offers a WebAssembly variant that enables flexible deployment in web browsers and computational notebooks. In general, these data management tools are agnostic to urban-specific challenges and operations, such as heterogeneous geometries and physical urban layers, such as spatial joins between thematic data and building footprints. Autark addresses these gaps by consolidating spatial data management, GPU-accelerated computation, 3D map visualization, and abstract charts into a single serverless toolkit that runs entirely in the browser.

LLM in VA system development: Enabling users to author VA system modules in natural language has long been a major goal in the visualization community. Early efforts [25, 53] relied on classical natural language processing techniques, such as rule-based methods and probabilistic grammars [51], while Flowsense [58] employed semantic parsing to assist users in building visual dataflows. While successful in translating natural language into visual artifacts, these approaches were limited to predefined visualization types. The emergence of LLMs has dramatically expanded what is achievable with natural language. Systems such as Urbanite [38], Chat2VIS [33], LIDA [17], and ChartGPT [54] have demonstrated that LLMs are a promising avenue for automating visualization generation from free-form descriptions. This capability extends to more challenging scenarios: ChatVis [34] generates complete ParaView [7] scripts for 3D scientific visualization workflows, and NLI4VolVis [8] enables real-time exploration and semantic editing of volumetric scenes using natural language. More recently, researchers have begun leveraging LLMs not only to generate individual visual artifacts but also to orchestrate entire VA systems. LightVA [60] decomposes high-level analytical goals into executable subtasks to facilitate coordinated visualizations, while Data-to-Dashboard [59] automates end-to-end pipelines from raw data to interactive dashboards using modular agents that iterate and reflect on their decisions. A fully general framework, however, capable of assembling VA systems across arbitrary domains may be impractical, as each domain brings its particularities. Autark fills the gap for a domain-specific tool that encapsulates most of the operations commonly needed to build urban VA systems, thereby not only supporting developers with a structured framework for defining their systems but also narrowing the design space the LLM must navigate to produce more robust and uniform VA systems. 3

D ESIGN P RINCIPLES

Lessons from urban VA development landscape: Building VA systems for urban data presents multifaceted challenges arising from the intrinsic complexity of urban datasets, the architectural demands of such systems, the heterogeneous nature of their development ecosystem, and the high barriers to collaboration. All of these challenges shaped the design of Autark. Cities generate heterogeneous data streams, trajectories, sensor feeds, and environmental simulations, each carrying its own spatial scale, temporal resolution, and format, often reaching massive volumes [10]. Despite the richness of the urban VA literature [20, 37], the field lacks a consolidated toolkit for rapid prototyping, leaving researchers to reassemble the same foundational components with each new project. General-purpose visualization libraries [14, 49], however expressive, leave a gap for domain-specific tasks whose data types, analytical pipelines, and visualization encodings fall outside any general approach. This gap motivates a design that must target the recurring data types, spatial scales, and analytical patterns that characterize urban VA (Urban-specific), providing self-contained components that encode domain operations, such as spatial operations across multivariate data types, such as physical and thematic data, rather than requiring researchers to assemble these primitives from scratch. From an architectural viewpoint, state-of-the-art urban visual analytics platforms typically integrate distinct modules for data ingestion and management, scalable computation and analytics, and both spatial and abstract visualizations [18, 37]. The orchestration of these modules may face different challenges depending on the adopted system architecture (e.g., clientserver, microservices, etc.). For example, client-server architectures, widely used in web application development, must address challenges such as data transfer latency, state synchronization across distributed nodes, real-time performance during user interactions, and end-to-end security, particularly for sensitive urban datasets subject to privacy regulations. These complex development infrastructures directly impact the practical results of urban VA systems. System deployment often becomes a difficult task that requires containerization and other specialized technologies, making tools hard to maintain and use. A toolkit designed to dissolve this overhead must propose a uniform architecture that facilitates distribution and reproducibility without requiring complex communication between heterogeneous services with different infrastructure requirements (Web-first). Autark’s serverless architec-

ture is directly inspired by this observation. Its web-first stack, relying on WebAssembly and WebGPU, can be deployed as a static collection of modules, making systems inherently shareable and reproducible without environment configuration. The design process of VA systems benefits from the ability to isolate and evaluate individual components independently, much like ablation studies. Replacing a spatial join strategy, swapping a rendering layer, or testing an alternative interaction model should not require restructuring the entire system. In practice, however, the tightly coupled architectures common in urban VA make such targeted experimentation difficult, discouraging exploration and creating barriers to collaboration with domain experts [40], who cannot easily test ideas on isolated parts of the system. This motivates a design structured as a collection of loosely coupled, composable components with well-defined responsibilities and consistent interfaces (Component-oriented). Researchers can adopt individual components without committing to the full toolkit, and swap them as requirements evolve without cascading changes. Lessons from agentic VA development: Employing LLMs in the construction of urban VA systems has the potential to mitigate the challenges previously outlined, particularly by accelerating prototyping, bridging expertise gaps, and streamlining the use of heterogeneous development ecosystems. In fact, LLMs can efficiently generate boilerplate code, support API definition, improve code quality, and aid debugging, among other benefits. However, to fully exploit these benefits requires thorough context engineering, the deliberate curation of instructions that explicitly define the LLM’s expected outputs, constraints, and success criteria. Calibrating the volume of information provided in the context is fundamental, as concise contexts yield outputs that fail to meet user goals, while large ones induce hallucinations due to diluted attention to key details. In the context of urban visual analytics systems, one possible approach is to include general-purpose libraries useful for building these systems (e.g., spatial indexing libraries such as DuckDB, rendering frameworks such as Three.js, visualization libraries such as D3.js, or analytics tools such as scikit-learn) within the LLM. However, integrating several low-level libraries into the LLM context significantly increases token consumption and operational costs. This approach often results in a large, generic context that fails to capture domain-specific requirements or optimize code structures, ultimately reducing the LLM’s effectiveness while increasing system maintenance costs. Thus, the Autark’s APIs were designed to be structured and narrow, reducing the surface area an LLM must reason over (LLM-ready). Each component is documented with explicit contracts that can be included directly in a prompt context, benefiting both AI agents and human developers who must inspect and maintain code they did not write. Reflecting on our experience designing urban VA systems [22, 23, 36, 39, 40, 48] and surveying the field [20, 37], we observe that the ambition of a design idea is rarely the bottleneck; the operational overhead of realizing it is. With Autark, our philosophy is that a toolkit should dissolve this overhead rather than manage it, allowing researchers to focus entirely on the design problem at hand. 4

T HE AUTARK TOOLKIT

Autark is a toolkit designed to streamline the prototyping of urban VA systems through a serverless architecture that executes entirely in the web browser. What makes its modules composable, both for human developers and for agentic workflows, is a programming model that governs how all components communicate. We first describe this model, as it provides the conceptual foundation for understanding each module’s design. We then present Autark’s components, illustrated in Figure 2: a spatial database that provides in-browser relational storage and querying of heterogeneous urban datasets built over DuckDB; a GPU compute engine built using WebGPU that executes analytical operations in parallel across geographic features; a 3D map view that renders vector and raster spatial data also using WebGPU; and an abstract charts library that provides visualizations built using D3.js. 4.1

A unified model for data and interaction in urban VA

Urban VA systems require two features to work in tandem: a coherent strategy for integrating heterogeneous data streams across spatial scales

Feature (f): {

(g) , [ 0.123, 543 ,.... ] (A) , 01734 (id) {

Perimeter

Area

Spatial Database

3D Map

Compute Engine

Abstract Charts

(Collection)

(Selection)

(Hybrid)

Fig. 2: Autark’s serverless architecture. The toolkit comprises four independent modules that can be freely combined via their APIs. It uses feature collections C and selections S in accordance with the feature-centric model. The image shows the data that flows through each connection. Hybrid connections exchange either collections or selections, depending on the direction of flow.

and formats, and a mechanism for coordinating interactions across multiple linked views. Both problems in the urban setting can naturally be reduced to a common solution: geographical features describing the urban environment. Urban data, regardless of its origin, can be expressed as a collection of features with associated properties, and user interactions, regardless of their visual form, can be expressed as selections over those same features. Autark takes this observation as the foundation of its architecture model, making the geographical feature the atomic unit of the entire toolkit. In most urban VA toolkits, data, rendering, and interaction each operate at different levels of abstraction: a database returns rows, a renderer consumes buffers, and an interaction produces a pixel coordinate or a bounding box. Autark collapses these into a single level: everything operates on features. In Autark, a spatial database ingests heterogeneous urban data and exports it as a feature collection; a compute engine executes analytical operations across features and writes results back as new feature properties; a map component renders each feature’s geometry; and a chart component binds to feature properties. In this model, the developer’s effort to convert, reshape, or transfer data between components is minimized; instead, they reason about features and feature collections, and the toolkit ensures that every component understands the data. We define this design as the feature-centric model for urban VA. This model’s central claim is that the complexity of urban VA systems often arises from a single architectural mismatch: data and interaction operate at different levels of abstraction. This mismatch is visible in the most influential VA programming models. In Vega-Lite, data is a flat array of tuples and interaction is expressed as a selection predicate that filters those tuples, a clean model for statistical visualization, but one that has no notion of geographic identity. In Mosaic, interaction is expressed as filtering predicates that translate user actions into SQL query constraints, but spatial selections must be expressed as a geometric predicate rather than as a reference to the features themselves. deck.gl moves closer to a feature-centric model by organizing data into layers that can operate directly on features. However, this consistency does not extend across the full system: the base map in deck.gl is a tile layer that has no notion of features, so a building in a layer and the geometry underneath it are fundamentally two different kinds of objects. In each case, the same translation layer reappears: between the data representation and the geographical entity, between the interaction event and the data it refers to, or both. Autark avoids this by treating all data, including coastlines, streets, and buildings, as the same collection of features that drive computation and interaction. There is no base map, no tile layer, and no boundary at which the feature abstraction breaks down: the same primitive flows from data ingestion to rendering to interaction. In Autark, a feature f = (g, A, id) is a triple consisting of a geometry g, a set of named

thematic attributes A = {a1 , a2 , ..., an } and a unique identifier id. For example, a building is a feature whose geometry g is a polygon footprint, and whose attributes A may include height and year that it was built. A collection C = { f1 , f2 , ..., fn } is a set of features that serves as the unit of exchange between all modules. A selection S ⊆ {id| fid ∈ C} is a subset of feature identifiers drawn from a collection. The model then supports two classes of operations, both defined over these primitives. A data operation δ : C → C takes a collection and returns a collection that may be filtered, enriched, aggregated or transformed, but keeping the representation of features as the unit of output. An interaction operation i : C × E → S takes a collection C and a user event E (e.g., a click or a brush gesture) and returns a selection, i.e., the subset of feature identifiers S from C targeted by the user. Because both operations are defined over the same primitives, no translation is needed: a selection S produced by an interaction in one view can be applied directly to any collection C in any other view that shares the same identifier space. This model offers three concrete advantages. First, it is semantically natural: a selected neighborhood is always a neighborhood, not an index into a buffer, not a row identifier in a result set, not a bounding box in pixel space, and developers reason about the same objects at every stage of the pipeline, from querying to computing to rendering to interacting. Second, it is composable: components can be freely combined because they share not just a data format but a common vocabulary for what the data means. Third, it aligns naturally with how urban data is sourced in practice: the two most common sources of urban physical layer data, OpenStreetMap and GeoJSON, both organize their content as collections of geographical features. This uniformity extends to non-spatial sources: when tabular data is ingested, Autark can join it to existing spatial features, so that all modules operate on the same feature-centric representation regardless of the original format. Next, we describe how this model is operationalized in practice using Autark’s components, each of which implements a subset of operations over a shared feature space. 4.2

The Autark components

Autark employs a serverless architecture, written in TypeScript, that executes entirely in the browser, eliminating backend dependencies and making deployment and distribution straightforward. As illustrated in Figure 2, Autark is composed of four core modules: a spatial database (Section 4.2.1), a general-purpose GPU compute engine (Section 4.2.2), a 3D map viewer (Section 4.2.3), and a collection of abstract charts (Section 4.2.4). All modules are designed as standalone components and can be composed to handle complex usage scenarios. No centralized broker is required to orchestrate data exchanges between components. Components communicate via feature collections, the common communication protocol in Autark. 4.2.1

Spatial database

The spatial database module is the entry point of the feature-centric model. It provides in-browser relational storage and querying powered by DuckDB (compiled to WebAssembly), ingests heterogeneous urban datasets, and exports them as a collection of features C, the shared primitive that all downstream modules operate on. In terms of the model’s operations, the module is responsible for two tasks: constructing C from raw urban data sources and implementing data operations δ : C → C that filter, join, and aggregate features while preserving the features as the output units. Data injection: The spatial database module fetches and parses coastlines, parks, water bodies, streets, and buildings directly from OpenStreetMap. It relies on the OverpassAPI1 , which supports retrieval of up to 10 million elements filtered by location, object type, tags, proximity, and other criteria. Once fetched, each data layer is stored in an individual DuckDB table with appropriate spatial indexing. After instantiating and initializing the database, to fetch OSM data, the user must define the base search area, the regions to load (e.g., neighborhoods), the output table name, the coordinate format, and the layers to extract. The following example loads all layers of Manhattan Island. 1 https://overpass-turbo.eu/

const db = new AutkSpatialDb(); await db.init(); await db.loadOsmFromOverpassApi({ queryArea: { search: 'New York', load: ['Manhattan Island'] }, outputTableName: 'table_osm', autoLoadLayers: { projection: 'EPSG:3395', layers: ['surface', 'parks', 'water', 'roads', 'buildings'] } });

The module can also load vector data (polylines and polygon sets) provided as GeoJSON, thematic urban data (point sets) in CSV, and raster data (imagery and heatmaps), accommodating both discrete data and continuous spatial fields in GeoTIFF. Spatial and OLAP queries: Once ingested, the module supports data operations δ : C → C that filter, enrich, and reshape the collection without ever breaking the feature as the unit of representation. Linking urban datasets is essential in visual analytics for hypothesis testing, such as correlating incident reports with nearby street infrastructure. To support this, the spatial database module provides spatial joins (features within polygons) and nearest neighbor queries (features within a search radius), both with user-defined predicate functions for aggregation. await db.spatialQuery({ tableRootName: 'neighborhoods', tableJoinName: 'noise', spatialPredicate: 'JOIN', // 'JOIN', 'NEAREST' groupBy: { selectColumns: [ { resultField: 'noise', column: 'noise_key', aggregateFn: 'count' // 'count', 'min', 'max', 'avg' } ] } });

In exploratory tasks, the core data dimensions (i.e., spatial location, attribute values or event types, and timestamps) form a triad (where–what–when) where combining any two typically reveals patterns in the third [23]. For this reason, Autark supports general queries for filtering by location (where), filtering and aggregating by attributes or categories (what), and slicing or grouping across time-varying datasets (when). 4.2.2 GPU compute engine The GPU compute engine also implements the data operation δ : C → C in the feature-centric model. It takes a collection as input, executes analytical or render-based operations in parallel across its features on the GPU, and returns an enriched collection in which each feature carries new computed properties alongside its original attributes. Urban visual analytics workflows typically require this kind of enrichment, combining physical layer features, such as street network segments, with derived thematic values, such as accumulated shadow durations or building visibility scores. The compute engine abstracts low-level WebGPU configuration details, providing a higher-level interface for data binding and shader definition, allowing users to focus on computation logic rather than GPU boilerplate. Compute programs: The compute engine takes a feature collection C as input. Each feature is mapped to a record in a data buffer consumed by a shader program, which is executed in parallel on the GPU. The metadata associated with each feature is explicitly bound to shader variables. A full execution of the engine produces one (or a list of) output values per feature, which is then written back into the original structure as an additional attribute field, returning an enriched collection that preserves every feature and its original properties while extending each with the computed result. The user supplies the analytical (from simple attribute transformations to complex domain-specific computations) or render-based logic (e.g., pixel counting for feature identification)

as a WGSL code fragment that is injected into the shader, while the engine manages compilation, dispatch, and synchronization of GPU workloads. This design supports straightforward shader definition and rapid experimentation with analytical models The following example illustrates a simple computation that calculates the volume of each building and writes the result as a new feature property. const cp = new AutkComputeEngine(); const enriched = await cp.analytical({ collection, // input feature collection variableMapping: { x: 'area', y: 'height', }, resultField: 'volume', wgslBody: 'return x * y;' });

4.2.3

3D map visualization

The 3D map module operationalizes two roles in the feature-centric model. As a renderer, it consumes a collection C and maps each feature’s geometry and attributes to visual encodings on screen. As an interaction surface, it implements the operation i : C × E → S: user events trigger a picking operation that identifies the targeted features and emits a selection S of their identifiers, which any other module can consume to drive coordinated updates. Unlike traditional tiled mapping libraries, which treat the map as a collection of pre-rendered layers without providing access to the underlying data, Autark renders all geometry (e.g., coastlines, streets, buildings, and thematic overlays) from the same feature collections that drive computation and interaction, so the feature abstraction is never broken at the rendering boundary. The map module accepts data in GeoJSON and GeoTIFF formats, loaded either from files or from the spatial database module. const collection = ...; // input feature collection const map = new AutkMap(canvas); await map.init(); map.loadCollection('neighborhoods', collection); map.draw();

Once loaded, all data (point sets, polylines, polygons, and raster data) are represented as triangle meshes, ensuring a consistent, fast rendering pipeline regardless of the underlying geometry. The viewer renders layers sequentially according to their loading order, enabling a multilayered composition of heterogeneous data. Data encoding and map styling: The map visualization module enables mapping feature attributes or aggregated thematic data (e.g. generated through the spatial database module), directly to the layer’s color channel. This supports the creation of visualizations such as heatmaps and choropleth maps, and enables visual representation of dynamic highlighting via brushing operations across coordinated views. const collection = ...; // input feature collection map.updateThematic('neighborhoods', collection, (f: Feature) => { return f.properties.sjoin.count.noise; };);

The module also allows users to define custom themes by specifying color styles for each layer, supporting both neutral palettes (e.g., for background context) and saturated schemes (e.g., for emphasizing layers of interest). Feature-Level interactivity: Any layer can be configured to listen to interactions, triggering a picking operation that identifies the selected features by their identifiers. The module then fires an event E carrying the resulting selection S, which other modules can capture through an event-driven architecture. In the example shown in Figure 3, selecting a neighborhood on the map (Palais Royal, Paris, in red) immediately highlights its corresponding data point in the scatter plot. This bidirectional flow ensures that selections made on the map trigger real-time updates in abstract charts, while interactions within those charts can, in turn, signal the map to highlight specific geographic features.

The previous example shows how to register a callback that receives the identifiers of the selected features when a click event occurs. Because S is a set of feature identifiers drawn from the shared collection, it can be applied directly to the map, or to any other module, without translation. 5

Fig. 3: Autark’s map and abstract charts modules facilitate the implementation of linked visualizations. Features selected on the map or brushed in the charts emit events containing selections (S) that other visualizations can react to. In this example, a map of Paris neighborhoods is joined with a city-wide bike station dataset. A scatter plot displaying station capacity versus availability ratio allows users to identify neighborhoods with high capacity but low availability, which are highlighted on the map. Conversely, selecting a neighborhood on the map immediately highlights its corresponding points in the scatter plot.

// picking event callback definition map.events.addListener(MapEvent.PICKING, (selection: number[]) => { // event handler });

4.2.4

Abstract charts

The abstract charts module shares the same two roles as the 3D map in the feature-centric model: it consumes a collection C, binding directly to feature attributes for rendering, and implements the interaction operation i : C × E → S, translating user events into selections S of feature identifiers that any other module can consume. By operating directly on features and accessing feature attributes from the properties object, the module eliminates the need for data format transformation and keeps a single source for both spatial and abstract visualizations. Autark provides multiple chart types (bar charts, scatterplots, line charts, parallel coordinates, etc.), selected based on the most commonly used chart types in the Urban VA literature. const plot = new AutkChart(plotDiv, { type: 'barchart' collection, // input feature collection labels: { axis: ['name', 'area'], title: 'Neighborhoods area' }, events: [PlotEvent.CLICK] });

Extensibility: The library enables custom visualizations through a single draw method, within which the developer defines the mapping between feature attributes and visual elements using standard D3.js code and data join patterns. This approach offers two key advantages. First, updates are handled natively. When the underlying collection changes, for instance, after a new spatial join or a GPU computation, the library automatically synchronizes the updated attributes with the existing SVG elements, since it operates on the same feature collection rather than a transformed copy. Second, developers can reuse most of their existing D3.js implementations with minimal integration overhead, as the only requirement is that visual marks store the feature(s) identifier(s) they represent. User interactions: When instantiating a chart, users can toggle between click and brush interaction modes. In click mode, the selected mark is the element that the user directly clicks. In brush mode, they are the elements in the brushed area. In both cases, the module extracts the selection S and broadcasts it using the same event-driven strategy used by the 3D map module. // click event callback definition plot.events.addListener(PlotEvent.CLICK, (selection: number[]) => { // event handler });

E VALUATION

We evaluate Autark along three dimensions. First, we present a series of usage scenarios demonstrating that Autark can achieve functionality comparable to urban VA systems traditionally built on complex, multiservice infrastructures. Second, we report performance benchmarks measuring data loading and spatial join scalability to assess the viability of a browser-based architecture for urban VA. Third, we conduct a controlled experiment comparing agent-based implementations of urban VA tasks with and without Autark to evaluate the toolkit’s impact on agentic development workflows. 5.1

Usage examples

Serverless remake of Urbane [22]: Figure 1 shows a remake of Urbane built with Autark. Urbane is a multi-resolution (neighborhood and building levels) VA system designed to support data-driven decisionmaking in urban development, enabling architects and planners to explore neighborhood characteristics across multiple integrated thematic datasets. The original system followed a client-server architecture, relying on preprocessed OSM data for the physical layers and precomputed spatial aggregations to associate thematic data with neighborhoods and buildings. In this reimplementation, all data is dynamically fetched and handled by the system using the spatial database module. OSM data containing the physical layers, a GeoJSON of Manhattan’s neighborhoods, and CSV files of the thematic data of interest are fetched by the toolkit when the system is initialized (Figure 1(A)). Once all data is loaded, we run a render-based program using the GPU compute module to estimate sky exposure, i.e., the percentage of the sky visible along the streets. Then, Autark performs spatial joins between the OSM buildings layer and the neighborhoods layer to determine which buildings belong to each region. Then, thematic and dynamically computed datasets are joined with the neighborhood layer so that each polygon is associated with its number of arrests, new buildings, trees, noise complaints, restaurants, schools, subway entrances, and the average sky exposure within its area. The loaded data can be initially explored at the neighborhood level using three visualizations (Figure 1(B)): a choropleth map, a parallel coordinates chart, and a table, built using Autark’s 3D-Map and abstract charts modules. All visualizations are linked. Once the user identifies a neighborhood of interest, the system allows them to drill down to the building level and explore the best location for their development. When the drill-down operation is triggered, the system first queries Autark’s database to select buildings within the chosen area, then joins all datasets with the building footprints using a nearest-neighbor spatial operation. The selected buildings and all their associated data can be visualized on the map using the color channel for buildings, as well as in the parallel coordinates and table visualizations previously used at the neighborhood level (Figure 1(C)). When interacting with the charts, the user can highlight the buildings that best fit their selection criteria. Since Autark also allows running code in parallel for each feature of a given layer using the General-purpose GPU computation module, we also implemented in this Urbane remake a dynamic feature score based on user-defined weights through the visual interface (Figure 1(B)). Once the user defines the weights for each attribute of interest, the system instantiates the GPU computation module and recalculates the score for each element in real time. The score computation is available at both the neighborhood and building levels. Although the system remake does not faithfully reproduce the original system, it implements all core functionalities. If compared to the original implementation, which comprised thousands of lines of code, a complex architecture, and a heterogeneous development ecosystem spanning multiple programming languages and dependencies, the Autark-based implementation achieves the same functionality in under 350 lines of code, runs entirely in the browser, relies solely on TypeScript, and is straightforward to deploy and extend. A live version of this example can be found online at https://autarkjs.org/usecases/live/urbane.html.

Fig. 4: Shadow accumulation in the Chicago Loop during the Summer Solstice (June 21), Autumnal Equinox (September 22), and Winter Solstice (December 21). Developed with Autark the built interactive system integrates linked histograms and a map view with a database of precomputed city-wide shadow data. The histogram shows the distribution of road segments by shadow duration; users can brush specific time ranges on the chart to highlight the corresponding segments in blue on the map. These spatial views show that the number of roads remaining in shadow for extended periods increases as the season progresses toward winter. To provide granular insights, the system can compute shadows cast by a user-selected building onto nearby streets. These local values are calculated in real time using a ray-casting algorithm executed by the GPU compute engine.

Accumulated shadows in Chicago: Accumulated gross shadow is a measure that quantifies the total time a specific location is in shade during a given time interval [36]. By capturing the cumulative duration of shadows across regions, this metric helps planners evaluate the impact of building developments on the environmental quality of public spaces, informing decisions about building height regulations and the preservation of sunlight access. Using Autark, we developed an application to analyze shadow patterns in the Chicago Loop during three seasonal markers (Figure 4): the summer solstice (June 21), the autumnal equinox (September 22), and the winter solstice (December 21). The workflow began by loading OpenStreetMap data layers for roads and buildings, along with the accumulated shadows dataset2 , which encodes the total daily duration of solar occlusion for each street segment across the three dates of interest. We then leveraged Autark’s spatial database module to join the shadow values with the street network data, associating each road segment with its corresponding shadow duration. Finally, we used the Autark abstract charts module to generate a histogram of the number of street segments in shadow for durations ranging from 1 to several hours per day, facilitating a seasonal comparison of urban solar access. The system utilizes Autark’s support for linked visualizations to implement a brush interaction on the histogram. As illustrated in Figure 4, an analyst can select specific time ranges to immediately identify and highlight corresponding road segments in blue on the map, enabling direct spatial inspection of the selected distribution. These coordinated views reveal a clear seasonal trend: the number of roads experiencing prolonged solar occlusion increases significantly as the year progresses toward the winter solstice. To take the analysis further, the application leverages the 3D map picking interaction and the Autark compute module to allow users to select a specific building and calculate its individual contribution to the accumulated shadows on surrounding streets. This feature, shown in the circular zoom insets in Figure 4, employs a ray-casting approach at an hourly resolution for the day of interest. More precisely, for each 20-meter road segment, the system casts a ray toward the sun at every hour; if the ray intersects the selected building, it is recorded as a potential shadow source for that segment at that time. These local values are calculated in real time, allowing analysts to interactively probe the shadow contribution of individual structures. We observe that this computation result represents a lower bound, as other structures could be positioned between the building of interest and the segment. We argue that this approach ensures the estimated contribution is never lower than reality. This example can be found online at https://autarkjs.org/usecases/live/shadows.html. 2 https://osf.io/4tqp9/overview

Heat islands in Niterói: This use case demonstrates Autark’s ability to process raster geospatial datasets. To do so, we developed an application to monitor trends in urban land temperatures. The analysis uses NASA Land Surface Temperature (LST) data covering the period from 2001 to 2024 for the city of Niterói3 . We preprocessed the original raster files to create a multi-band TIFF, with each band storing the average summer temperature (i.e., data from December, January, and February) for a specific year, resulting in a compact representation of the dataset’s full temporal extent. As illustrated in the first column of Figure 5, we first use the spatial database module of Autark to load the multi-band TIFF file and perform a spatial join between the road network and the temperature time series, enriching each street segment with a time series of summer heat values that captures its thermal history over the observation period. Next, to identify areas with increasing surface temperatures, we used Autark’s compute engine to calculate linear regressions of surface temperature values for each road segment in parallel. The regression is computed independently for each segment, taking full advantage of the GPU’s parallelism to process the entire road network simultaneously. The slope of the regression indicates the trend in temperature variation, while the intercept encodes the base temperature values and may help locate the hottest areas. In the middle column of Figure 5, we see the road network of Niterói colored by the regression slope (using a diverging scale, from blue to red). Negative slope values mean that temperatures in the region decreased from 2001 to 2024. Positive values mean that the temperature is increasing in the region. We also used the feature-picking functionality of Autark’s 3D-map module to implement a dynamically updated line chart that displays the temperature time series and the fitted regression line for segments of interest, enabling detailed investigation of localized thermal trends and specific anomalous situations. Finally, we created a scatterplot to facilitate a global exploration of heat areas over the city. The chart implements a brush interaction that allows users to highlight roads on the map based on the slope and intercept values of interest. By jointly analyzing the slope and intercept of each road segment, users can distinguish between areas that are both hot and warming from those that are warming but starting from a lower baseline. Interactively exploring the visualizations, we identified that one of the regions with the highest increases in temperature was the Piratininga neighborhood (see the last column of Figure 5), where intense urban expansion and the construction of several new buildings have occurred in recent years. A live version of this example is available at https://autarkjs.org/usecases/live/heat.html. 3 https://shorturl.at/R0G5v

Fig. 5: Analysis of urban heat trends in Niterói (2001–2024) using Autark. The system processes NASA LST raster data to enrich road segments with average summer temperature over the years (left column). Autark’s compute engine, in parallel, calculates linear regressions for each road segment to map temperature trend (slope) and base heat (intercept) across the city. Line charts showing the heat data and the regression lines for picked roads can be produced dynamically (middle column). Finally, a scatter plot showing the slope and intercept values of all roads in the city is constructed to enable global exploration of heat areas. The chart’s brushing interaction allows users to highlight areas of significant warming on the map, such as the Piratininga neighborhood, where recent urban expansion correlates with rising temperatures (right column).

5.2

Performance

Three performance experiments were conducted on an M1 Mac Studio (32GB RAM) to evaluate the feasibility of Autark’s serverless approach. The first assessed loading time by incrementally loading Manhattan neighborhood data from 1 to 10 areas (2,000–20,000 features). The second evaluated spatial join performance using 28 neighborhood polygons joined against approximately 4.5 million georeferenced 311 service records, sampled at 10% increments4 . The third evaluated GPU compute performance across approximately 11,000 segments of Manhattan’s road network. Each test was run 10 times to assess robustness. For loading time, at 20,000 features, the total time averages 6.0s (sd=460ms), with database ingestion accounting for 4.9s (sd=295ms) and 3D map data loading for 1.1s (sd=180ms), yielding a cost of ≈0.3ms per feature. For spatial joins, processing the full 4.5 million records requires, on average, 2.6s (sd=6ms), corresponding to ≈0.58µs per record. Both metrics scale linearly with dataset size, suggesting predictable behavior for larger inputs. Render-based computation test used a 6, 784 × 6, 784 target to store 11,224 tiles (64 × 64 pixels), consuming 185 MB of GPU memory and ran on average in 4.2s (sd=45ms). These results are particularly noteworthy given that Autark runs entirely in the browser, where such operations would traditionally require a backend, and that no optimizations such as data streaming were applied. Given that modern browsers can allocate several gigabytes of memory per tab, these results suggest that serverless architectures are a feasible alternative for urban visual analytics systems. 5.3

Agentic urban VA development with Autark

The development of Urban VA systems is undergoing a paradigm shift in which code is increasingly written by agents, yet the resulting codebase must remain understandable and maintainable by humans who define requirements and verify correctness. This raises a key question: how does a toolkit’s design influence the quality of agent-generated code? To investigate this, we evaluated Autark’s effectiveness through a controlled experiment comparing agent-based implementations of well-scoped urban VA systems across two conditions: one constrained to Autark’s modules and one that allowed the agent to use any generalpurpose libraries available online (baseline). Our goal was twofold: to assess whether agents could deliver functional applications in both conditions, and to evaluate the structural properties of the resulting code with respect to complexity, maintainability, and readability. 4 https://shorturl.at/HylCQ

Experimental setup: We designed five urban VA tasks of increasing complexity, each requiring a combination of data ingestion, spatial operations, and interactive visualization. The first task, the simplest, requires loading multiple OpenStreetMap Layers and coloring specific layers based on a spatially joined attribute from an external thematic dataset. Each successive task adds requirements: additional thematic datasets, multiple spatial joins, linked charts, and GPU-accelerated computations. All the tasks, prompts, and experiment results are available in the supplemental material of this paper on the GitHub5 . Each task was implemented by an AI coding agent (Claude Code with Opus 4.6 model). For both conditions, we prompted the task definition and used the same model configuration. Each trial was conducted independently, with no conversation history carried over between tasks. To ensure a fair comparison, both conditions shared the same stop criteria: after generating the project, the agent was required to validate that the system fully compiles, builds, and serves without errors. For the Autark condition, the agent was provided with Autark’s documentation as its primary context and instructed to use only Autark’s API. For the general condition, the agent was explicitly told not to use Autark to build the system. Functional issues: Our first goal in analyzing the experiments was to assess whether the generated systems behave as specified. For each task and condition, we manually inspected the output application against its functional requirements, such as layer rendering, data encoding, spatial operations, and view coordination. The first issue concerns layer representation. Without Autark, the agent frequently combines multiple mapping libraries within the same application to render different urban layers. As shown in the leftmost column of Figure 6, this results in a fragmented visual stack, with layers from different rendering libraries coexisting on the same canvas. Beyond the visual inconsistency, it introduces a functional limitation: picking operations cannot traverse libraries, making it impossible to select or interact with features on layers that are occluded by elements rendered by a different backend. Autark avoids this entirely by routing all layers through a single rendering pipeline, ensuring that picking and interaction work uniformly across the full layer stack. The second issue concerns layer processing. Autark’s spatial database module processes raw OpenStreetMap data through a unified pipeline that reconstructs semantically coherent geometries, assembling building footprints from their constituent way segments before storing them as individual features. Examples from the baseline condition lack this consolidation step. As a result, parts of the same physical structure are treated as independent geometries, 5 https://github.com/urban-toolkit/autark-experiments

Semantically-coherent layer components

Mesh Rendering

General

Autark

Non-uniform Layer Representation

Fig. 6: Comparison of agent-generated outputs between the Autark condition (top row) and the baseline (bottom row). (Left) The baseline combines multiple rendering libraries into a fragmented visual stack. (Center) The baseline treats parts of the same physical structure as independent geometries, whereas Autark reconstructs semantically coherent building footprints. (Right) The baseline produces artifacts, such as fragmented polygons, whereas Autark ensures artifact-free rendering.

as illustrated in the center column of Figure 6. This inconsistency hinders geometry-dependent computations, as thematic attributes might be assigned to parts of the layer elements, and physical properties, such as building areas, become unreliable. These processing issues also affect rendering quality. As shown in the rightmost column of Figure 6, the baseline condition produces visible mesh artifacts, such as fragmented polygons and overlapping edges that result from operating on raw, unconsolidated geometry. Autark’s unified processing pipeline reconstructs coherent geometries before rendering, ensuring that the visual output is free of such artifacts. Code generation metrics: Beyond functional correctness, we also profile the generated code to characterize its structural properties. Even in an agentic workflow, developers must be able to read, navigate, and understand the generated codebase in order to verify the agent’s design decisions. To this end, we computed multiple code metrics that serve as proxies potentially indicative of code understandability and ease of maintenance. Per-trial results are available in the supplemental material. Autark-based implementations average 153 LOC compared to 590 for the general condition and are consistently contained in a single source file, whereas the general condition spreads across 6 files on average. The general condition also introduces roughly twice as many external dependencies (6.1 vs. 3.1 on average, Autark-based code mainly imports its own modules), each of which adds API surface that the developer must understand, version constraints that must be managed, and potential points of failure that complicate debugging, all of which compound the maintenance burden of the generated codebase. Cyclomatic complexity measures the number of independent paths through a program’s control flow, serving as a widely used proxy for how difficult code is to understand and test [35]. Higher values indicate more branching logic that developers must trace when verifying correctness. Autark code averages a cyclomatic complexity of 22 compared to 84 for the general condition, indicating that the toolkit’s declarative abstractions absorb much of the branching logic that the agent must otherwise generate from low-level primitives. Taken together, these metrics suggest that Autark’s domain-specific abstractions not only reduce the volume of generated code but also produce codebases that are structurally simpler and more uniform. As demonstrated in the usage scenarios (Section 5.1), these gains do not come at the cost of expressiveness, as Autark achieves feature-parity with traditional urban VA systems while producing code that is more compact. While these proxies do not guarantee maintainability, they consistently lower the barrier for developers who need to inspect, verify, and extend the agent-generated codebase.

Fig. 7: Autark wrapper for Jupyter notebooks, illustrating how its serverless architecture facilitates integration with diverse computational environments and community standards.

6

C ONCLUSION

Community adoption: Autark’s self-contained, serverless architecture facilitates integration with diverse computational ecosystems without requiring specific development environments or deployment stacks. Figure 7 shows Autark used within a Jupyter notebook via a Python wrapper (pyautark6 ), analyzing buildings affected by noise complaints in New York’s Financial District. Beyond Jupyter, Autark is compatible with cloud-hosted platforms such as Google Colab, reactive notebook environments such as Observable [12], and WebXR platforms for immersive analytics [55]. Limitations: Autark’s serverless architecture, while effective for rapid prototyping, introduces inherent scalability constraints. The toolkit is bound by the memory and compute resources available in a single browser tab. For the datasets explored in this paper, this proved sufficient, with linear scaling behavior and interactive response times (Section 5.2). However, for terabyte-scale datasets, a browser-based approach is not a viable alternative to server-backed architectures with dedicated database infrastructure. Additionally, the set of abstract chart types currently provided by Autark was informed by a decade of experience building urban VA systems and by a thorough review of the urban VA literature, but it is not exhaustive. Autark partially addresses this by providing an extensibility mechanism that allows developers to define custom visualization code while retaining integration with the feature-centric model. A more comprehensive built-in chart library remains a direction for future work. Future work: We envision two main directions for future work. First, we plan to leverage Autark to better understand the construction of VA systems within agentic ecosystems. The evaluation presented in this paper adopted a purely agentic approach, where the agent was solely responsible for generating the entire codebase. In practice, however, the development process is more nuanced: developers may co-write code alongside agents, selectively delegate specific components, or write entire modules themselves. We plan to conduct a large-scale user study using Autark to investigate how developers interact with agents across this spectrum of collaboration, examining how toolkit design influences not only the quality of the output but also the dynamics of the human-agent development process. Second, we plan to explore integrating Autark into immersive environments. Autark’s web-first, serverless architecture is inherently compatible with WebXR, and its feature-centric model provides a natural foundation for immersive urban analytics. This direction has the potential to reduce barriers to developing immersive VA applications, which currently require substantial additional engineering effort beyond an already complex urban VA stack. 6 https://github.com/urban-toolkit/pyautark

R EFERENCES [1] deck.gl. https://deck.gl/, 2024. 2 [2] kepler.gl. https://kepler.gl/, 2024. 2 [3] Leaflet. https://leafletjs.com/, 2024. 2 [4] Mapbox GL JS. https://www.mapbox.com/mapbox-gljs, 2024. 2 [5] MapLibre GL JS. https://maplibre.org/, 2024. 2 [6] OpenLayers. https://openlayers.org/, 2024. 2 [7] J. Ahrens, B. Geveci, and C. Law. ParaView: An end-user tool for large data visualization. The Visualization Handbook, pp. 717–731, 2005. doi: 10.1016/B978-012387582-2/50038-1 3 [8] K. Ai, K. Tang, and C. Wang. NLI4VolVis: Natural language interaction for volume visualization via LLM multi-agents and editable 3D Gaussian splatting. IEEE Trans. Vis. Comput. Graph., 2025. doi: 10.1109/TVCG. 2024.3520556 3 [9] G. Andrienko, N. Andrienko, W. Chen, R. Maciejewski, and Y. Zhao. Visual analytics of mobility and transportation: State of the art and further research directions. IEEE Trans. Intell. Transp. Syst., 18(8):2232–2249, 2017. doi: 10.1109/TITS.2017.2701893 2 [10] S. Bonadia, R. Gama, D. d. Oliveira, F. Miranda, and M. Lage. Visual analytics using heterogeneous urban data. In Proc. SIBGRAPI, pp. 1–6, 2023. doi: 10.1109/SIBGRAPI59091.2023.10347156 2, 3 [11] B. Booth, A. Mitchell, et al. Getting started with ArcGIS, 2001. 2 [12] M. Bostock, M. Conlen, J. Heer, and I. Meckler. Observable: The collaborative data canvas. https://observablehq.com, 2024. Accessed: 2026-03-21. 1, 9 [13] M. Bostock and J. Heer. Protovis: A graphical toolkit for visualization. IEEE Trans. Vis. Comput. Graph., 15(6):1121–1128, 2009. doi: 10.1109/ TVCG.2009.174 2 [14] M. Bostock, V. Ogievetsky, and J. Heer. D3: Data-driven documents. IEEE Trans. Vis. Comput. Graph., 17(12):2301–2309, 2011. doi: 10.1109/ TVCG.2011.185 1, 2, 3 [15] S. Chen, F. Miranda, N. Ferreira, M. Lage, H. Doraiswamy, C. Brenner et al. UrbanRama: Navigating cities in virtual reality. IEEE Trans. Vis. Comput. Graph., 28(12):4685–4699, 2021. doi: 10.1109/TVCG.2021. 3099012 2 [16] Z. Deng, D. Weng, J. Chen, R. Liu, Z. Wang, J. Bao et al. AirVis: Visual analytics of air pollution propagation. IEEE Trans. Vis. Comput. Graph., 26(1):800–810, 2019. doi: 10.1109/TVCG.2019.2934670 2 [17] V. Dibia. LIDA: A tool for automatic generation of grammar-agnostic visualizations and infographics using large language models. In Proc. ACL, pp. 113–126, 2023. doi: 10.18653/v1/2023.acl-demo.11 3 [18] H. Doraiswamy, J. Freire, M. Lage, F. Miranda, and C. T. Silva. Spatiotemporal urban data analysis: A visual analytics perspective. IEEE Comput. Graph. Appl., 38(5):26–35, 2018. doi: 10.1109/MCG.2018.2852702 3 [19] N. Elmqvist and P. Tsigas. A taxonomy of 3D occlusion management for visualization. IEEE Trans. Vis. Comput. Graph., 14(5):1095–1109, 2008. doi: 10.1109/TVCG.2008.59 2 [20] L. Ferreira, G. Moreira, M. Hosseini, M. Lage, N. Ferreira, and F. Miranda. Assessing the landscape of toolkits, frameworks, and authoring tools for urban visual analytics systems. Comput. Graph., 123:104013, 2024. doi: 10.1016/j.cag.2024.104013 2, 3 [21] L. Ferreira, G. Moreira, and F. Miranda. VA-Blueprint: Uncovering building blocks for visual analytics system design. IEEE Trans. Vis. Comput. Graph., 2025. doi: 10.1109/TVCG.2024.3456345 2 [22] N. Ferreira, M. Lage, H. Doraiswamy, H. Vo, L. Wilson, H. Werner et al. Urbane: A 3D framework to support data driven decision making in urban development. In Proc. VAST, pp. 97–104, 2015. doi: 10.1109/VAST.2015 .7347636 1, 2, 3, 6 [23] N. Ferreira, J. Poco, H. Vo, J. Freire, and C. T. Silva. Visual exploration of big spatio-temporal urban data: A study of New York City taxi trips. IEEE Trans. Vis. Comput. Graph., 19(12):2149–2158, 2013. doi: 10.1109/ TVCG.2013.226 2, 3, 5 [24] J. Freire, P. Bonnet, and D. Shasha. Computational reproducibility: Stateof-the-art, challenges, and database research opportunities. In Proc. SIGMOD, pp. 593–596, 2012. doi: 10.1145/2213836.2213908 2 [25] T. Gao, M. Dontcheva, E. Adar, Z. Liu, and K. G. Karahalios. DataTone: Managing ambiguity in natural language interfaces for data visualization. In Proc. UIST, pp. 489–500, 2015. doi: 10.1145/2807442.2807478 3 [26] G. García-Zanabria, M. M. Raimundo, J. Poco, M. B. Nery, C. T. Silva, S. Adorno et al. CriPAV: Street-level crime patterns analysis and visualization. IEEE Trans. Vis. Comput. Graph., 28(12):4000–4015, 2021. doi: 10.1109/TVCG.2021.3111146 2

[27] H. Guo, Z. Wang, B. Yu, H. Zhao, and X. Yuan. TripVista: Triple perspective visual trajectory analytics and its application on microscopic traffic data at a road intersection. In Proc. PacificVis, pp. 163–170, 2011. doi: 10.1109/PACIFICVIS.2011.5742387 1 [28] J. Heer, S. K. Card, and J. A. Landay. Prefuse: A toolkit for interactive information visualization. In Proc. CHI, pp. 421–430, 2005. doi: 10. 1145/1054972.1055031 2 [29] J. Heer, D. Moritz, and R. Pechuk. Mosaic: An architecture for linking databases and scalable interactive visualizations. In Proc. SIGMOD, pp. 123–126, 2025. doi: 10.1145/3632410.3632420 2 [30] J. Heer, D. Moritz, and R. Pechuk. Mosaic Selections: Managing and optimizing user selections for scalable data visualization systems. IEEE Trans. Vis. Comput. Graph., 2025. doi: 10.48550/arXiv.2507.19690 2 [31] L. Lins, J. T. Klosowski, and C. Scheidegger. Nanocubes for real-time exploration of spatiotemporal datasets. IEEE Trans. Vis. Comput. Graph., 19(12):2456–2465, 2013. doi: 10.1109/TVCG.2013.179 2 [32] Z. Liu, B. Jiang, and J. Heer. imMens: Real-time visual querying of big data. In Comput. Graph. Forum, vol. 32, pp. 421–430, 2013. doi: 10. 1111/cgf.12129 2 [33] P. Maddigan and T. Susnjak. Chat2Vis: Generating data visualizations via natural language using ChatGPT, Codex and GPT-3 large language models. IEEE Access, 11:45181–45193, 2023. doi: 10.1109/ACCESS. 2023.3273215 3 [34] T. Mallick, O. Yildiz, D. Lenz, and T. Peterka. ChatVis: Automating scientific visualization with a large language model. In Proc. SC-W, pp. 49–55, 2024. doi: 10.1109/SCW63240.2024.00014 3 [35] T. J. McCabe. A complexity measure. IEEE Trans. Softw. Eng., 4:308–320, 1976. doi: 10.1109/TSE.1976.233837 9 [36] F. Miranda, H. Doraiswamy, M. Lage, L. Wilson, M. Hsieh, and C. T. Silva. Shadow Accrual Maps: Efficient accumulation of city-scale shadows over time. IEEE Trans. Vis. Comput. Graph., 25(3):1559–1574, 2019. doi: 10. 1109/TVCG.2018.2802945 3, 7 [37] F. Miranda, T. Ortner, G. Moreira, M. Hosseini, M. Vučković, F. Biljecki et al. The state of the art in visual analytics for 3D urban data. Comput. Graph. Forum, 43(3):e15112, 2024. doi: 10.1111/cgf.15112 2, 3 [38] G. Moreira, L. Ferreira, C. Veiga, M. Hosseini, and F. Miranda. Urbanite: A dataflow-based framework for human-ai interactive alignment in urban visual analytics. IEEE Trans. Vis. Comput. Graph., 32(1):1065–1075, 2026. doi: 10.1109/TVCG.2025.3634644 3 [39] G. Moreira, M. Hosseini, M. N. A. Nipu, M. Lage, N. Ferreira, and F. Miranda. The Urban Toolkit: A grammar-based framework for urban visual analytics. IEEE Trans. Vis. Comput. Graph., 30(1):1402–1412, 2023. doi: 10.1109/TVCG.2023.3326922 2, 3 [40] G. Moreira, M. Hosseini, C. Veiga, L. Alexandre, N. Colaninno, D. de Oliveira et al. Curio: A dataflow-based framework for collaborative urban visual analytics. IEEE Trans. Vis. Comput. Graph., 31(1):1224– 1234, 2025. doi: 10.1109/TVCG.2024.3456353 3 [41] D. Moritz, B. Howe, and J. Heer. Falcon: Balancing interactive latency and resolution sensitivity for scalable linked visualizations. In Proc. CHI, pp. 1–11, 2019. doi: 10.1145/3290605.3300924 2 [42] D. Moritz, C. Wang, G. L. Nelson, H. Lin, A. M. Smith, B. Howe et al. Formalizing visualization design knowledge as constraints: Actionable and extensible models in Draco. IEEE Trans. Vis. Comput. Graph., 25(1):438– 448, 2018. doi: 10.1109/TVCG.2018.2865240 1 [43] N. Moyroud and F. Portet. Introduction to QGIS. QGIS and Generic Tools, 1:1–17, 2018. doi: 10.1002/9781119439165.ch1 2 [44] T. Munzner. A nested model for visualization design and validation. IEEE Trans. Vis. Comput. Graph., 15(6):921–928, 2009. doi: 10.1109/TVCG. 2009.111 1 [45] C. Partl, A. Lex, M. Streit, D. Kalkofen, K. Kashofer, and D. Schmalstieg. enRoute: Dynamic path extraction from biological pathway maps for exploring heterogeneous experimental datasets. BMC Bioinformatics, 14(S19):S3, 2013. doi: 10.1186/1471-2105-14-S19-S3 1 [46] M. Raasveldt and H. Mühleisen. DuckDB: An embeddable analytical database. In Proc. SIGMOD, pp. 1981–1984, 2019. doi: 10.1145/3299869 .3320212 2 [47] J. Rodgers and L. Bartram. Exploring ambient and artistic visualization for residential energy use feedback. IEEE Trans. Vis. Comput. Graph., 17(12):2489–2497, 2011. doi: 10.1109/TVCG.2011.196 2 [48] J. Rulff, F. Miranda, M. Hosseini, M. Lage, M. Cartwright, G. Dove et al. Urban Rhapsody: Large-scale exploration of urban soundscapes. In Comput. Graph. Forum, vol. 41, pp. 209–221, 2022. doi: 10.1111/cgf. 14533 2, 3

[49] A. Satyanarayan, D. Moritz, K. Wongsuphasawat, and J. Heer. Vega-Lite: A grammar of interactive graphics. IEEE Trans. Vis. Comput. Graph., 23(1):341–350, 2016. doi: 10.1109/TVCG.2016.2599030 1, 2, 3 [50] M. Sedlmair, M. Meyer, and T. Munzner. Design study methodology: Reflections from the trenches and the stacks. IEEE Trans. Vis. Comput. Graph., 18(12):2431–2440, 2012. doi: 10.1109/TVCG.2012.213 1 [51] V. Setlur, S. E. Battersby, M. Tory, R. Gossweiler, and A. X. Chang. Eviza: A natural language interface for visual analysis. In Proc. UIST, pp. 365–377, 2016. doi: 10.1145/2984511.2984588 3 [52] E. Stengel-Eskin, A. Prasad, and M. Bansal. Regal: Refactoring programs to discover generalizable abstractions. arXiv preprint arXiv:2401.16467, 2024. doi: 10.48550/arXiv.2401.16467 2 [53] Y. Sun, J. Leigh, A. Johnson, and S. Lee. Articulate: A semi-automated model for translating natural language queries into meaningful visualizations. In Int. Symp. Smart Graphics, pp. 184–195, 2010. doi: 10. 1007/978-3-642-13544-6_18 3 [54] Y. Tian, W. Cui, D. Deng, X. Yi, Y. Yang, H. Zhang et al. ChartGPT: Leveraging LLMs to generate charts from abstract natural language. IEEE Trans. Vis. Comput. Graph., 31(3):1731–1745, 2024. doi: 10.1109/TVCG. 2023.3346715 3 [55] J. Wagner, C. T. Silva, W. Stuerzlinger, and L. Nedel. Reimagining TaxiVis through an immersive space-time cube metaphor. In Proc. VR, pp. 827–838, 2024. doi: 10.1109/VR58804.2024.00099 9 [56] J. Waser, A. Konev, B. Sadransky, Z. Horváth, H. Ribičić, R. Carnecky et al. Many plans: Multidimensional ensembles for visual decision support in flood management. In Comput. Graph. Forum, vol. 33, pp. 281–290, 2014. doi: 10.1111/cgf.12384 2 [57] K. Wongsuphasawat. Encodable: Configurable grammar for visualization components. In Proc. VIS, pp. 131–135, 2020. doi: 10.1109/VIS47514. 2020.00034 2 [58] B. Yu and C. T. Silva. FlowSense: A natural language interface for visual data exploration within a dataflow system. IEEE Trans. Vis. Comput. Graph., 26(1):1–11, 2019. doi: 10.1109/TVCG.2019.2934668 3 [59] R. Zhang and M. Elhamod. Data-to-dashboard: Multi-agent LLM framework for insightful visualization in enterprise analytics. arXiv preprint arXiv:2505.23695, 2025. doi: 10.48550/arXiv.2505.23695 3 [60] Y. Zhao, J. Wang, L. Xiang, X. Zhang, Z. Guo, C. Turkay et al. LightVA: Lightweight visual analytics with LLM agent-based task planning and execution. IEEE Trans. Vis. Comput. Graph., 31(9):6162–6177, 2024. doi: 10.1109/TVCG.2024.3413998 3 [61] P. Ziegler and S. E. Chasins. A need-finding study with users of geospatial data. In Proc. CHI, pp. 1–16, 2023. doi: 10.1145/3544548.3581370 2