Development of a multi-view and geo-event-driven real-time collaborative GIS

ABSTRACT

Supporting distributed real-time collaborative work has become an important development trend in GIS. It enables group users to cooperate and improve the use of scientific data and collaboration technologies. Real-time collaborative GIS (RCGIS) provides a platform for supporting synchronous collaboration using geospatial data in various forms. Traditional RCGIS generally works on a single map view, which has the disadvantage of collaborative interface confusion. The traditional system-driven mechanism of RCGIS is a computer-interaction event that has the disadvantage of an unfriendly collaborative perception. This paper presents a design and prototype of a RCGIS based on multi-view and geo-event driven mechanisms. The geo-event-driven mechanism provides users with a smoother collaborative perception and interactions that are more natural and friendly. The collaboration process for a GIS that is driven by geo-events is also discussed. A multi-view technique is used to make real-time GIS collaboration more orderly. The paper also proposes a synchronization strategy for public–private views. Finally, walk-through examples are used to demonstrate the use of RCGIS within a web environment.

KEYWORDS:

• Geographical information
• collaboration
• real-time
• multi-view
• geo-event driven

1. Introduction

The COVID-19 pandemic has changed where and how people work and has raised new demands for efficient software tools to support virtual collaboration, which has become vital to essential business processes and people’s social connections and well-being. Collaborative Geographic Information Systems (CGIS) have been an important research area over the past decades. However, they may become a resurging area of development to support the collaborative exploration of geospatial data for group decision support, especially in real-time, synchronous modes. Unlike asynchronous collaboration systems, synchronous collaboration systems are characterized by operation concurrency, instant response perception, and level of interaction freedom.

A real-time CGIS (RCGIS) provides a multi-user, real-time, and synchronized collaborative work environment, i.e. what you see is what I see (WYSIWIS), for spatial decision support and problem-solving (Armstrong 1993; MacEachren et al. 2005; Sun and Li 2016). RCGIS can change and optimize the group decision-making environment with geospatial data and assist users who come from various professional fields to work together at the same time from different places. It can build a virtual space where decision-makers can communicate across time and space boundaries. This kind of system can be used in disaster and emergency response (Fuhrmann et al. 2003; Schafer, Ganoe, and Carroll 2007; Zhu et al. 2016; Ghavami, Maleki, and Arentze 2019) to provide a working environment for spatial decision-making and problem solving. Application areas include public participation (Li et al. 2007; Brown 2017; Palacio Buendía, Pérez Albert, and Serrano Giné 2019) and spatial planning (Fechner, Wilhelm, and Kray 2015; Kuby et al. 2018; Aguilar, Flacke, and Pfeffer 2020).

In previous research, RCGIS mostly used one shared map view interface (Chang and Li 2008; Kang 2015; Sun, Du, and Zhou 2010) and suffered from defects in interaction ability. First, personal and collaborative GIS operation results have been displayed on a single shared map view, making it difficult to comprehend and display group consensus. Second, RCGIS has widely used inflexible concurrency control strategies, which degraded users’ real-time collaborative operation perception. Multi-view technology can help effectively resolve these problems by separating users’ private and shared GIS operations, synchronizing the results when necessary, and making the entire collaborative process clearer and more orderly.

Previous RCGIS were usually driven by computer-interaction events, which produced problems related to coarse coordination granularity and the occurrence of many redundant collaborative operations. The event-driven mechanism can be seen as the engine and one of the key techniques of RCGIS. GIS has many types of functions and complicated operations, and an appropriate driven mechanism can provide users with a smoother collaborative perception effect and friendlier interaction. Herein, a geo-event-driven mechanism is proposed to solve the above problems. This paper presents the design and implementation of multi-view RCGIS, as well as some critical technical issues. The remainder of this paper is organized as follows. Section 2 reviews related work. In Section 3, the geo-event-driven mechanism of RCGIS is analyzed in detail. This section also discusses the collaborative mode of public–private map views and the conversion method between the shared (public) and private views. Section 4 introduces system prototype development and walk-through testing. Finally, conclusions and system improvements are provided in Section 5.

