A Lightweight Collaborative GIS Data Editing Approach to Support Urban Planning

Abstract

Collaborative geospatial data editing is different from other collaborative editing systems, such as textual editing, owing to its geospatial nature. This paper presents a version-based lightweight collaborative geospatial editing method for urban planning. This method extracts editing data and generates a version for collaborative editing, which reduces the data size and thus allows for a high feedback speed. A replication mechanism is engaged to replicate a version for the client to freely edit, which ensures constraint-free editing in collaboration. Based on this method, realizing the fact that heterogeneous geospatial data and non-professional users are involved, a lightweight architecture, integrating web services, and component technologies, was proposed. This architecture provides a unified data access interface and powerful editing ability and ensures a high feedback speed and constraint-free editing. The result of the application of the proposed approach in a practical project demonstrates the usability of collaborative geospatial editing in urban planning. While this approach has been designed for urban planning, it can be modified for use in other domains.

1. Introduction

Collaboration, as one of the top 10 industry trends [1], has increasingly drawn the attention of researchers in computer science, geographic information science (GIS), and urban planning in recent decades [2]. The importance of collaboration in decision-making has been verified in many domains, such as urban planning, site selection, and resource management [3,4,5,6]. The fundamental goal of collaboration is to accomplish the task of having multiple stakeholders, including experts, professional workers, and administrators, work on the same data. The collaboration approach allows participants to work in different places or at different times [7]. In the field of urban planning, it is often integrated with GIS to form the so-called collaborative GIS, which strengthens the ability of participants to solve complex urban planning problems and the efficiency of their problem solving. One of the key issues lies in collaborative geospatial data editing.

Given the fact that many types of GIS software, such as ArcGIS, QGIS, and Leaflet, are the de-facto and mainstream tools for urban planning, there is a potential conflict between the complex functions of tools and a few functional requirements for GIS tools in urban planning, i.e., tools may provide a hundred functions, but only a few of them may be applicable in urban planning [8]. Moreover, facing the rapid urbanization process and rise of big geospatial data in the urban field, big data is becoming a hot topic, which is frequently discussed in urban studies and planning practices [9]. Collaborative editing of big geospatial data poses many challenges. The user feedback speed and editing constraints are two such challenges. In this paper, we focus on how to develop a new method and approach to constraint-free editing, with a high user feedback speed, for urban planning.

Therefore, a lightweight geospatial editing approach may be important for urban planning and a step in the direction of future developments in it. While the component-based and REpresentational State Transfer (REST)—based architecture of the GIS software facilitate data access and the editing of geospatial data, many open challenges remain, which are mostly due to the balance between the complex functions of tools and a few functional requirements for GIS tools in urban planning.

One challenge is the big geospatial data access and management framework in collaborative editing. Motivated by many theories and technologies for the handling of big geospatial data, more research works have been dedicated to developing REST-or web services-based geospatial data exploration or management methods to enable unified access for clients or servers [10,11,12]. While these two methods can support applications that are more sharable and reusable and have a loose coupling architecture, they have a low capability in geospatial data editing. The component-based development paradigm provides flexibility, extendibility, and powerful geospatial editing functions, which have been widely used in urban planning [13,14,15], agriculture [16], crisis management [17,18], and other domains, but without the unified data access ability. Therefore, integrating web services and component is a more practical approach.

Another challenge is to support collaborative big geospatial data editing. Empirical studies show that many works have been dedicated to collaborative geospatial data editing, but few of them concern the lightweight approach, which big geospatial data employs. Collaborative geospatial data editing, in which the spatial editing of an object may influence neighboring objects, is a complex challenge due to its spatial nature [19]. A number of approaches have been proposed to resolve collaborative geospatial data editing, including the lock mechanism [20,21], floor control [22,23], and operation transformation [24]. These methods can maintain the consistency of geospatial data very well, but they impose constraints on other users who are editing concurrently, such as an object lock that prevents other users from editing. Moreover, the management of locks and control of floor tokens are more complex [2]. In addition, they are used to work on the whole layer, with thousands or more objects, in collaborative editing, which may decrease the feedback speed of editing, particularly in the big geospatial data environment.

