Design and Development of a Local-First Collaborative 3D WebGIS Application for Mapping

Abstract

Real-time collaborative WebGIS represents a significant trend in the evolution of Geographic Information Systems. Current commercial collaborative WebGIS platforms, such as ArcGIS Online and Felt, rely on centralized servers for data storage and spatial analysis. However, this centralized architecture poses notable limitations: the software becomes non-functional in the absence of a network connection or if the service is discontinued. Moreover, data ownership resides with the commercial providers, exposing users to potential data loss in the event of service disruptions. To address these challenges, this paper introduces the concept of local-first software into WebGIS. By leveraging Conflict-free Replicated Data Types (CRDTs) and advanced web technologies, we develop a user-friendly, interactive, and offline-capable local-first WebGIS application that supports real-time collaboration. The application enables multi-user collaborative editing, offline functionality, and efficient browser-based spatial analysis. This paper outlines the design methodology and system prototype for the local-first WebGIS application, utilizing open-source software and libraries throughout the development process. Practical examples are provided to demonstrate the application’s functionality. The proposed solution enhances real-time collaboration and data security in WebGIS, ultimately improving user productivity and collaborative experiences.

1. Introduction

The rapid advancement of cutting-edge technologies has profoundly reshaped collaboration and data management practices, particularly within the field of Geographic Information Systems (GISs). A growing number of organizations now depend on GISs for mapping, spatial analysis, and decision-making support. Cloud-based applications have revolutionized workflows by enabling seamless collaboration and cross-device accessibility. In the GIS domain, platforms such as ArcGIS Online [1] and Felt [2], alongside tools like Google Docs and Slack in other fields, facilitate real-time editing, communication, and project management. However, despite their benefits, cloud-based GIS applications present significant challenges, particularly regarding data ownership and control. By storing data on remote servers, cloud services effectively cede control to third-party providers. This dependence on external infrastructure raises critical concerns about data security, privacy, and long-term accessibility. Should cloud services become unavailable or discontinued, users risk losing access to their data or encountering difficulties in migrating to alternative platforms. This lack of ownership is particularly concerning for individuals and organizations reliant on GIS data for critical decision-making, as they often maintain deep professional and emotional investments in their work [3].

The objective of this study is to develop a local-first 3D collaborative WebGIS application equipped with fundamental spatial analysis capabilities to enhance work efficiency and foster collaboration among users. However, constructing such an application necessitates addressing several challenges. The following sections review relevant research and projects from three primary perspectives: the concept and design of local-first software, collaborative WebGIS applications, and browser-based spatial analysis. Although research and projects at the intersection of these three domains are limited, there is a substantial body of work related to each individual domain.

The first issue is how to resolve conflicts during real-time collaboration while ensuring localization and privacy. The Ink&Switch laboratory [4] first introduced the concept of local-first software and proposed seven principles that local-first software strives to achieve. Local-first software refers to applications that support offline functionality and multi-device collaboration while also enhancing data security, privacy, long-term availability, and user control over data. The seven principles are speed, multi-device support, offline capability, collaboration, data longevity, privacy protection, and user control. Common application architectures primarily include client/server (browser/server) applications and native applications. However, local-first software can be considered a hybrid between native applications and client/server applications. Local-first software does not store data on remote servers but instead stores them on local computing devices. Ink&Switch introduced a series of distributed algorithms known as Conflict-free Replicated Data Types (CRDTs). CRDTs are regarded as foundational technologies for local-first software. CRDTs are data structures that simplify distributed data storage systems and multi-user applications [5,6,7]. They are general-purpose data structures, such as hash maps and lists, but their uniqueness lies in their inherent multi-user design. When building applications, data structures are central to storing document states. For example, the core data structure of a text editor is an array of characters and vector graphics applications rely on tree structures composed of graphical objects such as text objects, rectangles, and lines. For single-user applications, data structures like model objects, hash maps, lists, or records/structs are typically used to maintain state. However, when building collaborative multi-user applications, these data structures can be replaced with CRDTs. If states are modified simultaneously on different devices, CRDTs track all changes and synchronize them across devices. CRDTs can synchronize states through various communication channels, such as servers, peer-to-peer connections, Bluetooth, or even on a USB stick. They can track fine-grained changes (e.g., a single keystroke) or batch larger sets of changes to collaborators. Based on their CRDT implementation library, Automerge [8], Ink&Switch developed a peer-to-peer collaborative whiteboard software prototype called PushPin [9].

