SUPPORTING URBAN DESIGN WITH OPEN SOURCE GEOSPATIAL TECHNOLOGIES

: Urban designers collect information about a city or neighborhood, design improvements so that the city is functional and pleasant to live in, and communicate these improvements to relevant stakeholders. The use of space and the spatial relationships between physical features play a significant role in urban design, therefore much of the information that is collected and manipulated is georeferenced. We followed a scenario-based approach for collecting requirements for urban design projects. Functional and non-functional requirements were categorized into data collection, data storage and management, and data visualization. Subsequently, we reviewed and evaluated open source geospatial tools that can be used for the collection, storage, manipulation and visualization of geospatial data in urban design projects. Based on the evaluation, we propose an open geospatial toolbox for urban design projects. The results are equally applicable for researchers and professionals in other disciplines who collect data at the neighbourhood level.


INTRODUCTION
The role of urban designers is to shape the physical features of a city with the goal of making the city functional and pleasant to live in. For this the urban designer has to gather information about the current situation, design improvements, and communicate these to stakeholders (Parsaee et al., 2015;Rautenbach et al., 2015). Urban design tends to focus on the neighborhood level, while urban planning looks at the city as a whole (Rautenbach, 2017). The use of space and the spatial relationships between physical features play a significant role in urban design, therefore much of the information that is collected and manipulated is georeferenced. This calls for tools and technologies that urban designers can use to collect, manipulate and visualize the information.
In this paper we review and evaluate open source geospatial tools that can be used for the collection, storage, manipulation and visualization of geospatial data in urban design projects. Based on the evaluation, an open geospatial toolbox for urban design projects is presented.

METHOD
We followed a scenario-based approach for collecting the requirements. Scenarios describe possible events that can reasonably take place. Developing scenarios stimulates thinking about possible occurrences, opportunities, risks or actions (Jarke et al., 1998). Scenarios are an effective means of communication between users and stakeholders when requirements have to be identified from real world experiences (Sutcliffe, 2003). In agile software development methods, they are referred to as user stories (Riedemann and Freitag, 2009). Four researchers were asked to explain to us how they collect and use data at the neighbourhood level for their urban design projects. Their backgrounds were in spatial planning, architecture and business management. By analyzing the three scenarios, we determined both functional and non-functional requirements for the toolbox.
Based on the scenarios, we compiled a set of functional and non-functional requirements, and categorized them into requirements related to data collection, data storage and management, and data visualisation respectively. Following a review of available tools, the following open source geospatial tools were evaluated against these requirements: 1) Data collection: EpiCollect5, Arbiter, GeoODK and Field Papers 2) Data storage and management: GeoServer, MapServer, GeoNetwork and GeoNode for data storage and management 3) Data visualisation: MapWindow5 and QGIS Each category of tools was evaluated against requirements relevant to that category, e.g. for data storage and management, the user should be able to upload geospatial data, upload newer versions of the data, create and edit metadata about the data, and share the data in various formats using web services. Furthermore, the evaluation results show how tools meet individual requirements, i.e. we did not exclude tools that meet only one of several requirements.

Scenario 1: Neighborhood improvements
The first scenario involves an urban designer who is requested to guide and advise the local municipality on improvements in a neighborhood that has become dilapidated over time, and therefore unsafe. For this purpose, it is necessary to understand how people move through the neighborhood every day. The transport network, including both roads and pedestrian walkways, need to be captured. Furthermore, locations of gathering places and physical features that influence movement through the neighborhood have to be recorded.
The urban designers usually identify key areas that would aid in understanding the neighborhood. These areas are marked on a map or aerial image before immersing themselves in the neighborhood. They take the map with them for orientation and while they are in the neighborhood, they want to record anything that could help to understand the current state of the dilapidated neighborhood. These could be location-based notes, photos or even voice notes. Back in the office, the information is visualized on a single map and studied in order to better understand the neighborhood.
Regular updates on the data collected, including maps, are presented to the client in order to discuss and assess possible solutions. Ideally, the urban designers would like to share the and data and maps with the client, so that they can review them at their own leisure. More than one field trip may take place, by more than one person, and relevant metadata needs to be associated with the data that is collected.
The final product of the study is a comprehensive report that describes the findings and proposed solutions. Maps are included to demonstrate the findings and to assist the client with visualizing the proposed solutions.