Therefore, in our research, considering the factors mentioned earlier, a lightweight collaboration framework, integrating web services and component techniques, is proposed to support powerful data editing and unified data access interfaces. This novel approach is developed based on the version schema and replication method to facilitate collaborative geospatial data editing. Collaborative editing should be lightweight to balance the complex functions of tools and a few functional requirements in urban planning and to avoid the editing operation constraint in collaborative editing tasks. With this solution, child versions of geospatial data are created in a spatial database and replicated for users (clients) through middleware. Clients can freely edit the local version of geospatial data. Based on this approach, a high feedback speed and constraint-free editing are achieved by the version mechanism. Meanwhile, the extraction of data from the database sharply reduces the data size for editing. Therefore, it is lightweight.

The contributions of this paper can be summarized as follows:

(1)

A lightweight method, based on the version and replication mechanism, was proposed to support constraint-free collaborative geospatial data editing, with a high feedback speed. Versioned geospatial data extracting from a geodatabase sharply reduces the data size for editing, and the data are replicated for clients to support constraint-free editing and a high-speed user feedback.

(2)

We developed a collaborative geospatial data editing approach, integrating web services and the component method, based on the proposed lightweight collaborative editing method, which are applied in urban planning.

The remainder of this paper is structured as follows. In Section 2, the background and work relating to collaboration editing are reviewed. Section 3 presents a definition of the approach, design consideration, and architecture. The development and implementation are described in Section 4. Section 5 covers the evaluation of our approach. A discussion of two key issues is presented in Section 6. Finally, Section 7 provides some concluding remarks and proposes some future work.

2. Background and Related Works

The theory and technology of GeoCollaboration constitute the basis of this paper. The investigation of the background of GeoCollaboration can provide cues for our lightweight approach. The literature review of existing collaborative editing approaches can indicate the state of the art of collaborative editing, and some inspiration also informs our research. In this section, we reviewed works from the literature concerning the theory and technologies that fall within collaborative editing in urban planning, which include GeoCollaboration and existing collaborative editing approaches.

2.1. GeoCollaboration

Closely linked to computer-supported cooperative work (CSCW), collaboration is regarded as an approach that helps to generate good decisions with multi-users [25], which is especially suitable for urban planning. A growing body of research has paid more attention to the design and development of collaborative GIS systems that support the group-based sharing, exploration, and interaction of geographic information for spatial planning and decision problems [26]. While the term, “collaborative GIS”, is not well-defined nor widely accepted [2,27], it has historically been linked with CSCW-based groupware, which provides the classification basis of collaborative GIS. Similar to general groupware, collaborative GIS may be classified into four categories, based on their time synchronization and users’ location (Figure 1) [2,28]. Synchronization means the same time, and asynchronization represents a different time; the same location means centralization, and different places are for distributed locations. Asynchronous collaboration eliminates real-time cooperation between users, which allows for collaboration at different times and speeds and multi-stage workflows [29]. Users collaborate, as needed, by exchanging information, possibly over a long period of time and multi-stage workflow [30]. In contrast to synchronous collaboration, participants have full control over their own applications and information.

There have been many collaborative research studies that focus on textual data [19]. Programmatic source code management is a typical asynchronous application, and Wikipedia is the largest scale asynchronous application. One of the team members can write/edit the same file freely at any time. However, collaborative geospatial editing is different from document or textual collaborative editing systems because of spatial characterization and spatial dependence [19,31]. Spatial editing on one feature must influence that feature and neighboring features.

The National Centre Geographic Information and Analysis (NCGIA) proposed an earlier concept of collaborative GIS for Initiative 17 on collaborative spatial decision-making [32]. The purpose of this initiative was to support groups of decision-makers in order to generate solutions and to reach informed decisions. Many later studies focused on developing frameworks, methods, and designs that support the development of collaborative GIS tools or systems in various application areas. For example, a prototype system supporting collaborative urban planning was designed [33]; for emergency planning, a practical system was developed [23]; Jing et al. [34] and Sun et al. [26] built a collaborative GIS for government workflows; and Han et al. developed a web-based system for collaborative mapping [35]. Butt and Li used map sharing to support public participation in municipal planning [36].