2. Background and related work

The development of RCGIS has gone through various stages, starting from conceptualization through the development of tools and systems to the exploration and evaluation of different applications. A detailed review is presented in Sun and Li (2016). This paper discusses the research progress on event-driven mechanisms and multi-view technology as well as development techniques.

2.1 Event-driven mechanisms

The real-time collaboration procedures must be clearly described before elaborating on RCGIS’s driven mechanism. The basic implementation procedure can be abstracted as shown in Figure 1. When a real-time collaboration session begins in a collaborative GIS environment, the GIS operation is initiated and executed on a user side. An operation message is then generated and transferred to other participant sides. After the message arrives at the other user sides, the same GIS operation is executed by parsing this message and extracting the GIS operation information. As such, each user obtains the identical results of the operation, i.e. their interfaces have the synchronized map views.

Figure 1. The process of generating, delivering, parsing and executing GIS operation messages(Sun 2007).

In the current development of RCGIS, the most common event-driven methods for coordination among collaborating users use computer interaction events based on keyboard and mouse (Kanzawa et al. 2008; Cheng, Chen, and Han 2012). Within this kind of mechanism, real-time collaboration begins once a user's collaborative operation triggers a control event, such as map zooming with a mouse wheel or panning by dragging, which is built into the user interface. The implementation of the process illustrated in Figure 1 depends on the way the event message is packed, transmitted, extracted, and executed.

Kanzawa et al. (2008) proposed an online communication system for supporting real-time collaborative analyses of remote sensing images by researchers at remote sites. The system allowed users to define the boundary of an area of interest by free-hand drawing using a mouse, accomplished by clicking the left mouse button and holding it down as they draw with the mouse. Releasing the mouse button ended the line and triggered an operation message transferred to the server using socket communication. The boundary would be redrawn on other user sides upon receiving the operation message. Sun, Du, and Zhou (2010) used component GIS technology and the C# programming language to develop a RCGIS based on a client/server architecture. A collaborative GIS message was generated when the independent GIS operation was completed through mouse or keyboard interaction with a client. This message was transferred to the server using the message communication technique, and then distributed to the other collaborative clients where the message was re-executed to get the operation result consistent with the co-initiator. A detailed GIS collaborative message-coding format was given in the above research work. Cheng, Chen, and Han (2012) used mouse and keyboard interaction events to trigger the transmission of collaborative messages among collaborators through the message queue technique, and the messages were analyzed and executed on the collaborative sides to realize GIS real-time collaboration. A prototype system was built using JavaScript and OpenLayers to support multiuser GIS collaboration and collaborative map annotation. A spatial operation transformation algorithm has been proposed for GIS collaborative message’s merging and efficient processing.

There are two main advantages of the above event-driven mechanism. One is that the user’s collaborative operations can be immediately delivered to every collaborative user. The other benefit is that the operation semantics of computer interaction events are clear, which reduces the complexity of system development. However, there are also shortcomings. First, the collaboration granularity is relatively coarse, and the collaborative perception effect is not ideal. Second, many redundant collaborative operation messages are generated, and some operations may lead to continuous changes in geospatial objects (hereafter geo-objects), while these operations need not be synchronized at all. For example, when a user pans a map, each drag-and-drop operation changes the extent of map views. Frequent panning operations lead to drastic changes in the collaborative map view, and the collaborative users are disrupted by the constant changing of the shared map interface, which greatly reduces the effect of collaborative awareness.

We propose a geo-event-driven method that overcomes the shortcomings of using computer interaction events to trigger coordination among collaborative clients. This is accomplished by monitoring changes in the attributes of geo-objects. Geo-objects are computer representations of features that represent real-world objects such as rivers, buildings, roads, and trees, even a map layer or map view (Gong, Li, and Wu 2014), and their attributes may be spatial, thematic, and temporal. Any GIS operation can generate a geo-event that contains information such as the time and location of occurrence and the attribute changes of geo-objects.