The second issue pertains to the design and implementation of collaborative WebGIS applications. Real-time collaborative GIS (RCGIS) provides a multi-user, real-time, and synchronous collaborative environment for spatial decision-making and problem-solving [10]. RCGIS focuses on delivering an object-oriented, multi-user collaborative workspace that enables real-time interaction and collaboration between stakeholders and professionals. It finds applications in disaster and emergency response, e-government, resource management, data production, collaborative mapping, and spatial modeling. In collaborative mapping scenarios, real-time collaborative editing significantly enhances communication efficiency among users. Traditional workflows often involve cumbersome file exchanges between users, leading to increased communication costs. Real-time collaboration addresses several challenges: improving work efficiency by allowing multiple users to work simultaneously on the same file, eliminating the need for repetitive file transfers and merge operations. Users can view each other’s modifications in real time and provide immediate feedback. Facilitating effective communication by enabling users to add comments and annotations directly within the file, clearly expressing intentions and issues without the need for repetitive explanations. In practical workflows, users often contribute diverse datasets, such as 2D or 3D data. Real-time collaboration allows these datasets to be integrated into a unified platform, enabling real-time browsing and collaboration, thereby significantly enhancing productivity.

In terms of collaborative frameworks and research methodologies, early work includes the decision task model developed by Nyerges et al. [11]. Convertino et al. explored a multi-view approach to enhance the expressiveness of real-time collaborative GIS. Chang and Li [12] investigated methods for developing 3D real-time collaborative GIS, proposing a hybrid system architecture that integrates centralized and replicated computing frameworks to create an integrated synchronous collaborative environment and 3D GIS tools for group decision-making and 3D information sharing. Marion and Jomier [13] experimented with WebGL and WebSocket technologies for 3D real-time collaborative visualization, evaluating performance metrics such as average latency, synchronization rate (per second), and primary rendering rate (per second). Sun et al. [14] developed a multi-view and geo-event-driven real-time collaborative GIS system. In the realm of commercial software, popular platforms include ArcGIS Online and Felt.

Due to the nature of supporting real-time and group collaboration, RCGIS design often requires special consideration of issues such as concurrency control and group awareness. In real-time collaborative GISs, conflicts between operations are inevitable, and concurrency control aims to resolve such conflicts. Previous research has employed various strongly consistent concurrency control methods, including lock mechanisms and flow control [12,15,16] (sometimes referred to as “token”). Beyond these common mechanisms, other techniques such as Operational Transformation (OT), proposed and tested by Ellis and Gibbs [17], have also been explored. Distributed systems need to deal with the fact that the data may be concurrently modified on different replicas. Generally speaking, there are two possible ways of dealing with such data modifications: strongly consistent replication and optimistic replication. CRDTs are used in systems with optimistic replication, where they take care of conflict resolution. By leveraging their inherent mathematical properties, CRDTs guarantee eventual consistency even when concurrent modifications occur on independent replicas. This merge is performed automatically by the CRDT, without requiring any special conflict resolution code or user intervention.

Telepointer, radar view, and multiple views can be used to support group awareness in RCGIS [10]. The telepointer tracks the user’s location on the shared map. Radar view provides miniature workspace overviews for awareness. The multiple-view technique employs multiple-view windows for awareness in collaborative workspaces. The public view provides a shared space where synchronized operations are performed and displayed. The private view provides a private workspace where the user can operate and display individual work. This separation clarifies real-time collaborative GIS operations, ensuring orderly workflows and better collaboration perception.