2.2. Collaborative Editing Approaches in Urban Planning

Urban planning cannot be achieved by one single person. Instead, it must result from a collaborative process [3]. While the final path to decision-making may vary between different projects, five common stages, shown in Figure 2, generally include: Problem definition, problem analysis, alternative solution generation, alternative solution evaluation, and implementation [29]. Stakeholders may be involved in some stages. For example, administrative staff may contribute more in the problem definition, while the public may be involved in the problem analysis and solution generation phase. Collaborative geospatial data editing should be included in the first four stages, and iterations are often necessary to adjust solutions and decision-making.

For collaborative geospatial data editing, there are three mainstream methods, including the lock mechanism, floor control, and operation transformation [2,37]. The locking and unlocking operation affects the user response speed in geospatial editing, which is crucial in relation to big geospatial data. The determination of lock data granularity is the second challenge. Some works differentiate the object-level, query filter elements, and other granularity. Guo et al. and Li et al. used object-level locking to control the visibility and operability of different granularity objects [21,38]. Ross developed a fine-grain lock on query filter elements for collaboration [20]. As another approach, many works have been dedicated to the floor control mechanism in various collaborative GIS environments [22,23,29]. The floor control approach engages the token to allow only one user to have the highest control and operation power. While the lock and floor controls are the two most used and easily implemented mechanisms in concurrency control, they impose some constraints on the objects, such as a lock on concurrent objects [2], which may decrease the feedback speed of users. Different from the above two approaches, which typically focus only on geospatial data, the operation transformation approach is developed based on the management of geospatial operation actions. Each spatial operation in a collaboration environment may change the same objects and disturb the concurrent operations. A spatial operation dependence graph was proposed by Kang to maintain synchronous consistency [31].

Compared with the aforementioned methods, a version-based approach has gained more attention in collaborative editing, owing to its ability in the track-logging of all editing activities and data changes. Cyclopath is a web-based asynchronous computational geowiki that enables cyclists to map bike routes collaboratively [39,40]. Collaborative editing in crisis-mapping, based on OpenStreetMap (OSM), was published [41]. The editing solution is based on the OSM Tasking Manager, which is similar to the floor lock solution. Some types of OSM official editing software, such as iD and JOSM, are based on the Tasking Manager, with a block spatial boundary. These two blocking collaboration solutions constrain the editing activities falling within certain spatial boundaries. Another version-based system, called Ethermap, was developed for disaster mapping [19]. Unlike blocking collaboration across all functions, Ethermap supports collaboration anywhere by reviewing all editing activities. Some types of mature GIS software provide a version plugin. For example, QGIS has a versioning plugin to support the management of working copies [42].

In general, most existing geospatial collaborative editing approaches suffer from drawbacks. First, the editing constraints and management of many locks or tokens involved in the existing solutions may make the approach heavy and disturb the non-professional users. Facing the stronger requirements for geo-information, urban planning projects engage many dimensions of geo-information, including economic, social, and environmental information [25], which requires unified data access interfaces. Another thing is the multiple stakeholders, including non-professional users, who are involved, such as urban administrators, urban planners, people from the public, and experts. Therefore, a lightweight approach to collaborative editing, with a unified data access interface and constraint-free editing, is needed in urban planning. Second, the existing approaches often carried out spatial operations on all of the data, which make data transfer and operation heavier. They have a low feedback speed when the geospatial data sharply increase. For example, a collaborative map editing conceptual framework, based on the whole argumentation map, was proposed for wind farm sites [3]. An approach to the collaborative editing of geospatial data, called Ethermap, was developed for disaster mapping [19], which engaged the version mechanism. However, the version employed was also based on all of the data and thus had a heavier computation.

In this paper, the proposed architecture, integrating web services and component technology, provides lightweight data access functions, with a unified interface. Then, a version approach is proposed to reduce the data size for editing and improve the feedback speed. The replication of a version for local clients enables constraint-free editing for users, i.e., without the constraints imposed by locks or tokens. Therefore, the proposed approach, based on versioning, is a lightweight approach.