A geo-event is a kind of event that leads to temporal and spatial changes in geo-objects (Su, Zhou, and Shi 2004), and drives the corresponding changes in related geo-objects under certain conditions. The changes of geo-objects are normally recorded by the state sequences of objects. A spatiotemporal data model is presented that describes the integrated spatiotemporal process, geo-objects and geo-events. The mode serves the need for dynamic geographic object and dynamic process simulation according to the characteristics of various geographic features and the requirements of storage management in real-time GIS. Traditional spatiotemporal data models are not suitable for analyzing the overall temporal relationships of events. Peuquet and Duan (1995) addressed this issue by presenting an event-based Spatio Temporal Data Model (ESTDM), which can explicitly represent changes over space relative to time. The information contained in a geo-event generally includes the occurrence time, place, and attribute changes in geo-objects (Zhang et al. 2017). In RCGIS, a user’s GIS operation can be considered as a geo-event that captures the above information.

The geo-event-driven method has the advantages of fine-grained collaborative operation and a smooth user collaboration experience. At the same time, it can also naturally eliminate some redundant GIS collaborative operations.

2.2 Multi-view technology of RCGIS

Multi-view means that there is more than one view in the user interface. The overview map, which is a common feature of GIS software, can be used as an example. Usually, the over view map is simultaneously connected to the main map view, and through it, the location of the main map can be seen. Presently, the research on multi-views in the geospatial information technology field mainly focuses on 3D modeling and applications (Luo et al. 2019; Liu et al. 2021), big data analysis and visualization (Butkiewicz et al. 2008; Herranz et al. 2014), and collaborative work (Wu et al. 2013; Nuernberger et al. 2016). The multi-view technique used in 3D modeling can help to observe the model from different perspectives, and multi-view stereo methods are able to produce precise and highly detailed 3D reconstructions (Maurer et al. 2012). Spatiotemporal big data contains rich semantic information and multi-views can be used for collaborative analysis to mine and express complex spatiotemporal relationships (Liu, Wu, and Yu 2017). Li et al. (2019) suggested that big spatiotemporal data might be divided into spatial, temporal, and attribute dimensions. Furthermore, these could be mapped as spatial, temporal, and attribute views, respectively, to fully display the spatial distribution, attribute changes, and temporal evolution of data.

The multi-view techniques in the above areas are usually applied to a single-machine or single-user system. It is the development trend of GIS application to support multi-users in collaborative work. The application characteristics of RCGIS are only distributed among group users. Past researches have been dedicated to studying the combination of multi-view techniques and the collaborative GIS, although not many. Convertino et al. (2007) provided a shared space for building and discussing plans with team and role-specific views. It was equipped with role manipulation tools and transformation tools, which could transform the summarized data’s presentation and comments into the map in the team view. The study focuses on an emerging domain of applications for human–computer interaction at that time. The multiple view technique was initially developed for single-user applications, but was adapted by teams of experts in CSCW (Computer Supported Cooperative Work). A core research member of the same research team as the above authors proposed a multi-view, role-based system, with both private and public maps to help team members analyze geo-spatial information and monitor individual activities in emergency management (Wu et al. 2013). However, the above research did not discuss how to solve the conflicts. The current research should adapt to the new generation of network environments to develop a multi-view RCGIS system with stronger distributed application abilities. Nuernberger (2016) presented a multi-view technique to solve spatial problems in the field of 3D GIS, claiming that simple 2D gesture annotations could be used to convey spatial information to another user in image-based 3D reconstructed scenes with applications in collaborative virtual and augmented reality. Additionally, they also proposed a multi-view annotation method that was useful in a variety of scenarios and applicable to both sparse and dense 3D reconstructions.

In the above research, multi-view techniques have enabled multiple people to cooperate in an orderly manner to complete tasks, which is essential for the development of real-time collaboration in work environments. For RCGIS, multiple views can help separate the display of users’ shared and private GIS operations, making the real-time collaborative work process clear and more orderly, and enabling a friendly collaborative operation perception.

2.3 Development methods of RCGIS