Scenario 2: Identifying crime hotspots
In the second scenario, the aim is to identify crime hotspots in a neighborhood and to propose preventative crime measures through environmental design (CPTED). CPTED is a crime prevention and design-based concept founded on the idea that proper design and effective use of the built environment can lead to a reduction in crime incidences.
Once again, a map is prepared before going into the field. In this case, the map could already show crime hotspots if location-based crime incident data is available for the neighborhood. In the field, the urban designers will record anything that could invite crime, such as the intended and actual use of physical features in the built environment of the neighborhood: a walkway could be intended for pedestrians but is actually used as marketplace by informal traders or as meeting place for homeless individuals. Such mismatches between intended and actual use may create opportunities for crime. Other features of the environment that could induce crime include lack of access control, insufficient lighting or overgrown or abandoned areas, and need to be recorded by the urban designer, e.g. with location-based notes, photos or even voice notes. The recording of such information should be quick and hassle free so that the designer can concentrate on the environment, and not get sidetracked by technology challenges.
In this scenario it would also be useful to share the data that is collected with the client. Additionally, there is often a multidisciplinary team, e.g. comprising urban designers, traffic engineers and criminologists, who collect and analyse data when planning a neighborhood improvement. Sharing and metadata would be beneficial to their collaboration.

Scenario 3: Retailers
In the third scenario, the urban designer needs to study the environment of informal traders and entrepreneurs in lower income neighborhoods in order to come up with proposals for increasing their profits through changes in the neighborhood. Informal traders make up a significant portion of the South African retail, therefore heir business success can make a significantly positive contribution to the growth of the economy of South Africa (Woodward et al., 2011).
The location of the informal traders, how they are arranged and how their customers move through the area needs to be understood. Once again this requires location-based information. It is also important to understand how the situation changes through the day. The information can be used to identify weaknesses in the spatiality of the neighborhood, or the locations of the informal traders, which can be addressed by specific interventions.

Data collection
A user needs to do the following in the field: -Prepare a map before going into the field.
-Record location-based observations in the field. These could be in the form of text, photos, videos or voice notes. -Record metadata about the observation. Preferably, this should be done automatically.
Since the urban designer will be walking or driving through the neighbourhood, collecting data should be simple and hassle free. Furthermore, urban designers are not necessarily tech-savvy, therefore usability is important. Finally, there may or may not be internet connectivity in these neighbourhoods. Therefore, it should be possible to do offline data collection. The data collection tools are typically used by individuals in the field.

Data storage and management.
A user needs to do the following: -Back at the office, where there is internet connectivity, a user will upload the data collected in the field. -View the observations on a map with a backdrop, either of a (raster) satellite image or (vector) topographic information.
-Edit the data, e.g. move an observation, or add additional information to an observation. -Organize the observations into folders.
-Search for observations, based on metadata and keywords. -Share the observations with project team members or clients, either as raw data or on a map.
For the data sharing, and also to protect the urban designer's intellectual property, authorization and authentication with a user login are required. Once again, functionality should be simple to use, i.e. a GIS software that requires professional expertise is not the solution here. This functionality needs to be scalable to teams of up to twenty people.

Data visualisation.
A user will want to do the following: -Prepare a map that can be used to communicate findings to the client. -Add additional layers of information to the map.
-Export the map, e.g. as JPEG or PDF, for inclusion in a report. -Basic spatial analysis, such as measuring distances, creating buffers around features or counting features within a specific distance.
Here again, usability and ease of use are important. One can assume that the urban designer will have internet connectivity that is suitable for cloud-based applications. This functionality will also be used by more than one team member at the same time and therefore needs to be scalable.