3. Approach to Collaborative Geospatial Data Editing

In this section, we define the collaborative editing approach. The basis of our approach is the lightweight collaborative editing method, based on a version and replication. The approach design considerations and architecture design were introduced from the technological perspective.

3.1. Lightweight Collaborative Editing Method Based on Versioning and Replication

Within urban planning processing, collaboration data editing between different stakeholders is of crucial importance. While many approaches were developed and demonstrated to be more suitable approaches for collaboration, the difficulty in maintaining feature consistency is challenged, particularly when editing a very large volume of geospatial objects in urban planning.

The term, “lightweight”, refers to the conceptual weight of collaborative editing. In our method, lightweight means relatively simpler or faster and constraint-free editing among stakeholders, which is similar to the way in which the term is used in the information technology domain, where it is applied to a program, protocol, or device that provides a flexible and portable application. Specifically, our proposed lightweight method sharply reduces the data size by a version mechanism, unlike the traditional approach. Moreover, it supports constraint-free collaborative editing, with a local version for clients.

The goal is to develop a lightweight collaborative editing method that provides a high feedback speed and supports constraint-free data editing. To achieve these goals, the proposed method consists of two main parts:

• The extraction of the related geospatial objects from the working geospatial layer and creation of a version; and
• The use of a master-replication concept to ensure free editing operations among all stakeholders.

While a large amount data is necessary for urban planning, only parts of layers or objects are essential for collaborative editing. Therefore, only editing these essential objects can highly reduce the data size and improve the user feedback speed for collaborative editing. In our approach, the two steps, extraction and version generation, are designed to support efficient editing.

Extraction means the indexing, searching, and extracting of essential geospatial objects from the geospatial database. To fulfill this task, some mature geospatial indexing and searching algorithms are engaged to solve big geospatial data searching. The version is a logical concept for organizing the extracted geospatial objects, which is a replica and subset of geospatial data. The essential geospatial objects include objects of the working layers, instead of the whole layers. For the version generation, a file formation is employed to store these data. Considering the comparability between the server and client management and editing tools, the ESRI SHAPE file format is adopted as the version file format. The extraction and version generation is created on-demand, according to the urban planning project, which is determined by the parameter, CaseID.

A master-replication concept model entails that the master version is replicated for clients in order to support constraint-free editing. The version is generated by the servers in consideration of the master version of the data. Meanwhile, the replication entails that the replica of the master version can be transferred to clients for collaborative editing, and it is named the child version. Because the editing is of the local replica, the editing must be constraint-free, which helps to improve the user feedback speed. The relationship between the master and child version is a one-many relationship, which means that one master version could be replicated by many copies for many users. There is one middleware or functional module that supports the management of replications.

Based on the above definition of our approach, Figure 3 sketches the general workflow of using the proposed approach for collaborative editing. Users can request data concerning the urban planning project, CaseID, through the graphic user interface (GUI). The detailed steps are as follows: (1) The user request is parsed by the Map Server middleware, and the request is sent to the geospatial database through a spatial database engine (such as ArcSDE); (2) the data retrieval module executes a spatial query to generate a child version, and the child version is formatted to a common format, such as a ESRI SHAPE format; (3) the child version is then downloaded by the client using the Map Server file copy functions, and the status information of the child version in the server database is then changed to “downloaded“, as a message on the server module, which is used to inform users. All the child versions from the same master version are unique for every client. Therefore, all users can freely edit geospatial data on their local machines. (4) Finally, when the editing is complete, the child version is uploaded to the server, and the status information is changed to “uploading”. The status information can be updated by other users’ requests, communicated via the message server middleware.

3.2. Approach Design Considerations

Urban planning is a complex process that is composed of several kinds of spatial operations, such as data access, data visualization, spatial editing, and planning schema analysis. Each process may require many people to work with specific geospatial data, according to the urban planning project. For example, “planning and siting” work includes more than four departments’ collaborative work, including the land management department, planning department, municipal department, and environment department. Therefore, the urban planning approach must support flexible and unified access to the heterogeneous spatial data at any time in order to operate the spatial data and provide high-speed feedback in editing operations. Thus, the lightweight architecture should devote more attention to this.