Due to developments of information technology and the increases in network speed, RCGIS development has transitioned from coarse-grained system integration, which integrates single-user GIS systems with groupware systems, to fine-grained system integration. This new method uses messaging technology to establish an RCGIS system by decomposing and analyzing GIS operations.

From a distributed computing perspective, the structure of software systems has evolved from client-server (C/S) architecture to browser-server (B/S) architecture and service-oriented architecture (SOA). C/S was used in early RCGIS (Manoharan, Taylor, and Gardiner 2002; Kanzawa et al. 2008). The spatial data and collaborative application modules were deployed on the collaborative users’ sides (‘clients’), and collaborative control modules were deployed on the server-side. Every client was able to take full advantage of its computing capability, but it was very difficult to maintain collaborative consistency among clients. In this period, component GIS technology was combined with a high-level language to complete system development.

WebGIS technology gradually matured in the twenty-first century, and RCGIS’s architecture evolved to incorporate browser-server (B/S). The system maintenance and distributed computing capabilities of RCGIS have been significantly improved compared to C/S. Clients do not need to install the collaborative applications separately, and data and applications are all deployed on the server sides. Fechner, Wilhelm, and Kray (2015) developed a real-time collaborative map editing system based on web technologies, such as HTML5, JavaScript, and Mapbox.js. Due to the wide distribution of application deployments, the response efficiency is a crucial problem for RCGIS based on B/S architecture.

SOA is a new generation of software architecture. It links the various functional units of the application (called ‘services’) through well-defined interfaces and contracts (Papazoglou et al. 2007; Park et al. 2019). The core idea of SOA is to use alternative technologies and methods to structure applications by linking services together rather than writing new code. This kind of architecture is gradually being used in RCGIS. Web service is a widely used SOA implementation technology (Fallahi et al. 2008; Al-Hader et al. 2009). Butt, Mahmood, and Hassan Raza (2018) proposed an online system (‘GeoWebEX’) for supporting group collaboration. GeoWebEX can integrate geographical data from various remote sources in the form of web services.

It has become a trend to combine SOA and B/S architecture and use open source technologies to develop RCGIS.

3. Methods and design considerations

The key components of RCGIS are mainly related to coordination among multiple users, including multi-user synchronization and coordination of multiple views.

3.1 Multi-user synchronization driven by geo-events

An important aspect of a collaborative system is to share events among collaborative users in the same session. In this paper, we took advantage of the geo-event-driven mechanism described in Section 2.1 to develop the coordination among collaborative users.

Conceptually, the geo-event-driven mechanism is based on binding listeners to geo-objects’ attributes. If a geo-object’s attribute changes, a geo-event is triggered and the listeners respond to the change. The collaborative process is initiated if the range of this change exceeds the pre-defined threshold. Theoretically, any attribute can be bound to a listener and multiple listeners are possible. The following expression provides a general listener definition, which identifies the geographic object, attribute name, attribute change event, and processing function. (1) $\mathrm{L}\mathrm{i}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}=\mathrm{W}\mathrm{a}\mathrm{t}\mathrm{c}\mathrm{h}\left(\mathrm{g}\mathrm{e}\mathrm{o}-\mathrm{o}\mathrm{b}\mathrm{j}\mathrm{e}\mathrm{c}\mathrm{t},\mathrm{a}\mathrm{t}\mathrm{t}\mathrm{r}\mathrm{i}\mathrm{b}\mathrm{u}\mathrm{t}\mathrm{e},\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{n}\mathrm{t},\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}\mathrm{b}\mathrm{a}\mathrm{c}\mathrm{k}\right)$(1) The parameters of the listener are defined as follows:

• Geo-objects: view objects, layer objects, feature objects, etc.

• Attribute: both spatial and non-spatial attributes, such as the extent, scale, length of a river, and land use type.

• Event: The event that causes the value of the attribute to change, also known as the geo-event. It is always initiated by and encapsulated based on user interaction events.

• Callback: the handler function after the collaboration has started.