The third issue pertains to spatial analysis in WebGIS applications. In a local-first design, the application does not rely on server-based spatial analysis services but instead provides basic spatial analysis capabilities directly within the browser. Browser-based spatial analysis has garnered significant academic interest in recent years. Kulawiak et al. [18] discussed the feasibility and potential of creating thick-client WebGIS architectures, software libraries, and data sources, as well as comparing the performance of server-side and client-side data processing. Feenstra [19] proposed and prototyped a method centered on a visual programming language to host GIS library functionalities in a composable manner within applications, making core GIS libraries more directly accessible and combinable for end users. Currently, several web-based GIS applications are beginning to offer spatial analysis capabilities to end users. GeoTIFF [20] is an open-source, web-based tool for processing GeoTIFF files. It provides basic operations, such as calculating the median or average of specific regions and generating histograms, all computed in the browser using JavaScript. Szujó et al. [21] developed a WebGIS application to address issues arising in mining activities, leveraging open-source libraries like turf.js and kriging.js to provide geospatial analysis capabilities. However, browser-based spatial analysis faces numerous challenges; browsers and JavaScript are not ideal environments. Although there are several open-source JavaScript libraries for spatial analysis, such as turf.js [22] and kriging.js [23], JavaScript, as an interpreted language, is slower and less precise compared to system-level languages like C/C++ or Rust. Additionally, it has limited support for file read/write operations and lacks a robust ecosystem of geo-computation libraries. Emerging browser features like WebAssembly may offer solutions to some of these challenges. WebAssembly [24] enables running native software as part of web applications, addressing issues such as the inefficiency of JavaScript in data-intensive applications. Many libraries in the GIS domain, such as CGAL [25] and GEOS [26], are written in system-level languages and can be compiled into WebAssembly.

In the above context, this paper proposes an easy-to-use, interactive, and offline-capable local-first collaborative 3D WebGIS application. The application is built using open-source technologies. The proposed design addresses the issues identified in the preceding discussion, and the application’s functionalities combine and surpass the capabilities of existing individual solutions:

• Easy To Use: Maps and analytical tools for sharing geographic information are typically implemented as web applications. Compared to native applications, web applications offer distribution advantages and inherently support cross-platform compatibility.
• Minimized Server Dependency: The application relies minimally on servers, with data stored locally on each user’s device.
• Offline Functionality: The application remains functional offline and utilizes WebAssembly (WASM) for data-intensive spatial analysis, operating entirely within the browser’s local environment.
• Collaborative Integration: Leveraging CRDT technology for data collaboration, the application supports the integration of data from diverse sources to facilitate collaborative workflows.

Section 2 of this paper provides a detailed analysis of the application’s design methodology and system prototype, explaining the functionalities of each module. Section 3 demonstrates use cases and performance testing. Section 4 discusses the results of the application’s design and testing. Finally, Section 5 summarizes the proposed work and outlines future development directions.

2. Materials and Methods

We have developed a local-first collaborative 3D WebGIS application. Figure 1 illustrates the system architecture of the application. The primary components of the system reside on the client side, specifically within the browser. We utilized Progressive Web Application (PWA) technology to build the web application, ensuring offline functionality. Data are stored locally in the browser’s IndexedDB, and the data structure is constructed using CRDTs. Data exchange between users is facilitated through a WebSocket server, which does not retain any data. The following sections discuss the application’s design methodology and prototype development, focusing on both the client and server components.

2.1. Client-Side Architecture Design and Implementation

Thanks to the rapid iteration and development of web technologies, we can leverage multiple open-source JavaScript libraries and cutting-edge web technologies to build the client-side WebGIS application, eliminating the need to develop the entire application from scratch and saving significant time and effort.

For visualization, popular open-source 3D globe engine libraries include Cesium.js [27] and iTown.js [28], among others. We chose Cesium.js as the visualization framework for rendering a 3D virtual geographic environment. Cesium utilizes the glTF format for rendering 3D model assets, which is an open-standard runtime format for WebGL. GLB is a binary container format for glTF that packages all scene assets into a single binary file, reducing file size and improving processing efficiency. Additionally, Cesium.js has made significant contributions to large-scale data visualization, introducing the 3D Tiles format for the transmission and rendering of multi-source, heterogeneous large-scale datasets. Cesium.js can load realistic 3D Tiles from Google Maps via its Map Tiles API, creating an immersive experience. The application’s user interface (UI) is built using Vue.js, a modern front-end reactive framework.