Following the above analysis, the GIS data editing approach that supports urban planning is proposed to satisfy the following requirements:

(1)

Designing a lightweight architecture approach that facilitates geospatial data access and editing;

(2)

Supporting the data exchange standards (e.g., XML) and GIS standards of the Open Geospatial Consortium (e.g., a web map service);

(3)

Providing free spatial collaborative editing and high-speed feedback to support urban planning.

To realize the above requirements, an architecture, integrating web services and components, was carefully designed. To satisfy requirement (1), the web service techniques are engaged to support flexible and unified data access. Meanwhile, the component technique supports powerful geospatial data editing and version management. Open standards are required to support multi-source urban planning data, including geospatial data and non-geospatial data. Therefore, the adoption of open standards (e.g., XML and a web service) is necessary to exchange data, so that the features (e.g., extendibility, open interfaces, ease of access, and low maintenance) of modern software can be obtained. In our design, the Web Mapping Service (WMS) and Web Feature Service (WFS) standards of the Open Geospatial Consortium (OGC) are employed to integrate an internet map service. To satisfy requirement (3), the versioning mechanism is proposed to ensure free editing and high feedback speed. Only the related objects from the version data are sub-extracted from the geodatabase, so the transferred data is sharply reduced, providing high-speed feedback from the user. The version can be transferred to a local disk for local spatial editing, which ensures constraint-free editing.

3.3. Approach Architecture Design

Urban planning is a workflow, from a problem definition to decision-making, in which the collaborative GIS has been increasingly involved [14,43]. A lightweight GIS-based collaborative geospatial data editing system was designed and developed to satisfy the aforementioned concerns. The three-tier C/S architecture is shown in Figure 4, which includes a server tier, middleware tier, and client tier. Detailed information concerning the architecture is introduced in this section.

The server tier is the data center, which includes the urban planning database and geospatial database. Urban planning data are stored in a relational database, while geospatial data are stored in a geospatial database (as shown in

Table 1. Primary data sets in urban planning.

Database	Name of Dataset	Layers or Tables	Attribute Data
Spatial database	Basic geographic data	Road, River, Building, Topography, etc.	Name, category, code, grade, etc.
	Urban planning geospatial data	City planning	Name, code, date, etc.
		Road planning redline	Type, width, date, etc.
		Pipe planning data	Type, code, category, etc.
	Online geospatial data information	Baidu Map; Tianditu Map	Name, coordination, level, url, etc.
Urban planning database	Planning business dataset	Siting business	Name, code, date, power, state, etc.
		Planning permit of engineering	Name, code, date, power, state, etc.
		Land use permit of engineering	Name, code, date, power, state, etc.
	Archive project dataset	City planning, land use planning	Type, function zones, date, planning conditions, etc.
	Economic planning data	Census population data	Name, age, sex, work class, occupation, education, native country, etc.
		Economic data	Category, date, economic volume, etc.

). A service module is also contained in the server tier to integrate other online geospatial data with the specifications provided by the OGC’s Web Map Services (WMS) or Web Feature Services (WFS). As mentioned in Section 3.2, a large number of data formats (e.g., binary, text-based, geometry-based, or geospatial data) and data access interfaces cause heterogeneity. Using the traditional solution, to access these data, they need to be manually adapted by a customized functions module. Because the service module in our approach provides a unified data access interface, it is a relatively simpler or lightweight approach, without an extra code for data access. On the other hand, the version generation module deployed in the server tier, which is in charge of data extraction from the database and the generation of the version, is another important element of the lightweight approach. The version is a subset of the database that enables a few parts of the data to be edited, unlike in the traditional database schema. The lightweight approach is achieved by reducing the editing data size, while enabling a high feedback speed in editing. The extracted data, according to the urban planning project, caseID, are components of the master version. Many child versions, which are obtained by the collaborative participants, can be derived from one master version. Therefore, as shown in Figure 4, the relationship between the master version and child version is one to many (1:n).

