Making open geo-data attainable for everyone - Requirements for a Layman’s GeoPortal
Summary
Open data are data that are made publicly available by organisations for reuse by third parties. A part of these data has a geographic component; these can be defined as open geo-data. In the Netherlands open geo-data are provided by municipalities and other (governmental) organisations through GeoPortals. A GeoPortal can be defined as a gateway on the internet where access is provided to services that make it possible to search and retrieve geographic information. It can be argued that current GeoPortals in the Netherlands focus on specialised users, since the data have to be downloaded when the need arises amongst the users to perform (simple) edits or analyses on the data. This can be seen as a threshold: a lack of functions to work with the data online. This threshold, and other impediments, can exclude laymen from using open geo-data, as it can be assumed that laymen do not possess software to work with the data. It is therefore investigated which laymen-impediments are present and which requirements a Layman’s GeoPortal should have to potentially resolve impediments that laymen experience when using open geo-data online. In this manner open geo-data can be made attainable for everyone, not only the experienced users.
The main research question of this research is “To what extent can a GeoPortal be designed and developed using free and open-source software that resolves impediments laymen experience when using open geo-data?”. It must be noted that the main objective of this research is not to develop a complete functioning GeoPortal from scratch in terms of defined requirements, but rather to use suitable free and open-source software (FOSS), which focuses on the development of GeoPortals and geo data dissemination, develop a proof-of-concept GeoPortal which embeds more functions than the individual Dutch GeoPortals, and use this GeoPortal as a means for an evaluation. Since this proof-of-concept GeoPortal embeds more functions compared to individual Dutch GeoPortals, this newly developed GeoPortal can be defined as an renewal in terms of functionality.
First of all, the impediments and requirements are formulated by means of a preliminary analysis, literature review, and semi-structured interviews with open geo-data experts from municipalities. The derived impediments and requirements are used as input for the Conceptual Design. The Conceptual Design describes which impediments are intended to be resolved with the implementation of which requirements. This design includes eight laymen-impediments and thirty requirements. Two examples of important impediments are ‘lack of domain knowledge’ and ‘lack of provided services’. Important requirements that come forth in this research are the provision of certain functionality and that the GeoPortal should be intuitively and easy to use. Functions that are not provided by current GeoPortals in the Netherlands, but emerged in this research, are a tool to measure a distance, the ability to make layers transparent, and the option to create and save custom maps. The implementation of these functions lead to a distinction between the proof-of-concept and the current Dutch GeoPortals.
The proof-of-concept GeoPortal is developed using suitable FOSS. Three instances are analysed and it is concluded that GeoNode is the most appropriate choice, as the default interface of GeoNode already provides a the most requirements that are defined in this research. Additionally, the abovementioned functions are already provided in the default interface by the GeoNode software. Furthermore, the developers of GeoNode claim that their software is made for inexperienced users, in contrast to the other two software instances (i.e. ESRI Geoportal Server and Open Geoportal). The choice is made to add no new functions to the default provision of functions of GeoNode, as the documentation of GeoNode lacks on guidance in this context and a developer of GeoNode notes that the addition of functions is really hard, even for experienced programmers.
The next step in the research process is the conduction of an evaluation with laymen. It is investigated if defined impediments are resolved by the developed proof-of-concept and if (new) impediments and requirements can be formulated by them. The results of the evaluation show that three out of eight impediments are completely resolved, being ‘Lack of domain knowledge’, ‘Lack of provided services’, and ‘Lack of provided metadata’. Additionally, four are partially resolved: ‘Data are not up-to-date and accurate’, ‘Lack of provided geo-data’, ‘Data cannot be found’, and ‘Lack of search possibilities’. One of the impediments is not resolved, which is ‘Open geo-data are unfamiliar’. In addition, the evaluators define one new impediment and two new requirements. The new impediment that is formulated is the use of a foreign language in the GeoPortal, as it can be hard for users when they do not speak the English language sufficiently. The new requirements that are defined by the evaluators are the provision of a manual regarding the usage of provided functionality and, related to the aforementioned impediment, the use of the native language in the GeoPortal.
The results of this research can be seen as a step forward towards the design of an attainable GeoPortal for laymen, as the developed proof-of-concept GeoPortal resolves a majority of defined impediments that laymen experience when using open geo-data. However, some impediments are not (completely) resolved. The free and open-source software of GeoNode provides a lot of requirements in its default design, but some remaining requirements are not implemented. It can be concluded that the software of GeoNode can be used for the development of GeoPortals of municipalities that are attainable for laymen. However, it is recommended that an experienced programmer is actively involved within the organisation to develop and implement requirements regarding the GeoPortal. If this experienced programmer is not present, the default functionality provided by GeoNode can be too limited. In this case it might be better for an organisation to use proprietary software which provides a larger supply of functionality.