For implementing collaboration and local-first software, open-source CRDT implementations such as Y.js [29], Automerge [8], and Collabs [30] are available. We selected Y.js to build the application. Y.js is a high-performance CRDT library designed for creating automatically synchronized collaborative applications. It exposes its internal CRDT model as shared data types that support concurrent operations. These shared data types resemble common data structures like maps and arrays. While leveraging open-source libraries is beneficial, discrepancies often arise between user expectations and library implementations during actual application development. Relying solely on library implementations limits control over the application, making it crucial to design CRDTs from scratch in certain scenarios.

For persistent storage, browser storage options include Cookies, Web Storage, IndexedDB, Cache Storage, and the File System API, among others. Cookies are primarily used for storing user authentication information and session states. Web Storage typically allows around 5–10 MB of data per domain, suitable for storing user preferences. IndexedDB is a transactional database system ideal for storing large amounts of structured data, with no strict size limits, making it suitable for complex application data storage. The File System API enables web pages to create and manage files and directories in the user’s file system, though it remains experimental and has limited support. Our application uses IndexedDB for data storage.

For browser-based spatial analysis, in the prototype application designed and implemented in this study, we use Rust, a system-level programming language, to implement the required spatial analysis functionalities. These are then compiled into WebAssembly (WASM) to run data-intensive spatial analyses directly in the browser.

The following subsections outline the design methodologies and implementation details across various aspects, including the application’s data structure and data flow design, data storage design, group awareness design, and browser-based spatial analysis design.

2.1.1. Data Structure and Data Flow Design

When developing local-first software, CRDTs serve as the foundational data structure. The primary goal of CRDTs is to achieve data consistency across multiple replicas while allowing independent updates on each replica without coordination. Even in cases of concurrent updates across replicas, all replicas eventually converge to the same state through mathematically reliable rules. Y.js enables concurrent updates of its internal CRDT model across different devices and ensures that replicas converge to the same state upon communication. Concurrent updates are seamlessly merged on each replica.

In the application, the data structure is abstracted into two categories: Element and Layer. The Element class represents user-generated annotation information during the mapping process, supporting operations such as adding, deleting, modifying attributes, and changing positions. The Layer class resembles the concept of layers in traditional GIS software, containing geographic location information which is immutable and supporting spatial analysis operations. The Layer class is categorized into the following types: Imagery, Service, and 3DTiles. Both data types require synchronization across users, so they are implemented using CRDTs. For the Element class, CRDT Objects or CRDT-value Maps are used to store the corresponding elements, depending on the collaborative content. Similarly, the Layer class includes a data attribute representing the immutable original data of the layer. For instance, the data attribute of a GeoJSON Layer stores a GeoJSON object. For binary data, such as GLB models rendered in Cesium, Uint8Array is used instead of Base64 encoding to store the data in the CRDT document, leveraging Y.js’s current support. This approach minimizes the data size for transmission. Figure 2 illustrates the JSON representation of a CRDT document in the application.

Based on the designed data structure, Figure 3 illustrates the state and data flow architecture of the application, which integrates a 3D rendering library, a reactive front-end framework, and a CRDT data structure.

All collaborative-related commands directly modify the CRDT-based data, and updates to objects in Cesium and the reactive framework’s state are triggered by listening to CRDT-related events. This design streamlines the data flow by eliminating the need for an additional binding layer between the CRDT and the application’s internal state. Consequently, the user interface logic does not need to differentiate between updates from local users and those received remotely over the network, as both types of updates seamlessly trigger reactive state changes.

In the application, user input originates from two sources: (1) commands triggered by the front-end UI, such as modifying element attributes or performing spatial analysis, and (2) commands triggered by interactive operations in the Cesium scene, such as adding elements through drag or click actions.