The middleware-tier is the container of all of the middleware components, such as the “Map Server” and “Message Server”. The Map Server middleware aids in the version management, which interacts with the database and editing modules to support proposed collaborative editing approach. Meanwhile, the Message Server middleware is responsible for the version status update for users. The Message Server exchanges status information with the Map Server middleware. When the status of the map objects is updated by the Map Server, the Message Server middleware can update the related information for users. Other types of middleware can also be designed and deployed here, according to new business requirements, so the architecture is scalable. The Map Server is designed to bridge the gap between the server tier and the client tier by the CaseID parameter, as shown in Figure 4. The versions are requested and submitted by the Map Server, with CaseID, and transferred between the server and the client.

The client tier is the graphic user interface (GUI) shared between users and the system. On the client side, a standalone application is deployed on each client machine to support urban planning activities. In this architecture, all collaborative editing functions are implemented, on the client side, to support urban planning business module activities, and the editing is conducted on a child version. Urban planning business modules support the urban planning business workflow, from one stage to the next stage. Collaborative geospatial data editing is invoked in some steps of the workflow. The revised child version will be transferred and uploaded to the server side upon the completion of editing.

4. Development of a Planning Management System—PMS

4.1. Implementation of the System

Based on the above architecture, a system, called a Planning Management System (PMS), was implemented to enable stakeholders (an urban planning officer and the public) and experts to collaboratively edit an urban planning project. The implementation framework is shown in Figure 5. The PMS system has been adopted by Suzhou Urban Planning Bureau, Jiangsu Province, China and applied in their planning projects. The system has about 89 users and more than 20 GB of urban planning project data and 50 GB of geospatial data.

From the user perspective, PMS was implemented principally in consideration of the users’ knowledge and experience. Each module of the system is enveloped by its tier, i.e., the request module and file copy module are developed in the middleware tier. This ensures that the designed architecture is transparent for the end users. From the technological perspective, the implementation of PMS made full use of mature technologies, such as ArcGIS, Oracle, and program development tools. Oracle was selected to store and organize the urban planning attribute data and geospatial data. ArcGIS of ESRI Inc. is used to support geospatial data access and editing. Microsoft ActiveX Data Objects (ADO) and program development tools are used to develop urban planning functional modules.

4.2. Main Functions

The system provides users with powerful management and editing functions, with friendly GUI, as shown in Figure 6. During the design of GUI, most elements, such as icons and functions, widely referenced the ESRI ArcGIS software and AutoCAD software, which are the conventional tools for urban planning.

The main GUI includes the following elements: (1) Geospatial data editing tools (labeled as 1 in Figure 6) are included. The toolset consists of map-mode tools, map-draw tools, map-edit tools, and location tools. (2) Map navigation tools, such as “zoom in”, “zoom out”, and so on (labeled as 2), are included. (3) A map layer control dialog (labeled as 3) is included. The map layer’s table of contents includes the reference map/image (such as DOM and DLG), the urban planning draft and the collaboration works on the urban planning draft. (4) Map view windows (labeled as 4) are included. The view frame is designed for the viewing of geospatial data.

(1) The spatial editing scenario.

As shown in the collaboration workflow (Figure 3), collaborative editing may include, briefly, two steps: (1) The parameter, CaseID, is the main input value, and the spatial coordinate parameters are optional items. The system parses input parameters and invokes the map view in the planning project location. (2) Draw and Annotation tools are used to process this task. Figure 7 shows the result of draw operations and annotation operations. First, a polygon is drawn on a map with the Draw tool and is annotated with an area value inside (labeled as 1 in Figure 7). Then, the Annotation tool is used to label the coordinates of four boundary points (labeled as 2). This function supports the auto-layout of the annotation element and the manual tuning operation of the annotation layout.

(2) Middleware (Map Server) GUI.

The Map Server is a type of middleware designed to communicate between the server and the client. The Map Server consists of the following modules: (i) A request parsing module, responsible for the parsing of input parameters (CaseID); (ii) a data retrieval module, which retrieves the child version metadata of the target data generated by the server; (iii) a file copy module, used to download and upload child versions; and (iv) a status update module, which updates and manages the version status. Figure 8 shows the graphic user interface of the Map Server. The download and upload information are recorded, as shown at label 1 in Figure 8. The module configuration page is labeled 2. Information concerning the child versions in the local machine is labeled 3.