For example, if a View object is listened to, two listeners can be bound to the View object to separately monitor changes in the extent and the scale attributes, which is essential in a real-time collaborative GIS to maintain consistent views for all collaborative users. (2) $\mathrm{L}\mathrm{i}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}1=\mathrm{W}\mathrm{a}\mathrm{t}\mathrm{c}\mathrm{h}\left(\mathrm{v}\mathrm{i}\mathrm{e}\mathrm{w},\mathrm{e}\mathrm{x}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{t},\mathrm{c}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d},\mathrm{f}\mathrm{u}\mathrm{n}\mathrm{c}1\right)$(2) (3) $\mathrm{L}\mathrm{i}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}2=\mathrm{W}\mathrm{a}\mathrm{t}\mathrm{c}\mathrm{h}\left(\mathrm{v}\mathrm{i}\mathrm{e}\mathrm{w},\mathrm{s}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{e},\mathrm{c}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d},\mathrm{f}\mathrm{u}\mathrm{n}\mathrm{c}2\right)$(3)

The inclusion of thresholds helps to realize a relaxed what-you-see-is-what-I-see effect, which means that the displays of the GIS operation results may not be the same on different collaborator’s screens. Take map zooming as an example. The real-time collaboration will not start when a user performs a map zooming operation in a very small range on the local map view (i.e. the change value for the scale attribute is less than the preset threshold). Otherwise, the collaborative work will start if the change value of the scale attribute is greater than the threshold. At the same time, the collaborative receiver can also perform a zoom on the map with the same parameters. The advantages of RCGIS based on geo-event is that the collaboration will not be started by the user’s random map operations, which will lead to chaos in real-time collaborative work. An RCGIS driven by geo-events will bring users a friendly and smooth collaborative interaction experience.

Figure 2 illustrates the overall collaboration process driven by geo-events. The collaboration process begins when the initiating collaborative user performs a GIS operation that leads to changes in the attribute value of a geo-object. The binding listener then determines whether the changed attribute satisfies the threshold condition. If the result is true, a collaborative GIS message (CoGISMssg) is generated and sent to the server side through message communication technology. The CoGISMssg consists of the basic information for initiating the collaborator and GIS collaborative information. The former is mainly composed of the collaboration time, collaborator ID, and user role, and the latter is mainly composed of the geo-object and its parameters. The following examples help to further understand the composition of CoGISMssg. On the server side, CoGISMssg is stored in a collaborative message queue, and then distributed to the other collaborative users. Upon receiving this message, the responding collaborator unwraps it to extract the information about the geo-objects and their changes, and updates the corresponding geo-objects on the collaborative side.

Figure 2. Overall collaboration process driven by geo-events.

The CoGISMssg is coded in JSON (JavaScript Object Notation) format in the RCGIS system, and its basic structure is shown below.