The application leverages Cesium to render the Element class and the Layer class. By default, the coordinate reference system used by Cesium’s virtual globe is EPSG:4326. However, the positions attribute of the Element class contains a set of points in the world coordinate system (three-dimensional cartesian coordinate system).

Cesium provides two types of APIs for rendering spatial data: the Entity API and the Primitive API. The Primitive API is a low-level interface intended for graphics developers, whereas the Entity API is data-driven and aligns more closely with GIS principles. Elements are integrated into the Cesium scene using the Entity API, as it facilitates easier interoperability with CRDTs. The Entity API provides support for rendering various vector geometries, including points, polylines, and polygons. Layers are integrated into the Cesium scene using different APIs. Imagery-type Layers are added to the scene using the ImageryLayer class, which is used to render raster files. Service-type Layers are added using the DataSource class. Additionally, 3D Tiles-type Layers are added via the Cesium3DTileset class.

2.1.2. Data Storage Design

In terms of data storage design, the application is developed as a Progressive Web Application (PWA), enabling direct installation on devices and leveraging Service Workers to provide a basic offline experience. A Service Worker is an event-driven worker registered for a specific origin and path. It exists as a JavaScript file and can control the associated web page/site, intercept and modify navigation and resource requests, and cache resources at a very granular level. This allows the Service Worker to fully manage the application’s behavior under specific conditions, particularly when the network is unavailable.

Additionally, when building local-first conventional applications, such as document or creative drawing applications, the shared content typically consists of data generated by users during interactions. However, for WebGIS applications, in addition to supporting user-edited features like map annotations, they often involve the analysis and visualization of large-scale geospatial data, such as 3D models and imagery. In the GIS field, such data are typically processed using the Level of Detail (LOD) concept, processing large-scale data through tiling and simplification methods, such as quadtree segmentation for imagery and the 3D Tiles format proposed by Cesium.

However, in offline scenarios, caching all imagery or terrain files, such as the aforementioned WMTS resources or 3D Tiles resources, is impractical. To partially address this issue, this paper proposes a caching strategy, as illustrated in Figure 4.

For imagery data, Service Workers are utilized to cache the resources necessary for offline operation, including the aforementioned low-resolution imagery. During the initial access to the application, low-resolution imagery resources are cached, enabling Cesium to render the 3D globe using the cached imagery when offline. In the prototype development, the low-level Natural Earth II imagery provided by Cesium was cached.

For 3D Tiles data, the application caches the tileset.json file when the resource is first added. The tileset.json file contains the Bounding Volume properties of the 3D Tiles dataset. When offline and unable to access network resources, the cached tileset.json file is used to render a translucent bounding box as a substitute for the actual large-scale data. This ensures that users do not encounter unexplained blank areas during practical use. This caching mechanism is primarily based on the following considerations: the 3D Tiles format is inherently a loose and low-constraint data format [31]. Model assets heavily depend on the production method of 3D Tiles, as different model partitioning and simplification methods can significantly impact the number of tile nodes and the size of individual tile models. Therefore, the application does not cache the actual model assets. Figure 5 illustrates how the application renders the same 3D Tiles Layer under different network conditions.

Users can utilize Cesium ion [32] or a simple file system to provide services. Additionally, they can utilize locally hosted 3D Tiles data, enabling offline access to their own data, though other project participants will not have access to them.

For user-uploaded GLB models, the models are saved to IndexedDB, and new object URLs are generated for each model. This approach allows the reuse of the same model when adding it to the scene, as the data structure only needs to store the asset ID. This avoids redundant uploads and storage, which could otherwise result in excessive storage consumption.

2.1.3. Group Awareness Design

In collaborative work, group awareness is a crucial feature that ensures users are fully informed during collaborative mapping. In 2D collaborative GIS, common tools include remote pointers, radar views, and the multi-view technique. This paper employs the following tools to enhance awareness among users.

The first tool is user location. In a 3D geographic environment, the camera positions of other users are rendered using point graphics in Cesium, indicating their current proximity to the scene. This is similar to remote pointers in 2D collaborative GIS but shares location information rather than pointer positions. The top-right corner of Figure 6 indicates there are two users in the current project, while the transparent circle in the bottom-left corner represents the location of the other user.