5. Evaluation

Reviewing the collaboration-related literature and systems, many methods that assess the quality and usefulness of systems or applications were found. A survey paper concerning a groupware system evaluation investigated the main evaluation methods of a server, including a user study, questionnaire, etc. [44]. One example is the user study evaluation of a collaborative system that was conducted by Butt and Li [36]. However, inspired by related work from Fechner (2015) and Hu (2015), we adopted the questionnaire, as the evaluation method.

The questionnaire and its score statistics are shown in

Table 2. Summary of the statements and statistical results.

No.	Statement	Average	Median	Standard Deviation
Q1	I was satisfied with the user feedback speed.	8.25	9	0.87
Q2	I don’t need to wait to edit the data in collaboration.	8.33	9	1.07
Q3	It is a small dataset to edit.	8.45	9	0.93
Q4	The system effectively helped me to access the heterogeneous data.	7.75	8	1.06
Q5	I can receive status information about data in a timely fashion.	7.75	8	0.87
Q6	The collaborative geospatial data editing enables me to complete the task more efficiently.	8.00	8	1.04
Q7	It is easy for me to use these tools for editing.	7.50	7	1.09
Q8	I can see and know the version for my task.	Yes	Yes	Yes
Q9	Activities of other users did not interfere with my work.	Yes	Yes	Yes
Q10	The number of objects that I edited.	33.75	30	/

. There are ten questions regarding the usability and effectiveness of our approach. As for the score of questions, seven questions used the ten-point Likert scale, from 1 to 10, to note the degree of users’ agreement or disagreement with the functions. Two are yes-no questions. The last question is an open question, which requires that the participant fill the number of edited objects. In the design of the questions, usability, functionality, and user experience were considered.

The participants and scenario procedure were also carefully designed. The stakeholders in collaborative editing have different kinds of knowledge. Therefore, 10 students with geographic or urban planning knowledge were recruited from our university, which included 8 undergraduate students and 2 graduate students (two of which are co-authors of the present paper). In addition, two planners were invited to evaluate the approach by filling in the same questionnaire. The designed scenario is building or road editing within the university campus. The users can randomly add, delete, or edit objects in a map. As for the evaluation process, instructions concerning the system are first provided. After that, the users can edit the map twenty minutes, after which time they are asked to fill in the questionnaire.

As for the result of the questionnaire, we first consider the number of edited objects, as shown in the last question. The minimum count of objects is 23, and the median is the 30. In our evaluation, this number is sufficient for our approach evaluation.

The first two questions relate to the user feedback speed and constraint-free collaborative editing. The higher the average score and the lower the standard deviation, the more the participants strongly agreed that our approach can achieve constraint-free collaborative editing with a high feedback speed.

Four questions, from question 3 to question 6, concern the functions of our approach. Question 3 is concerning the reduction of the data size in editing by the extraction and generation of version data. While one user was unsure about it, the other users had a positive attitude toward it. Questions 4 and 5 relate to data access and collaborative awareness relating to the version. The score indicates that these functions are useful in collaboration. Meanwhile, the result for question 6 enhanced the usability of our approach in collaborative editing.

Questions 7, 8, and 9 concern the users’ experience. The design of these questions addressed the users’ awareness relating to the version mechanism, user interface design, and collaboration between users. The result for question 7 shows that users can easily use the system, which has a user-friendly interface. The positive answer to questions 8 and 9 demonstrates the usability of our approach in the system.

While a high score was achieved in the results, some misunderstanding and misleading operations existed in the evaluation procedure. This indicates that our system requires further improvement.

6. Discussion

We proposed a novel approach for collaborative geospatial data editing, based on the version mechanism. Constraint-free editing with a high feedback speed is achieved in our approach. In this section, we discuss the concurrent control and system architecture, from the point of view of user feedback speed and user constraints in collaboration editing.

6.1. Concurrent Geospatial Data Control