Brief background of evaluated tools
Even though a wide variety of tools is available, we only considered open source tools, as other tools would affect the manner in which the application may be used and also any derived implementations may be distributed.
EpiCollect5 is an open source cross-platform data collection application with a mobile and web interface. On the web interface, users can set up a project and create a custom form that will be used to collect data. The form builder allows the user to add various types of input fields, such as text, dropdowns, photographs, audio clips and GPS locations. The mobile application can then be used to connect to the project and collect data using the form developed. Offline data collection is possible. The web application also allows the user to view and edit the data after collection, and to export the data as a CSV file. EpiCollect5 is very easy to use and the interface is very intuitive. The biggest drawback of using EpiCollect5 is that the user can only collect point data.
Arbiter is an open source Android mobile application for the collection or editing of geospatial data. Arbiter allows the user to add a web map service (WMS) to the OpenStreetMap (OSM) backdrop and then either edit the existing features or add new features. Unlike EpiCollect5, the user can capture points, lines and polygons, but there is less focus on attribute data. Arbiter can be used offline and is easy to use, however, the screen size of mobile phones might be an issue when collecting certain (e.g. larger) features.
GeoODK is a specialised version of Open Data Kit (ODK) that adds the ability to capture geospatial data (i.e. points, lines and polygons). GeoODK provides a form builder with a wide variety of input options or the ability to transform an XLS file to a form that can then be loaded on the Android mobile application. Data can be captured offline and then exported as a CSV or KML. GeoODK also has a web platform that allows the user to view the data and connect to other services, such as Google Spreadsheets or ArcGIS Online.

Field
Papers is an open source web application for creating a printable atlas (set of maps with an index map) of a specified area from OSM. The maps can then be used in the field to manually annotate changes and add notes. After completion of the field work, the atlas is scanned and added as a backdrop to JOSM where the user can digitise the annotations. Field Papers is very easy to use and requires little to no technical expertise.
GeoServer and MapServer are open source cross-platform web applications that allow users to publish and share their geospatial data. GeoServer and MapServer expose geospatial data as standard OGC web services, such as WMS, web feature service (WFS), web processing service (WPS) and web coverage service (WCS). These are server applications with which general users would have little to no direct interaction; they would rather connect to these services through other applications, such as QGIS or GeoNetwork.
GeoNetwork is an open source catalogue application that allows users to manage geospatially referenced resources, such as data or documents. GeoNetwork's focus is on the metadata (e.g. ISO 19115, ISO 19119, ISO 19110 and Dublin Core) of these resources that can be harvested from various sources, such as a GeoServer or MapServer. The resources available in the catalogue can then be searched using various methods, for example, using keywords or bounding boxes. GeoNetwork allows the user to view the data using OpenLayers3 with OSM as a base map add annotations and print the final map.
GeoNode is an open source geospatial content management system. GeoNode and GeoNetwork have the same type of functionality, but with GeoNode the metadata is often extracted from the data itself and how the data is used. Additionally, with GeoNode, the user can load data directly into the application and not just provide links to the data. Users can create interactive maps with GeoNode that can be shared.

MapWindow5
and QGIS are open source desktop GIS applications that can easily be extended with plugins. MapWindow5 is only available on Windows, while QGIS is cross-platform. Both applications are user-friendly and have a large user base with documentation. QGIS allows users to import additional formats (e.g. WFS, CSV and GeoJSON) that MapWindow5 does not support.