The second tool is synchronized cameras. Users can share perspectives by jumping to another user’s camera position and orientation, thereby improving communication and collaboration. In 2D scenarios, the viewpoint is often limited, and camera movement is restricted to panning. However, in 3D environments, the camera has additional attributes, such as rotation, making it essential to share both position and orientation to provide synchronized camera functionality for enhanced awareness.

For such frequently changing but non-persistent information, the application uses the Awareness CRDT provided by Y.js to propagate relevant information to all users.

2.1.4. Browser-Based Spatial Analysis Design

In terms of design, each spatial analysis operation is a tool within the toolbox. We use Rust, a systems programming language, to implement the algorithms and compile them into WebAssembly for use in the application. Additionally, we implement the same algorithms in JavaScript for comparison. Furthermore, the efficiency of WebAssembly programs depends on the optimization of their implementation and the design of the interface between WebAssembly and JavaScript. Poor interface design can, in fact, lead to reduced efficiency in WebAssembly. Therefore, when designing interfaces between WebAssembly and JavaScript, we should focus on optimizing the following attributes [33]:

1. Minimize read and write operations on WebAssembly linear memory. Unnecessary memory copying introduces additional overhead.

2. Minimize serialization and deserialization operations. These operations also increase overhead and are often accompanied by data copying processes.

In this study, heatmap analysis was used as a case study to investigate feasibility. In the implementation, the heat value matrix can be represented as a flat one-dimensional array in WebAssembly’s linear memory, where each array element corresponds to the heat value at a specific position. The array index is computed from the corresponding row and column indices. The color value matrix follows an analogous flat structure, with each array element containing RGBA values. The algorithm’s final output is this color value matrix. JavaScript efficiently obtains the results through direct access to the linear memory, thereby reducing unnecessary memory copying. The pseudocode for the heatmap algorithm is shown in Algorithm 1, with the complete implementation (v0.1.4) available on GitHub [34].

Algorithm 1. Heatmap Algorithm.
Input: A set of heat points P = {P1, …, Pn} and configuration (sizeX, radius, max heat, gradient, deltaLng, deltaLat) Output: Heatmap Image
1	Calculate perPixel = deltaLng/sizeX, sizeY = ceil(delatLat/perPixel)
2	Initialize: the heat value matrix and the color matrix using sizeX and sizeY
3	for each Pi in P do
4	Convert (lng, lat) to pixel coordinates (x, y)
5	Spread heat to neighboring pixels within radius
6	Update heat matrix with weighted heat values
7	end
8	for each pixel (x, y) in heat matrix do
9	Map heat value to RGBA color using gradient and max heat
10	Store RGBA values in color matrix
11	end
12	Create Image using color matrix
13	return Image

2.2. Server-Side Architecture Design and Implementation

As shown in Figure 7, the backend architecture of the application is relatively simple. CRDTs are inherently agnostic to the underlying network communication technologies, provided that all updates are eventually delivered. The synchronization of the document remains consistent regardless of the order in which updates are applied. Y.js’s CRDT implementation exemplifies this network independence, allowing for flexibility in practical development scenarios where various communication methods can be employed or even integrated. In our design, the backend server functions exclusively as a signaling server to facilitate the transmission of collaborative data. WebSocket was selected as the communication protocol due to its efficiency. Importantly, the server does not retain any user data, thereby safeguarding user privacy.

Different clients connect to the same project, i.e., the same document, by sharing the same room ID, as shown in Figure 8.

3. Results

To evaluate the application’s functionality, this study designed an experimental scenario. The application’s multi-user collaboration capability was tested with two participants performing editing operations under both online and offline conditions. The computers used in the tests were configured with (1) AMD Ryzen 7 4800U with Radeon Graphics, 16 GB RAM, and (2) Intel Core i7-8750H CPU, 8 GB RAM, both running the application on the Chrome browser. The tests were conducted by two users, User A and User B. The server was deployed in a local area network.