Concurrent control is a key issue in any collaboration system [37]. Particularly, the long-term running of one project increases the possibility of concurrence in urban planning. Collaborative GIS encourages the development of new methods to support free multi-user interaction. The lock mechanism, floor control, and operation transformation are engaged to compare their concurrency with our proposed approach.

Our proposed approach supports flexible editing, without constraints, which is different from the aforementioned three approaches. While the lock mechanism is a classic method in concurrent research, its application in geospatial data editing requires further improvement, owing to the complex nature of geospatial data. To maintain the concurrence of geospatial data, more complex computational models must be developed, which require further validation between objects and may decrease the feedback speed. For example, the shared lock and exclusive lock are the most widely used categories, in which data are locked and cannot be read or written. As for the floor control approach, only one user with the highest control and operation power is allowed to edit. For concurrency, this admin user must repeat the other users’ editing operations, which is tedious and often prone to errors. However, in our proposed approach, the version is a subset and replica of the editing data, which can be download by clients for free editing, without any constraints. As shown in Figure 9, the master version is the stub data of the editing data, extracted from a spatial database by the CaseID parameter. Child versions are the heritors, which can be transferred to the client. All child versions used by every client are unique and can be freely edited, with a high feedback speed. When submitting to the geodatabase, if there is no conflict, the child version is saved to the database directly. Otherwise, the administrator coordinates related users to maintain data consistency.

6.2. Lightweight System Architecture

As mentioned above, many stakeholders and various heterogeneous data are engaged in urban planning. Existing geospatial data editing methods are mostly based on the full functional GIS software, such as ArcGIS and QGIS. However, a few functions are required. In addition, the existing approaches often work on the whole data, but a few objects are essential for editing, which increases the workload of the data transfer and validation. Therefore, the partial functional requirement and complex functions of the existing GIS software do not match. A practical and lightweight approach is necessary to balance the lightweight functional requirements and heavy tools.

There are a large number of data formats (e.g., binary, text, or other software file formats) and data access interfaces (e.g., FTP, cloud storage, or web services) in urban planning [5]. In the traditional approaches, data access components or services for each data format are developed successively, which gives these approaches a poor scalability and poses difficulties relating to software maintenance. Our approach integrates web services and component technologies. The web service provides the unified data access interface, which allows the manual adaptor development to be avoided. Meanwhile, the component technologies are employed to edit the geospatial data. Thus, the combination of these techniques enhances the advantages associated with both. As for the editing of data, methods to reduce the essential data can decrease the data size for complex validation. Data transferred between users is heavily reduced by the versioning mechanism. There are only a few objects involved in urban planning projects. The version mechanism supports the extraction of related data and generates a replica of these related objects, as a version, to reduce the amount of data that needs to be transferred. Therefore, our approach provides a lightweight architecture for data editing. However, the existing approaches and literature are rarely concerned with this architecture. Finally, the architecture supports constraint-free editing, with high-speed user feedback, because it allows clients to edit independently. In the lock and floor control method, users are constrained to edit concurrent objects, since other collaborative users lock these objects.

7. Conclusions

A lightweight method based on the version and replication mechanism was proposed in this paper. A version is a subset of geospatial data, which reduces the data size in editing. A replication of the version for clients to edit supports constraint-free editing. Therefore, constraint-free collaboration with a high feedback speed is achieved by this method. Based on this method, an architecture, integrating web services and component technologies, is designed to enhance the advantages of these services and technologies for the lightweight approach. The former provides the unified data access interface, and the component technology has a powerful editing ability. Therefore, facing the heterogeneous and big geospatial data in urban planning, this architecture provides a lightweight design for geospatial data operation. This approach was evaluated by a questionnaire method and its usability was demonstrated by a practical application in the urban planning department.

However, our approach still has some room for improvement in future work. The updating of the user interface and system environment to a WebGIS system is urgently needed. By developing new technologies, WebGIS will also be able to support online geospatial data editing, with powerful editing functions. Secondly, the communication module for real-time concurrent conflict reconciliation could be improved. While a message middleware was developed in our approach, it only works for users working online. That is, the concurrent user cannot receive messages when he/she is offline. Therefore, we also plan to develop a communication module integrated with social media software for the immediate notification of concurrent users.