Evaluation results
An overview of the evaluation results is available in Table 1.
We have indicated if a functionality is core (i.e. the main purpose of the application) or additional (i.e. add-on for achieving the main purpose). For example, in GeoServer the core functionality is to publish datasets and to expose them as OGC web services, however, GeoServer also provides a layer preview option that allows the user to view the layer to be published to ensure that the layer is correctly published. This layer preview is an add-on functionality for publishing a layer, and not fully-fledged viewing functionality, as available in other applications such as QGIS.
The four tools evaluated for data collection serve two different purposes: 1) capturing observations and the associated attributes (EpiCollect5, GeoODK); and 2) updating geospatial features in the field (Arbiter, Field Papers). With tools such as, EpiCollect5 or GeoODK, the user builds a custom form to collect specific information observed, for example, for a household survey the user can capture specific information, such as the address, household size and type of dwelling. EpiCollect5 can only capture this observation as point, whereas GeoODK can use points, lines or polygons. The core functionality of EpiCollect5 and GeoODK is to collect data, but both applications provide users with additional functionality that allows them to view the data captured in the web interface before downloading the data. The web interface does not allow for any data editing, only viewing. The data collected can be exported in various formats, such as CSV or JSON. Although both applications are popular, we felt that EpiCollect5 is more user-friendly and it has the additional benefit of the free online service. However, users might require their own installation if they work with sensitive data.
Arbiter and Field Papers have a very different focus again. With these tools, users can add or update geospatial features, for example, mapping land use or buildings in an area. Arbiter allows users to edit a specific layer that is added to the map using a WMS, thus the data is actually changed at the source location. The user can add or edit the available attributes in the layer. Field Papers can be scanned and viewed in JOSM where the users can digitise their field observations and these edits would reflect on OSM. Attributes data can be added as tags in OSM.
GeoServer and MapServer are very similar in terms of functionality and popularity. MapServer requires some expertise to set it up, whereas GeoServer is quite straight forward. The documentation available for both these applications is quite extensive. Thus, personal preference would be the only determining factor when deciding between these two map servers. Both have additional functionality to view layers, i.e. to preview a layer as a simple map view of the layer with no additional functionality. Basic spatial analysis

functionality of the tool A -Additional functionality offered by the tool
GeoNetwork is often used with various map servers, such as GeoServer or MapServer, to catalogue the resources (e.g. data, web services or documents) available and provide the functionality to search for specific datasets based on keywords or the location of the data. This functionality is not possible without comprehensive metadata about each dataset. Once a user has identified a dataset of potential interest, the user can then review the metadata and, if a WMS is available, view the data on a simple map. This map does not provide any editing functionality, but the map with annotations can be exported as an image or PDF file.
GeoNode is similar to GeoNetwork but allows the user to store the data within GeoNode. Additionally, editing of the datasets is possible and the data can be shared as an interactive map with some styling options. GeoNode and GeoNetwork are both well documented but require some experience to set up and maintain. GeoNetwork is crossplatform, but GeoNode is only available for Linux which might be a barrier for use in some urban design projects.
MapWindow5 and QGIS are both mature desktop GIS applications that allow users to perform a wide range of spatial analysis. The biggest drawback for MapWindow5 is the lack of support for different operating systems (it is only available on Windows) and the lack of documentation. QGIS has extensive user documentation and tutorials which might make it easier for the user to use. Any combination of these tools can be used for the collection, storage, manipulation and visualization of geospatial data in urban design projects. The only determining factor would be the specific purpose and scope of the project. For example, a specific collection of tools might be used when a novice user wants to collect observations with various attributes in the field (i.e. EpiCollect5), share the data on a server with editing capabilities (i.e. GeoNode) and then analyse the raw data using a desktop GIS (i.e. QGIS). A different collection might be more appropriate if an experienced user wants to verify a land use dataset (i.e. Arbiter) that is hosted on a map server (i.e. GeoServer) and produce maps (i.e. QGIS).

CONCLUSION
In this paper we reviewed and evaluated open source geospatial tools that can be used for the collection, storage, manipulation and visualization of geospatial data in urban design projects. Based on this, we proposed a modular open geospatial toolbox, i.e. urban designers can swap out a tool in a category for another one in that category, or swap out a tool that meets one requirement for another tool that meets that requirement. All the evaluated tools fulfilled the functional requirements to some degree; the real difference between the tools emerged from the evaluation against non-functional requirements, such as perceived usability for novice users and the amount of documentation or support available. The results in this paper are based on requirements of urban designers, but are equally applicable for researchers and professionals in other disciplines who collect data at the neighbourhood level. They can provide researchers and professionals from a range of fields with guidance for the collection, storage, analysis and visualization of neighborhood level geospatial data.