To evaluate the performance of the implemented heatmap analysis, this study conducted benchmark tests. The computers used in the tests were configured with AMD Ryzen 7 4800U with Radeon Graphics, 16 GB RAM.

3.1. Experimental Procedure

User A and User B are about to perform a mapping demonstration for a specific scenario. Figure 9 shows the initial interface of the program.

User A creates a project and generates a room ID, which is then shared with User B. User B uses this ID to connect to the same project. In the upper right corner, we can see a list of avatars indicating the presence of two users at this time. The basic editing operations in the scenario are as follows. Different users can perform edits, such as adding point, line, and area markers (Figure 10). The current user can view the results of other users’ operations in real time.

In addition, users can add pre-cached GLB models or upload their own GLB models to the scene. They can also use the gizmo tool to edit the positions of model entities in the scene. As shown in Figure 11, the model entity currently being edited by User A is highlighted within the red square bounding box.

In offline mode (when the server is down or there is no network connection), User A and User B can still perform various editing operations on the scenario. As shown in Figure 12, the respective editing results from two users working in offline mode are highlighted within the red square bounding box. Upon reconnecting to the server, all changes made by different users are synchronized, and the results remain consistent (Figure 12).

Next is the spatial analysis operation in the scenario. After User A adds heat point data (Figure 13), User B chooses to visualize the data added by User A using a heatmap visualization (Figure 14). The computation process runs in the browser environment, offering both WebAssembly and JS modes, and can also be used offline. The final results of the analysis are synchronized between users when connected to the server.

When User A and User B collaboratively edit the scenario, conflicts are automatically resolved, ensuring that their results remain consistent.

In the aforementioned usage scenario, the application demonstrated stable performance and high execution efficiency during testing (Video S1 in the Supplementary Materials demonstrates the entire experimental procedure). Cutting-edge web technologies enable the construction of applications that meet the required specifications.

3.2. Performance Tests

We evaluated the data processing performance across different modes using heat points of varying magnitudes, specifically testing scenarios with 100, 1000, 10,000, and 100,000 heat points. Figure 15 illustrates a comparison of the runtime efficiency between the JavaScript (JS) and WebAssembly (WASM) implementations of the same heatmap algorithm. Specifically, it shows the relationship between the number of heat points and the processing time under the condition of generating heatmaps of the same size. When the data volume is small, the computation time in WASM mode is longer than that in JS mode. This is because the communication between the JS and WASM modules becomes the primary bottleneck at this stage. However, as the data volume increases, such as when the number of heat points reaches 10,000 or 100,000, the gap in computation time between WASM and JS grows significantly. WASM demonstrates lower computation time compared to JS when handling large data volumes.

4. Discussion

From the principles of designing local-first software, we consider user-generated data as collaborative, such as Elements and Layers produced during the mapping process. For Layers, uploaded data are considered immutable, as enabling collaborative modifications would necessitate a more granular data model design. In practice, we made trade-offs based on the software’s functional requirements. In addition to user-generated data like Elements and Layers, base maps are also an essential part of the data required in a 3D geographic environment, typically existing as external services in vector or raster tile formats. However, caching complete imagery or terrain files for offline use is often impractical. To partially address this issue, our application employs a caching strategy. Specifically, during PWA installation, low-resolution imagery is pre-cached as a fallback to ensure users can perform basic operations offline. Additionally, for assets in 3D Tiles format, we cache the tileset.json file. This strategy is essentially a compromise. However, if constraints can be applied to 3D Tiles resources, such as limiting the model size of each tile layer and the number of top-level tiles, or generating a low-quality coarse model as the top-level node, the program can better cache these resources and improve visualization quality in offline scenarios.

The application client we developed is a web application that runs in a browser. Offline usage and data persistence are achieved through APIs such as LocalStorage and IndexedDB. However, these APIs are designed under the assumption that local user data serve only as a cache and are not authoritative, making them prone to expiration without warning or notification. Local-first software is not limited to the browser platform and can avoid these limitations by developing cross-platform applications based on Electron [9]. However, this approach sacrifices the distribution advantages and accessibility of web applications, which is why we chose the current technology.