CoGISMssg={

 “CoInfo”:{}, // basic information of initiating collaborator, such as collaboration time, user role, collaborator ID, etc.

 “GISCoInfo”:{

     “collaborationType”: “View Operation”,

     “geo-object”: “View”, // current collaboration geographic object

      “extent”: [Xmin, Ymin, Xmax, Ymax],

      “scale”: n,

                …  … //other information }

}

3.2 Coordination of multiple views

RCGIS adopts the multi-view concept by including both private and public views to support multiple users. Each user has a private and a public view. The public views of all users in the same collaboration session are coordinated (or synchronized) in real-time. Furthermore, each user’s private view is only synchronized to that user’s public view, which is the shared view, when necessary. The private–public views allow for the freedom of each user to work on some tasks privately, while the consistency of views is shared by all users, i.e. what-you-see-is-what-I-see. A single private or public view displays a set of data, or the derived data through GIS operations, and is embedded in that view’s interface. In the case of RCGIS, the data mainly consists of geospatial data (i.e. 2D/3D maps) and the data derived from performing GIS operations, which may be displayed in tabular or graph form.

As illustrated in Figure 3, two types of coordination are required to support group collaboration through these views. One is the coordination between all users’ public views. The other one is the coordination between the private and public views of a particular user.

Figure 3. Coordination between private and public views.

3.2.1 Coordination between all users’ public views

Each client has a public map view, and every GIS operation on the public view should be immediately synchronized. GIS collaboration between public views uses geo-event-driven mechanism, and its working principle is shown in Figure 2. The public map view is the expression interface of all real-time collaborative GIS operations, and the operations that are executed on it should be clear and intelligible. The concurrency control strategy with certain constraints is applicable to the GIS operations on the public map view, and the floor control method is applicable in this case. The moderator of this collaboration will allocate the floor control, and users who obtain the floor control can perform collaborative GIS operations on the public view.

3.2.2 Coordination between private view and public view

Synchronization between the public and private views is the key technical issue, and real-time collaboration based on private map view is more complex. Every user can synchronize the operations performed on their private map with the public map view. However, at this time, the map view interface for private and public views is inconsistent. Our solution is shown in Figure 4.

Figure 4. Synchronization process for the public-private views.

The user needs to first obtain the floor control to synchronize GIS operations from the private view onto the public view. Users can perform GIS collaborative operations only after they obtain the floor control, and at the same time, only one of the collaborators can have the floor control on the public map view.

Since the private and the public view are inconsistent, it is necessary to find the last synchronization point before subsequent real-time collaborative work occurs. Synchronization is then performed using this synchronization point as the benchmark. It should be noted that FLCtr2(Floor control 2) has a higher level of operation authority than FLCtr1(Floor control 1) (see Table 1 for details). Every user has a private operation database maintained on the server, and all users’ public views use the same operation database. That is to say, as long as the public view of any user changes, the public view of other users also changes. The last synchronization point is obtained by retrieving the public and private GIS operations databases separately, which is based on extracting the public and the private GIS operations that have been generated so far. The batch of public GIS operations that are generated after this synchronization point will be ignored. Based on the principle of map view consistency, the batch of private GIS operations which are generated after the synchronization point is executed on the public view through an operation merging process. The merged GIS operations performed on the public view are then saved into the public operation database on the server. At this time, the public and private views are consistent, and the new synchronization point is recorded in both the public and private operation databases.

Table 1. The level of floor control.

Abbreviated names of floor control	Collaboration between public views	Collaboration between the public and the private view
FlCtr 1	Yes	No
FlCtr 2	Yes	Yes

It should be noted that there is also a way for collaboration when moving from the public to private view that does not require floor control in advance. The user can start this function when they find that the current public view interface effect is exactly what is wanted. This principle is similar when converting the private view into the public view, and will not be repeated here. The collaboration between private and public views are both triggered by function buttons on the application interface.

3.2.3 Analysis of different collaborative work modes

Collaboration from public view to public view is the main mode adopted by most real-time collaborative systems. This type of system development method usually uses the concurrent technique of floor control. The floor control method makes the real-time collaborative work orderly, but also greatly reduces system flexibility. Only the user that obtains the floor control is able to operate the system in the process of real-time collaborative work, while other users can only wait and observe, thus resulting in an unfriendly system interaction experience. The multi-view technique can solve this problem by enabling a real-time collaborative GIS. If a user obtains the floor control, they can perform collaborative GIS operations on the public view. Other users can observe the changes in the public view while performing spatial operations in their private view. The work between users does not disturb each other. This greatly improves the flexibility and application ability of RCGIS.

4. System development and prototyping

4.1 System architecture

The system architecture of RCGIS based on web and multi-view technology is shown in Figure 5. The system adopts a centralized structure and B/S architecture. The main functions of the client are performing GIS operations, listening the changes of geo-objects’ attributes, generating GIS operation messages, and transmitting and receiving messages. Some important modules are deployed on the server side, such as the communication module, public–private view conversion module, public–private GIS operations merging process, and collaboration rules module. The GIS operation message database and collaboration rule database are stored on the data server, and spatial data is stored centrally on the server.

Figure 5. System Architecture.

4.2 Prototype development

The implementation of modern GIS systems increasingly uses open-source technology (Leidig and Teeuw 2015; Butt, Mahmood, and Hassan Raza 2018; Nicolaescu et al. 2018). Similarly, some open-source software and web-service technologies are adopted in RCGIS development, including GeoServer, MySQL, and Web map APIs. WebSocket is used to realize two-way communication. GeoServer is used as a spatial data service-publishing platform, and map APIs based on the Web are used as the development interface of GIS functions. The spatial and other collaborative data are stored on the server-side in the database.

The main interface of RCGIS is based on multiple views and is shown in Figure 6. The interface is composed of the menu bar, public map view, private map view, and collaborative information area.

Figure 6. The initial interface of User A and User B.

Menu bar: At the top of the interface, the public and the private views have their own separate menu function bars. The menu bar of the public view includes basic map operations, spatial queries, and the function of conversions between the public view and private view. The menu bar of the private view includes map annotations, basic map operations, spatial queries, spatial analysis tools, and map editing tools.

Map view area: Map views are in the middle of the interface and are the main area for displaying spatial operation results. The left side of the interface is the public map view, and the right side is the private map view area.

Collaborative information area: At the bottom of the interface, the collaborative information area is divided into three parts, which includes the online user display area, instant messages, and the collaborative GIS operation message area. A user identification shown in bold means that they are the moderator, and an underlined user description indicates the current user. The collaborative operation messages area shows GIS operation information executed in the public view. Instant messaging provides users with a chat function during the collaboration process.

4.3 Usage scenario

The computers used in the system function tests were configured with an Intel Core i7-8700 3.2GHz CPU with 16 GB of RAM, and the test was carried out by two users, User A and User B. Taking the site selection in a park as an example, a collaborative process that the private view was converted to the public view will be discussed. Figure 6 shows the initial interface of the two users, who in this scenario were discussing the site selection for public fitness venues using multi-view RCGIS. They both had two map views. The left was a public view that the GIS operations performed on it were immediately collaborated. The right was private view and the GIS operations performed on it were not collaborated on in real-time. The collaboration from private to public view was triggered by a menu function on the right interface of each graph, marked with a red box. First, User A and User B individually executed private operations on their local private views. Two users can be seen in the online user display area, and User A, who is displayed with a bold username is the moderator with the floor control. User A and User B both performed map zoom and pan operations, as shown in Figure 7. At a certain time, User A circled a piece of land as a fitness place not far from the park gate. Subsequently, User A clicked the button to convert the private view to public and uploaded the results of GIS operations from the private view into the public view. In Figure 8, User A and User B’s public views showed the corresponding collaborative operation results, but Client B’s private view was not disturbed. User A and User B can work independently, and they may upload their GIS operations to the public view when needed. The collaboration information prompt area at the bottom of the interface shows that User A just shared private operations with the public view.

Figure 7. User A and User B perform GIS operations on their respective private views.

Figure 8. User A performs a private operation that collaborates with the public view.

Each system test was conducted by a group of two or three users. The system ran stably in the test environment with high execution efficiency. In the above usage scenario, the response time of each collaborative GIS operation performed by the users did not exceed five seconds. Most collaborative GIS operations could be re-executed within one to two seconds.

5. Concluding remarks

Traditional RCGIS only uses a single map view to collaborate, and this application mode has the disadvantage of either a chaotic collaborative interface or limited user operation. RCGIS based on the multi-view technique can solve these problems, since one map view can be used to perform real-time collaboration, and the other map view can be used for personal work. In this way, the work characteristics of real-time collaboration are ensured, and the work between users is not be interrupted. A novel-driven mechanism, the geo-event-driven method, was also used in our RCGIS. The geo-event-driven mechanism can provide users with a smoother collaborative perception and more natural interaction. However, the system development of multi-view RCGIS is more complicated than for the single view system, since the real-time collaboration between public and private views needs an efficient synchronization algorithm and collaboration strategy. Our preliminary work is mainly devoted to developing GIS real-time collaborative functions, and the concurrent interaction and response time of the system still require further improvement. Based on our long history of research on RCGIS, we believe that the multi-view technique and geo-event-driven mechanism can make GIS real-time collaboration more orderly and flexible.

The demo video is provided at http://101.42.107.198:3000

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

This work was supported by the Fundamental Research Funds for the Central Universities [grant number 2017XKQY019].