In the program implementation, the Y.js framework, as a highly optimized implementation of CRDTs, provides robust support for real-time collaboration. The CRDT-based architecture also ensures performance. By designing the program using the data flow described in this paper, the application runs smoothly. However, performance optimization remains a critical consideration during the actual design and development process. For example, during the mapping process, certain attributes in the document, such as the position properties of annotation information, may change frequently, potentially leading to performance bottlenecks. To address this, techniques like throttling or periodically saving data to Y.js can be employed to reduce unnecessary computational and communication overhead. Additionally, potential performance issues should be considered early in the data structure design phase to ensure the system remains smooth under high-concurrency or large-data-volume scenarios.

In terms of group awareness, collaborative work often requires a shared environment where users can access information about other participants. In 2D environments, it is common to render other users’ mouse pointers as a collaborative tool. However, in 3D geographic environments, the cursor position of the mouse is not the optimal choice. This is because, in 3D environments, the projection point of a user’s mouse in the virtual space can change drastically in a short time and may not even project onto the virtual Earth, such as when pointing into space. In our application, we represent group awareness information using other users’ camera positions and a user list, which is common in real-time collaborative systems. In future development, rendering other users’ camera directions and adjusting the scale of entities based on their distance from the Earth could further enhance interaction.

Following the design principle of minimizing server dependency in local-first software, we use WebAssembly (WASM) instead of JavaScript for spatial analysis on the browser side. Although WASM exhibits superior performance characteristics in many aspects, such as efficient execution in computation-intensive tasks, improper program design can lead to situations where WASM underperforms compared to JavaScript. For example, frequent memory copy operations can significantly increase overhead, thereby diminishing the advantages of WASM. Therefore, during software development, targeted optimizations should be applied based on specific application scenarios, such as reducing unnecessary memory operations and optimizing the interface design between WASM and JavaScript, to fully leverage the potential of WASM.

Finally, on the server side, we use WebSocket as a signaling server to transmit document updates, with the server not storing any information. However, due to the network-agnostic nature of CRDTs, the program can use any connection-oriented network protocol to synchronize states, such as client/server (e.g., WebSocket), peer-to-peer (e.g., WebRTC), or local connections (e.g., Bluetooth). Therefore, in practical software development, the appropriate method for transmitting updates should be chosen based on specific business requirements.

This study presents a local-first collaborative 3D WebGIS application developed through multiple technical implementations: (1) PWA for web application construction, (2) IndexedDB for data persistence, (3) CRDTs for underlying data structures, (4) WASM for spatial analysis on the browser side, and (5) WebSocket for communication. The current design successfully balances functionality with technical feasibility under local-first principles. Notably, there remains room for improvement in offline caching strategies and CRDT performance optimization.

5. Conclusions

In this paper, we designed and developed a collaborative WebGIS application based on multiple open-source libraries, aiming to deliver a local-first user experience. The local-first design philosophy enables users to engage in mapping activities offline and automatically synchronizes all content upon reconnecting to the server, ensuring data consistency and availability. The application’s core architecture is based on Conflict-free Replicated Data Types, a choice that not only provides a solid foundation for local-first software but also offers a concise and efficient solution for collaborative needs in digital twin scenarios. Digital twin environments often involve multiple stakeholders and users with different roles, making real-time collaboration an indispensable feature.

In future development, we will focus on refining the application’s core functionalities and expanding its applicability in the GIS domain, utilizing more advanced CRDT algorithms to build the application’s data structures. We plan to enhance compatibility with mobile devices and design more user-friendly interfaces to improve the user experience. Furthermore, we aim to encapsulate the application’s core functionalities into an independent library based on Y.js and Cesium.js, increasing its versatility and enabling developers to customize solutions more flexibly according to specific needs. Particularly in digital twin and GIS real-time collaboration scenarios, developers can leverage this library to rapidly build applications tailored to specific requirements, thereby driving technological advancements and innovation in these fields.

The code for the application developed in this paper is available on GitHub [35].