Approach towards a Holistic Management of Research Data in Planetary Science—Use Case Study Based on Remote Sensing Data

Abstract

In the planetary sciences, the volume of remote sensing data and derived research products has been continuously increasing over the last five decades. The amount and complexity of data require growing sophistication in data analysis, data management, and data provision targeted at a growing research community. In order to efficiently manage and facilitate the reuse of research data and to provide stable and long-term access, sustainable research data solutions are needed. We here present a prototype for structured storage, management, and visualisation of planetary research data and discuss the particular benefits, as well as challenges of such an information system for data management, for establishing data references by cross-linking information, and for improving the visibility of data products. The prototype is a co-development of two research institutes of the German Aerospace Center (DLR) and is based on two components: the Earth Observation Center (EOC) Geoservice, which constitutes an infrastructure providing data storage and management capabilities, as well as an interface compliant with collaborative and web-based data access services, and the Environmental and Crisis Information Systems (UKIS), a framework for the implementation of geoscientific web applications.

1. Introduction and Background

With each new planetary mission, the amount of raw and derived data based on remote sensing observations, in situ measurements, or telescopic observations grows steadily and contributes to the overall pool of data available for further processing, research investigations, and distribution to a wider community. Remote sensing data commonly have the largest share of mission data and comprise optical image data, multispectral and hyperspectral data, radar images, and derived products developed at ground facilities, such as digital terrain models and higher-level data.

Data nodes, in particular the European Space Agency’s (ESA) Planetary Science Archive (PSA) [1,2] in Europe, the Planetary Data System (PDS) [3] in the U.S., the Japan Aerospace Exploration Agency (JAXA) Digital Archives [4] in Japan, the Lunar and Planetary Data Release System of the National Astronomical Observatories of China (NAOC) [5], or the Emirates Mars Mission (EMM) Science Data Center [6] of the United Arab Emirates (UAE) Space Agency, are responsible for data storage and for making data available to interested researchers and users also across their national boundaries. Apart from these larger data nodes, data are often made available through instrument teams, as well as other facilities. All these datasets are commonly referred to as primary research data (see, e.g., [7,8]) and defined as “original data collected for a specific research goal” [8] (p. 1). A comprehensive summary of these primary data in the planetary sciences, labelled as foundational data products, which include geodetic coordinate reference frames, topography, and orthoimages, was given by Laura and Beyer [9]. Among others, these foundational data products must, by definition, “have the widest possible scope of impact across the subset of the planetary sciences making use of spatial data” [9] (p. 1).

Apart from observation data, also modelling and laboratory data contribute to the growing database. Such data are usually collected during mission and team activities and stored in local databases, as for example the Europlanet 2024 activities Distributed Planetary Laboratory Facility [10,11] or Virtual European Solar and Planetary Access (VESPA) [12].

After scientific analyses have been conducted, a selection of these analysed data is turned into visual assets, such as figures, maps, profiles, diagrams, as well as models. Derived scientific data, called secondary research data (see, e.g., [7,8]), serve as the foundation of and description for research investigations in scientific publications and are defined as “data originally collected for a different purpose and reused for another research question” [8] (p. 1). In this contribution secondary research data is equated with the term information and thus used as a synonym here.

While primary research data are available via central archives, related research results are sometimes made available through supplements associated with publications. The storage of the secondary research data, however, is mainly organised in a decentralised way by individuals on local institutional levels. This applies not only to the planetary sciences, but is also common practice in other research branches.

These topics are the basis for discussions and demands related to the accessibility of research data in general, which have been initiated and communicated towards pushing for more sustainable data management. Here, the focus is on reusability and not least on the interoperability of research data within and between different scientific disciplines. All these issues are related to the term open science, which sums up much of these efforts. On the top level, that means “to make the primary outputs of publicly funded research results—publications and the research data—publicly accessible in digital format with no or minimal restriction” [13]. Doing so, “repositories and archives offer the possibility to store, access, use and reuse research and scientific inputs and outputs (both articles and data sets), and speed the transfer of knowledge among researchers and across scientific fields, opening up new ways of collaborating and new research methods” [14]. That means open science concerns all topics within the whole research data life cycle (see, e.g., [15,16]) including open source for software and open access for data and publications.

In order to provide platforms (a) to facilitate the use and reuse of data in a transparent and sustainable way and (b) to comply with recommendations and guidelines, research initiatives such as the Research Data Alliance (RDA) [17], GOFAIR [18], and the Committee on Data for Science and Technology (CODATA) [19] have been established. Besides these endeavours, FIGSHARE [20], ZENODO [21], and PANGAEA [22] were founded in order to provide the scientific community with platforms to archive shareable, discoverable, and citable research data. Furthermore, initiatives such as the Nationale Forschungsdateninfrastruktur (NFDI) [23] on a German national and the European Open Science Cloud (EOSC) [24] on a European level were established in order to provide a trusted and virtual environment that cuts across scientific disciplines and/or national boundaries. All these initiatives are governed by the FAIR principles [25] in order to create findable, accessible, interoperable, and reusable data.

If we focus on the characteristics of research data in the area of planetary science, it can be noticed that the major part of research data in this field has one thing in common: they are spatially referenceable. The special nature of spatial data allows cross-connections among different missions, areas, topics, and even planetary bodies. In order to handle these kinds of spatial data, currently, modern Geographic Information System (GIS) technologies are a central component.

Modern web-based GISs typically require less technical user knowledge than traditional desktop-based systems due to their limited general-purpose functionalities. Web-based systems run in web browsers and are often tailored to a clearly defined use case. The data basis is usually provided by the creator of the system [26]. Web-based GISs often consist of server and client components. In this architecture design, the tasks of the server components include, but are not limited to, data storage and data provision. The client components display the server’s data and also provide data analysis tools. Standards such as those of the Open Geospatial Consortium (OGC) are established for communication between servers and clients.

In the world of spatial planetary research data, web-based GISs became a common tool to impart knowledge to all kinds of possible users over the last few years. This was also taken into account by the planetary mission data archives. Thus, all primary scientific and ancillary data for all ESA planetary missions can be searched and requested via the PSA Search Interface, e.g., [27,28]. In the case of PDS, the mission data are provided via nodes according to their related topic. For example, within the geoscience node, the Orbital Data Explorer (ODE), e.g., [29,30], allows the search, display, and download of data products from different planetary missions.

Besides, further platforms and initiatives came up handling and supporting planetary data within web-based services and GISs. The Planetary Interactive GIS-on-the-Web Analyzable Database (PIGWARD) [31] can be understood as the first web-based GIS for planetary data. This was followed by Map-a-planet (USGS [32,33]) in order to serve the community with scientifically accurate planetary global mosaics via a web interface. Many other developments have followed in the last 20 years. JMars, short for Java Mission-planning and Analysis for Remote Sensing (Arizona State University, e.g., [34,35]), provides mission planning and data analysis tools for planetary scientists, engineers, students, instrument teams, and the general public. PlanetServer (Jacobs University Bremen [36]) allows for the analysis of complex planetary data online, in particular hyperspectral and topographic data. i-Mars (FU Berlin, [37]) is a server and web-based GIS application for the High-Resolution Stereo Camera (HRSC) data of Mars. The Planetary Geoportal (MexLab MIIGAIK [38]) is a prototype of a web-based GIS focusing on three-dimensional views of the Moon’s surface. SolarSystemTrek (JPL [39]) enables users to visualise, explore, and analyse planetary surfaces for mission planning, planetary science, and public outreach.

Those systems are either built upon proprietary software environments or, more commonly, upon a sustainable and well-established stack of open-source software such as spatial databases (such as PostgreSQL, [40]), applications for sharing geospatial data (such as GeoServer [41]), and a graphical user interface (e.g., based on JavaScript libraries [42]). Applicable standards developed by the OGC are the Web Map Service (WMS) [43] for serving georeferenced map images and the Web Feature Service (WFS) [44] for serving geographical features such as lines or polygons.

Considering the presented status of data, requirements for research data, and technological developments as mentioned above, web-based GISs have developed towards an established and promising component for a sustainable reuse of historical, current, and future spatial planetary data. This applies to the entire planetary science community, as well as to each individual actor within that community.

With all this in mind, the aim of this contribution was to demonstrate a solution for the structured management and visualisation of heterogeneous planetary research data compiled and developed with the contribution of the Institute for Planetary Research (PF) at the German Aerospace Center (DLR). This institute is involved in several international planetary missions and consequently produces and handles a large volume of different research data that can be distinguished into referenced, referenceable, or non-referenced research data (see Section 3.1 for more details). Since the primary research data are available through data archives and other platforms, this paper focused on the management of the secondary research data, incorporating scientific publications themselves as a research dataset. In order to manage these heterogeneous research data, an individual system environment has to be defined where different user groups should be able to store and query research data across multiple missions, planetary bodies, and scientific disciplines. Here, the spatial reference in combination with structured metadata should serve as the primary descriptive parameters on the top level. In order to benefit from existing open-source developments inside and outside of DLR, this contribution is proposed jointly by PF and the German Remote Sensing Data Center (DFD) at DLR. With its background in software development, DFD is involved in the reception, management, processing, provision, and analysis of German and European remote sensing data [45]. Finally, the paper had two essential foci: (1) to create a concept for the different scientific disciplines in the field of planetary research, in which the heterogeneous secondary research data are managed and made available in a reusable way via the spatial reference (directly or indirectly); (2) to implement this concept in a manner as resource-saving as possible. Thus, the choice fell on the existing system chain presented here. Although our development is based on GIS technology, we rather consider it as a data management system than a typical GIS.

The context and motivation of our work are covered within the current Section 1. Section 2 describes the methodological foundation of our work. The initial data and requirements analysis approach, the focus on how an implementation can be performed, and a detailed discussion about background information on the evaluation aspects are given in Section 2.1, Section 2.2 and Section 2.3. The actual description of the methodical concept is presented in Section 3. A data inventory is presented in Section 3.1. User and system requirements are given in Section 3.2, whereas an example use case is summarised in Section 3.3. Section 4 shows the whole technical implementation process from the backend (see Section 4.1) to the frontend (see Section 4.2). In order to give an impression to what extent the individual requirements are covered by the prototype, an evaluation as the last part of the development is given in Section 5. The final part Section 6 of this contribution contains the conclusion and outlook in order to present the potential of the presented developments and future developments.

2. Method

Methodically, the development presented here follows a standard approach consisting of (1) determining the system design, (2) implementing the prototype, and (3) evaluating its performance (cf., e.g., [46]). In this section, we present the details for each of these steps.

2.1. System Design: Inventory, Requirements, and Use Case

For the system design (1), an assessment of the data inventory was required, which is composed of a quantitative and qualitative overview of the available data and information diversity within the institutional unit. In this analysis, questions regarding the type and quantity of available data, data formats, and user groups using these data need to be answered. Here, the spatial reference should be used as the main parameter for cross-linking various types of research data.

The second step during the design phase was (2) the user and system requirements’ analysis (cf., [47,48]. This was conducted via an informal user interview, building on the expertise and experience of the authors and complementary literature resources.

Finally, as the third step (3), a use case needed to be formulated. It must be noted here that the use case needed to cover both an exemplary dataset, as well as a scientific task, which had to be conducted using the exemplary dataset.

2.2. Adaption and Implementation

The implementation built upon collected requirement specifications and exemplary input data. First, an initial system architecture was prepared that best met the most system requirements right from the start. Subsequently, software environments and libraries for the implementation were selected. We here decided to follow an iterative agile approach. Upon reaching development milestones, feedback from future users was collected. This way, the requirements could be further refined and improved iteratively, leading to a finished prototype according to the needs of the users.

2.3. Evaluation

In order to demonstrate the suitability of the prototype, an evaluation of the development is essential. This evaluation was directly conducted within the system environment and was based on the requirements that were formulated in Section 3.2. This evaluation should, if possible, also contain recommendations regarding the future development potential.

3. Towards the Prototype

In order to conceptualise and implement a working prototype, an institutional inventory was taken of the overall institute’s research data landscape in order to generate an overview of the institutional data assets and to build a concept based on the demands and requirements. This inventory is covered here as an abstract concept to draw the focus on the process of developing the requirements. In the following section, it is presented in a more concrete institutional use case so that the overall development process becomes more transparent. Both the abstract concept, as well as future use case development were aimed at providing ideas to adapt use cases that suit the readers’ needs.

3.1. Inventorizing Institutional Divers in Topics and Data

The research data developed and worked out in planetary science could be grouped into (1) directly referenced research data, i.e., the data have an inherent spatial reference in the file description (spatial data format) via the reference body and/or projection, (2) indirectly referenceable data, i.e., the dataset is related to a spatial location, or here planetary body, but this information is not included in the file description (e.g., diagrams or measurements), and (3) non-referenced data, i.e., data without any spatial relation such as laboratory data or programming code.

The conceptualisation based on the local institutional inventory was realised by semi-structured interviews covering qualitative questions addressed to representatives of individual institutional departments and also by extracting information from departments’ websites. For each department unit, the main activities and overarching data requirements, as well as also special cases were gathered and structured to identify commonalities and differences that needed to be addressed.

The set of collected information from institutional groups (departments, working groups, labs) consisted of (1) information about their main working fields referring to the specific focus in the respective institutional unit or department and (2) information about data sources and methodologies, including general methods, more specific data requirements, and the standard means of accessing data, as well as the main mission focus and targets.

By establishing this base information, commonalities, differences, and more importantly, interdependence’s among groups in terms of research objectives, as well as data, assets can be identified and an organisational network with its foci can be created. Furthermore, by identifying common data assets, it is possible to characterise dominant, as well as under-represented data areas within an organisation and to identify the need for establishing intelligent ways to improve data usage and counter access shortcomings.

The majority of the data volume returned from today’s planetary missions is image data that occupy most of the bandwidth and storage on board and on the ground (see Figure 1). At the ground, image raw data are transferred to structured formats, such as raster image formats, among which, e.g., the GeoTIFF [49], VICAR [50], FITS [51], and ISIS CUB [52] formats are perhaps the most popular and common ones. The resulting products are directly spatially referenced and can subsequently be used for data analyses and further processing. The data processing tasks may vary considerably depending on the research fields and objectives in the respective institutional environment. Whenever data are processed, the resulting products are directly linked to spatial metadata, which accumulate over time depending on the amount and nature of the data processing.

A second set of data comprises research data that are not currently linked to spatial information, but where the establishment of a spatial link is possible. These indirectly spatially referenceable data (see Figure 1) could be, e.g., laboratory measurements of samples that were collected at spatially well-defined locations on a planetary body. Metadata can be detached from the main product and delivered as human-readable text, or they are integrated into the binary data product as, e.g, a header. A third and potentially smaller set comprises data for which no spatial link can be established (see Figure 1).

Given the large value of planetary mission data, it is likely that various departments within an organisation work either independently or collaboratively on these data despite different research objectives and approaches. Instead, close cross-departmental collaboration is carried out to answer research questions and process data so that a clear distinction from one another is not actually possible.

In the following section, this contribution covers basic user and system requirements based on a user survey and introduces the actual software development.

3.2. User and System Requirements

For the development process, user requirements were collected and defined in order to address specific needs from organisational entities at large, as well as at the individual level. The result of this process subsequently served as the basis for development, as well as for the evaluation of the working prototype, once it is in place. In a more specific context, the functionality of the research data management system should be designed in such a way that it addresses the following criteria. These user requirements (UR) are comparable with the criteria described, e.g., in [53,54]:

• UR#1: The system shall manage available planetary research data that need to be further analysed and visualised;
• UR#2: The system shall provide a semantic and physical link between different kinds of planetary research data, which also include publication material;
• UR#3: Besides visualisation, planetary research data shall be made available for further scientific investigations;
• UR#4: For the purpose of the reusability of planetary research data, further information such as nomenclature, versioning, licensing, and citation shall be provided;
• UR#5: To reflect different levels of data access, permissions within the research data management system (for example, intermediate data, which are not published, yet) and access restriction are necessary;
• UR#6: The source code of the entire system/framework shall be made publicly available and follow open-access guidelines;
• UR#7: The research data management system must be intuitive and easy to use for people without in-depth GIS knowledge, as planetary researchers might not necessarily have a background in GIS applications. Furthermore, the system shall follow basic user interface (UI) guidelines and build on UI experiences in order to motivate its use;
• UR#8: The system must provide a manual to guide users.

Derived from the user requirements, technical and system requirements (SRs) served as the target for the prototype’s implementation:

• SR#1: The research data management system must contain a storage and a visualisation component for spatial data. Derived from UR#1;
• SR#2: The system shall allow different kinds of queries: spatial coordinate-based ones and attributive-keyword-based ones (e.g., semantic data retrieval). Derived from UR#2;
• SR#3: Spatial data shall be made available via standardised interfaces (e.g., WMS or WFS). Derived from UR#3;
• SR#4: Spatial data must contain (or be associated with) detailed metadata. Derived from UR#4;
• SR#5: A login page shall be created for controlled user access. Derived from UR#5;
• SR#6: The system must be built completely on open-source components. Open source is particularly useful when technology made for geodata has to be adjusted for data from other planetary bodies. Derived from UR#6;
• SR#7: The research data management system must be web-based in order to benefit from existing state-of-the-art web GIS technology. Moreover, web-based technology guarantees platform independence. Thus, the system will work with major desktop web browsers such as Mozilla Firefox, Google Chrome, or Microsoft Edge. Derived from UR#7;
• SR#8: A short PDF manual is provided. Derived from UR#8.

These system requirements are not exclusive to an implementation of a planetary research data management system. They are in particular also comparable to other developments targeting the web-based provision of spatial data.

3.3. Use Case and Sample Dataset

The representation of an application example, i.e., the use case, is an essential component of the prototype development, and it comes in addition to the representation of the inventory and the individual requirements that the research data management system should fulfil. This application example was divided into (1) the specification of a use-case and (2) the description of an exemplary and representative dataset used within the development.

The use case formulated and presented here describes the first, as well as the last step in the approach of a research question in the spatial sciences. More concretely, it is about the spatial and attributive search for research data at the beginning of a scientific investigation and to ensure that results with a certain value are available for further studies after finishing an investigation. Thematically, we here focused on a scientific geologic mapping approach whose final research results are geologic maps. The reason why that approach was chosen was that a geologic map could be understood as an inherently complex research data result in planetary science because the product is based on a high level of spatial and temporal interpretation, analyses, and a variety of different input data. As emphasised by Wilhelms Wiliams [55] (p. 208), a geologic map is a “two-dimensional representation of the three-dimensional spatial relations of a chronological sequences of the materials and structures of a planetary crust”. In more detail, Reference Hauber et al. [56] (p. 105) outlined that “geologic mapping is based on the premise that geologic materials such as rocks, sediments, dust, or ices distributed across the surface of a planet can be subdivided into discrete three-dimensional bodies (units) based on a common suite of Planetary Geologic Mapping characteristics (e.g., mineralogy, grain size, and color). These characteristics allude to a particular geologic process that occurred within a particular period of time. Geologic units are separated on a map by geologic contacts, which effectively denote a transition in geologic process or event. The three-dimensionality of a geologic unit alludes not only to the spatial and temporal pervasiveness of that particular geologic process when it was deposited but also how that unit was modified after emplacement. Thus, the process of geologic mapping is intended to catalog the characteristics of geologic units and the nature of their adjoining contacts as a means to infer how those rocks were originally emplaced (e.g., by intrusion) and how they have been modified (e.g., by faulting) since emplacement”. As a result, “geologic maps present the fundamental syntheses of interpretations of the materials, landforms, structures, and processes that characterize planetary surfaces” [57] (p. 64).

The data analysis process required for geological mapping is still limited to the analysis and interpretation of remote sensing data. This limitation, however, refers to data collection only, as a large variety of different recording methods exist in remote sensing to explore and analyse extraterrestrial surfaces [58] (p. 33). Despite this limitation, remote sensing is paramount for “gather(-ing) qualitative or quantitative information of an object from distance and without physical contact, usually through information transported by electromagnetic radiation from instruments on orbiting platforms. Remote sensing data are usually characterised by the geometric and spectral resolution of the observation, the observation time and scientific contents.” (cf. [58] (p. 34). For more details about the process of geologic mapping, as well as the importance of geologic maps in the planetary sciences, the reader is referred to Planetary Mapping by Greeley and Batson [59], Planetary geology by Rossi and van Gasselt [60], and Planetary Cartography and GIS by Hargitai [61].

The second part of the application example for the prototype development is a representative sample dataset. Essentially, this dataset is based on a recent approach developed within the institute. Here, a vector-based data collection of thematic, mainly geologic and geomorphologic mapping results, as well as a collection of raster-based global mosaics at different resolutions (as background data) are linked to a database handling different kinds of spectral data (see [62]).

The sample dataset is focused on vector- and raster-model-based data (see Figure 2), which was developed through the institute’s participation in NASA’s Dawn mission to dwarf planet Ceres. These use case data are described in the following.

• High-Altitude Mapping Orbiter (HAMO) global digital mosaic (see Figure 2, left part/centre):
  This high-resolution, controlled mosaic of Ceres based on ortho-rectified images taken by Dawn’s Framing Camera (FC) during the first cycle in HAMO depicts the surface at a resolution of about 140 m/px. The data product is also the basis for a high-resolution Ceres atlas that consists of 15 tiles mapped at a scale of 1:750,000. In detail, this dataset was described by Roatsch et al. [66];
• High-Altitude Mapping Orbiter (HAMO) global digital terrain model (DTM) (see Figure 2, left part/top):
  The HAMO DTM covers approximately 98% of Ceres’s surface. A multi-image matching process with 10,000 individual images at full resolution yields 2.8 billion object points. The global mosaic has a lateral pixel spacing of about 135 m/px (60 pixel/degree) and a vertical accuracy of about 10 m [67];
• Low-Altitude Mapping Orbiter (LAMO) tiles (see Figure 2, left part/bottom):
  For these datasets, ortho-rectified images with a resolution of about 35 m/px from the first four LAMO cycles were taken and used to derive a global, high-resolution, uncontrolled photomosaic of Ceres. This global mosaic is the basis for a high-resolution Ceres atlas that consists of 62 tiles mapped at a scale of 1:250,000. More details are provided in Roatsch et al. [68];
• Geologic and geomorphologic map (see Figure 2, right part):
  These mapping results were acquired during the nominal mission of Ceres (March 2015–June 2016) in order to support the analyses conducted by the Dawn Science Team [69]. The maps were based on a tiling scheme following the recommendations by Batson [70] and divided the surface into 15 quadrangles (HAMO, 140 m/px [66]). A quadrangle was mapped by one researcher/mapper, and in order to create matching datasets at the end, the mapping and cartographic process followed state-of-the-art approaches in cartography and GIS, which included the developments of the cartographic concept, guidance for mappers, and the implementation and merging of all GIS-based mapping data. The GIS-based geologic dataset is divided into 15 individual quadrangles, as well as a global dataset. Both products contain identical attributive and visual description items (see more [63,64,65,71]).

The sample dataset contains approximately 5 GB of data. However, the size of the retrievable data in the information system differs as data are compressed for web use. In addition to these datasets, scientific publications are linked with the information system. These dissemination products were generated within the Dawn project with institutional participation. However, since these articles are directly integrated via the institutional publication database at DLR, these datasets are not listed separately here.

4. Implementation of the Prototype

Based on the user and system requirements, we decided that a two-tier architecture with a data backend and a visualisation frontend met our needs (Figure 3) [72]. In our case, the task of the backend is the storage and provision of planetary data. The backend was designed to be deployed on a server. The frontend, however, represents the system’s interface to the user. It displays the planetary data provided by the backend. Thus, the frontend serves as the backend’s client.

Our research data management system was based on established standards from the context of web development. Therefore, the communication of the two layers of our architecture is realised via interfaces such as the standards by OGC. In addition, our architecture considers connections to external systems. The frontend allows queries of external metadata providers using standardised interfaces.

This system structure is a widespread architecture. It reflects the theoretical concepts of modern web-based GIS applications explained above. At DFD, for instance, the focus of such systems is on Earth observation (EO) data. Therefore, specialised software packages and frameworks have been compiled and implemented at DFD, which enable the rapid setup and stable operations of web-based geoscientific data management and information systems. In the following, we show how two of DFD’s developments have been applied in the context of planetary data.

4.1. Backend

The backend of the prototype is deployed in the EOC Geoservice platform developed and operated by DFD. The main goal of this platform is to provide access to EO data and value-added products, as well as high-level visualisation, discovery, and analysis services based on standardised OGC interfaces for internal and external users of DLR’s Earth Observation Center (EOC). However, the scalable architecture and multi-mission design of the EOC Geoservice facilitate the instantiation of services also for other projects such as this prototype.

In the context of this project, the backend is responsible for several important system-level functions/tasks. These tasks are provided by different components of the backend design, which are depicted schematically in Figure 4 and described in the following paragraphs.

The ingestion component implements the main logic for data handling and processing in the backend. It defines and executes data-specific workflows for loading research datasets into the platform’s storage. The workflows currently only implement a minimal set of tasks to support a frontend visualisation use case, but can be extended in the future to enable additional use cases and requirements. The component is based on the workflow engine Apache Airflow [73].

The workflows for primary datasets such as radar or optical images and digital elevation models mostly in raster formats include additional optimisation steps to ensure performant web-based access, such as reduced resolution image pyramids (overview). In addition, hillshades are generated for the DEM to enhance the visualisation and validation. Furthermore, the workflows may include reprojection of datasets into the common GIS coordinate reference system. This is necessary in order to use the data in common GIS software packages. While acceptable in a prototype, this is a major drawback that, in the future, needs to be analysed and solved in standardisation working groups and communities.

The workflow for secondary datasets such as edited geological and geomorphologic features in vector formats includes the ingestion of geometries from file-based transfer formats such as shapefiles into database backends. Furthermore, the workflows may be enriched using additional information and metadata to support discovery use cases in the future.

The storage component uses spatially enabled databases and block-based file storage for hosting the project datasets accessible through internal Network File Systems (NFS) and Structured Query Language (SQL) interfaces.

The database for managing and indexing vector-based features is based on PostgreSQL [40] with spatial support via PostGIS [74]. It holds the structurally organised data as defined and modelled in the project (cf., e.g., [65]). The ortho imagery and digital terrain datasets are currently stored as files on shared storage based on Network File System (NFS). They are organised in tiles and are mosaicked on-the-fly within the service component.

The service component provides interfaces to retrieve and visualise project datasets. The public interfaces are provided by GeoServer [41], which supports most of the OGC Standards and is widely used in the GIS community. The prototype backend currently provides OGC WMS, WCS, and WFS interfaces to the frontend and an administrative REST interface for the ingestion component.

The Web Map Service (WMS) allows visualisation of primary and secondary datasets. Both raster and vector datasets are rendered with data-specific styles on the server and sent to the frontend in the form of images. In contrast, the Web Feature Service (WFS) and the Web Coverage Service (WCS) allow the frontend to request the data themselves in vector and raster formats, respectively. Currently, raster-based primary datasets such as the HAMO, LAMO, and DTM data are retrieved by the frontend via the WMS, and the geological and geomorphological maps are retrieved from the WFS in to order to access the attributes defined in the data model.

4.2. Frontend

The user of our system interacts with the data provided by the backend via a graphical user interface: the frontend. Our frontend is based on the Environmental and Crisis Information Systems (UKIS, German: Umwelt- und Kriseninformationssysteme), DLR’s framework for geoscientific web applications [75]. UKIS has been under development since 2011 at DFD with the aim of making the institute’s research in the field of Earth observation accessible and usable by means of innovative software systems.

During the development of the UKIS, great importance was placed on reusability, modularity, and abstraction. Thus, it is possible to create a large number of thematically different systems based on the UKIS. Examples of past and current developments are natural hazard monitoring and information systems (e.g., for floods, forest fires, and tsunamis), environmental information systems (e.g., snow cover, coastal usage, land cover), information systems in the fields of civil security (e.g., ship detection) and health (e.g., COVID-19), as well as systems for creating video animations from remote sensing data.

In addition to the thematically diverse application possibilities, the advantages of the UKIS lie, on the one hand, in the accelerated software development. The UKIS provides a comprehensive foundation for new applications. On the other hand, all UKIS-based systems mutually benefit from innovations in the common software basis.

Technically, the UKIS is divided into modules, each with clearly definable tasks. One of these modules is the UKIS frontend, an open-source web interface for the intuitive analysis and visualisation of data [76]. For its part, the UKIS frontend is based on a large number of popular open-source developments. The most significant are:

• TypeScript: TypeScript is a programming language initially developed by Microsoft. It is designed for the implementation of large-scale applications and expands JavaScript by functionalities such as static typing. TypeScript programs transcompile to plain JavaScript [77];
• Angular: Angular is a generic TypeScript-based framework for the development of complex web applications. Its first version was introduced in 2016 by Google. Currently, Angular has become one of the most widespread frameworks for developing mobile and desktop-based web applications [78];
• Clarity: Clarity is an open-source design system developed by VMWare that combines UX guidelines, an HTML/CSS framework, Angular components, and web components [79];
• OpenLayers: OpenLayers is a JavaScript library for integrating maps into web-based applications [80].

As stated above, the UKIS is a software framework designed primarily with Earth sciences in mind. Thus, the framework itself and all its underlying components are expected to work with spatial data. However, due to the UKIS’s standards compliance and strong focus on flexibility, the integration of planetary research data was possible with minor adaptations. The only necessary extension was the application of the custom projection created for Ceres in the backend in order to apply it to the frontend. For this purpose, the library proj4js [81] was included in the UKIS frontend, which provides an interface to the custom projection. In this way, it is possible to visualise the data provided by the backend in an easy-to-use web map. All control elements such as layer navigation, as well as the design of the system could be adopted unchanged from the UKIS basis.

For our prototype, we also implemented a simple interface to the DLR electronic library elib [82]. elib is a public archive of publications by DLR employees. Search queries can be sent to elib using the HTTP method GET [83]. This makes it possible, for example, to search elib’s database by author name, year of publication, or other parameters. The response from the elib server can be requested in various data formats, e.g., HTML or RSS. To achieve the important linkage between location data and other types of data described in Section 1, the following functionality was implemented in the frontend: The surface of Ceres is divided into rectangular areas, called quadrangles. Each of these quadrangles has a unique name as an attribute. The frontend receives these names from the backend. By clicking on a quadrangle in the frontend, a query can be generated to elib using the name of the quadrangle as the search parameter. The user is then shown all publications in elib that were found for the respective quadrangle name.

5. Evaluation and Discussion

The last part within the production cycle of a new development is the evaluation of its functionality and performance. It is necessary to review the development with reference to the user and system requirements (see Section 3.2).

The user requirements combine the following important aspects on an upper level: simplicity, presentation, accessibility, interoperability, and reusability, as well as security and reliability. When taking a closer look at the system requirements, the research data management system had to be designed to be decentrally stored due to different working groups and departments, uniformly described across different reference systems, which refers to metadata for different disciplines to describe data as uniformly as possible and as flexibly as necessary, structurally organised through a metadata model, commonly and centrally accessible with standards for the interdisciplinary cross-link, visualised, and enabled for integration of non-spatial research data.

In order to evaluate to what extent the prototype fulfilled the user and system requirements (see Section 3.2 for the SR and UR), the current state of implementation is discussed in more detail below. As shown in Section 3.2, an SR always refers to the preceding UR. Thus, in order to evaluate their implementation so far, they were each considered together in the following, i.e., SR#1 and UR#1 corresponds to R#1, and so on. The results are presented in the following:

Requirement #1 (R#1) claims the strong need for data management and visualisation. As data management is needed everywhere, it is highly advisable not only for the single user’s use, but even more when different users and groups have to be handled simultaneously in order to guarantee data availability. Thus, this is the key component for central data provision. The visualisation is a characteristic of spatial data because they contain a numerical, as well as a visual description of the data at the same time. This leads to the great benefit of spatial data, by which besides analytical and statistical calculations and interpretations, also visual analyses are possible. One example of this represents the use case described here: the geologic mapping of a planetary surface. This produces a highly interpretative and complex image based on the visual data interpretation and numerical data analysis of remote sensing data. The result, i.e., the map product itself, serves as basis for further investigation. The spatial data visualisation is divided into (1) the selection of visual attributes, e.g., symbols, colour ramps, etc., and (2) the choice of cartographic projection, depending on the extent of the area, aimed of cartographic visualisation in order to minimise distortions. Both should be chosen under the strong consideration of the visualisation purpose.

The current prototype has a storage (EOC Geoservice) and a visualisation component based on the UKIS. The storage and management of the research data are already at a very good level through the use of the EOC Geoservice (see Figure 5).

Considering the need for visualisation, the types of research data should be considered separately, i.e., the referenced and visualisable, as well as the referenceable, but spatially not visualisable research data. The first part contains raster- and vector-based data at the same time. The raster-based data are displayed by the UKIS at full resolution and contain the predefined cartographic symbolisation of the raster values, and thus are perfectly visualised. The vector-based data are displayed accurately without gaps in scale and resolution (see Figure 6). The cartographic symbolisation needs further adjustments within the system in order to visualise, e.g., different coloured polygons related to defined data attributes. For example, this could be solved by integrating additional descriptive files such as Styled Layer Descriptors (SLD) [84] for web-based vector data visualisation. The current display of both data types is limited to a Mercator-based projection die to the lack of projections of celestial bodies in general and Ceres in particular (see Figure 6). Once projections for celestial bodies are defined and available in common software tools (PostGIS, GeoServer, Openlayers), the visualisation can be optimised.

The second part, the referenceable, but spatially not visualisable data, is integrated via linking external data sources. In the first instance, scientific publications are linked via a spatial description of the investigation area.

In a next step of the development process, two important issues need to be addressed and solved:

First, the visualisation of vector-based data requires further adjustments in order to reflect, e.g., the well-known illustration of colourful geological maps. For example, this could be solved by integrating an already mentioned SLD file, which describes the visualisation character of vector graphics for a web-based display. Secondly, it has to be discussed and defined which further formats have to be integrated via an external data storage in order to include the great quantity and quality of further referenceable, but spatially not visualisable data.

Requirement #2 (R#2) refers to the fact that the research data to be provided are all related to each other via a spatial reference, either directly, i.e., referenced, or indirectly, i.e., referenceable. This means the system must understand both the data description and enable the query of the research data in order to make their cross-references usable.

The current prototype is capable of linking spatial planetary data, i.e., retrieved by queries to the system’s backend, with corresponding publications, i.e., retrieved by queries to the institute’s literature database (see Figure 7) via attributes of the spatial data. In a next step, the system should also include further secondary research data, which are spatially referenceable (indirectly referenced). Exemplary datasets here are spectral plots/diagrams derived from spectral images (cf., e.g., the figures in [85,86,87,88]) or plots that show the results of crater counting. This allows the scientific community to produce statistical crater chronologies, as well as statements about the absolute ages of surface units on terrestrial planets (cf., e.g., the figures in [89,90,91,92].

A combination of Requirement #1 and #2 is given by Requirement #3 (R#3). This requirement refers to a proper and suitable availability of the referenced and referenceable research data within a web-based structure. Therefore, the OGC-compliant interfaces WMS and WFS represent a perfect environment (see Section 4).

Thus, the backend (server component) and frontend (client component) of the current prototype implements the OGC-compliant interfaces WMS and WFS. The backend’s interfaces give the user the possibility to easily access the research data, start spatial and further attributive queries, and use these for further scientific investigations.

Moving on with the development, the interfaces of the research data management system should (1) provide further functionality for downloading data. This is essential in order to serve the scientific community with valuable data for further investigations. It shall also (2) allow queries on object level. That means, e.g., if a vector-based dataset such as a geological map is given, it should be possible to query not only via the descriptive items on the metadata level, but also on the attribute level, e.g., object size, geomorphological attributes, unit genesis, etc. To accomplish these open tasks within the planetary domain in terms of research data provision, it may be very helpful that a request for a new Planetary Domain Working Group (DWG), OGC for Planetary Science, has been made in the recent past (see [93]). This DWG has the objectives to revise or extend existing OGC standards for celestial bodies other than the Earth, in order to improve the “efficiency and effectiveness of spatial data as used in planetary research and education through supporting the propagation of interoperable geospatial products and other information consumables that can be shared across the community” [93].

In the future, the service component may allow for interactive editing of mapping results via transactional extensions of the WFS interfaces (WFS-T). Furthermore, the next generation of the OGC standards is currently being developed known as the OGC API family of standards [94]. These OGC APIs facilitate access and integration into web-based frontends through a more modern resource-centric approach and web-friendly JSON encoding.

In addition to providing research data, a working group of this type could also assist in web-based data visualisation and analysis. Therefore, the extraterrestrial reference systems and cartographic projections of the planetary bodies are necessary.

In Requirement #4 (R#4), a key component, i.e., reusability, is mentioned. In order to reach this for every individual dataset, in additional to provisioning and visualizing research data, it is necessary to describe the content of the dataset in detail, concerning the geometry and attributes. To implement this, a bundle of descriptive elements in the form of metadata needs to be defined. The choice of metadata entries depends on the different quality levels of the research data. That means a selection of metadata entries is needed that describes the different research data by “the most common sense”. That is, a description as superordinate as possible, but also as detailed as needed is required. Thus, metadata should be divided into mandatory and optional description entries. In the domain of spatial data, different metadata standards already exist that can be used for these purposes. The most essential ones are ISO 19115 Geographic Information—Metadata [95], Dublin Core Metadata Initiative (DCMI) [96], or the standard established by the Federal Geographic Data Committee (FGDC) [97,98]. These standards differ in their level of detail and whether they can be used free of charge or are subject to a fee. A more specific standard for the planetary domain is the Planetary Data System Standard Reference (PDS standard) [99], which is the de facto standard for all planetary data. Via this standard, all planetary mission data that are archived on PDS or PSA archives, that is the primary research data, are already described. As a consequence, these data are already retrievable and reusable via the geometrical and imaging parameters.

However, in order to implement the descriptive criteria also for the secondary research data, it is essential to distil an applicable set of metadata entries for this purpose. The challenge here is that the secondary research data would also need a semantic description in order to understand the scientific result. Just secondary research data could be fully evaluated with respect to their quality in order to use them as input for further studies.

The sample spatial dataset used for the current prototype is divided into two data types: raster- and the vector-based data. As the raster datasets are already archived in PDS, they contain a detailed PDS description. The vector-based data are also published, not as data files, but as supplementary material within a journal publication (see Section 3.3). That means the semantic description needed for developing an understanding of the research result is not included thus far. In order to do so, semantic information such as keywords, interpretation highlights, analysis methods, additional interim results, etc., have to be assigned manually. This would enable the valuable content-related linking of the different research data, which can be used in the following, for example, as supplementary search criteria.

In a next and sustainable step of development, the semantic entries should be included automatically via existing standards. Therefore, it seems applicable to use the FGDC standard for metadata [97,98], so that the secondary research data are describable via the proper and hierarchical structure of the metadata entries. This standard is also adopted for the repository Astropedia [100], which is hosted by the USGS Astrogeology Science Center and serves the community with scientific results within a planetary data and cartography catalogue.

Two noteworthy metadata entries in the FGDC standard for metadata (see [97], page 16) are the indirect and direct spatial reference, which can be found within the third part of the standard Spatial Data Organization Information. Here, the spatial reference of data is described via the inherent characteristic of the reference information. Moreover, it could be described via indirect spatial reference information, such as the names of local features or planetary bodies (as free text), in order to make other data referenceable. Another important entry can be found within the fifth part Entity and Attribute Information of the FGDC standard (see [97], page 37), where it states that it handles details about the information content of the dataset, including the entities types, their attributes, and the domains from which attribute values may be assigned. [97]. With the help of this entry, the description at the semantic level could be improved either at the overview level, i.e., a summary of and/or citation to a detailed description of the dataset, or at the detailed level, i.e., a description of the entities, attributes, attribute values, and related characteristics encoded in the dataset (see [97] for more details).

A way for merging different standards that could be useful for the description of secondary data in general and mapping data in particular was discussed in [101].

Within Requirement #5 (R#5), one important point is mentioned, which refers to the assignment of permissions and usage rights. The system is built for published, but also for still restricted research data. Thus, a user management system is needed that regulates the access to open data and data restricted to specific user groups.

Currently, the prototype contains a simple access restriction. Users are asked to enter a username and a password in order to display data (see Figure 8). However, this system does not distinguish between different user groups, respectively personal accounts. Furthermore, for external users (outside the DLR structure), it is not allowed to visualise and access the data.

In a next step, a more sophisticated solution has to be implemented to create the different access levels as described above.

Requirement #6 (R#6) emphasises that the source code of the application needs to be open source in order to comply with open access guidelines. This topic is not specifically characteristic for planetary research or DLR, but rather refers to current discussions and developments in the context of the open science movement (cf. Section 1). Moreover, the use of open-source software makes sense from a technical point of view. Adaptations of existing technologies for a new use case are particularly easy with open software.

The described prototype is completely built on open technologies. The EOC Geoservice is based exclusively on open software from the field of data management and provision. The UKIS frontend also relies on existing open software. Moreover, the UKIS frontend as the framework of the graphical user interface is itself available under an open-source license on the Internet [76]. In the course of the development of the prototype, various improvements to the technical basis of the UKIS were released as open source. A future next step can be the publication of the source code of the system components developed specifically for the planetary research data management system.

Considering the definition of open science, it would also be desirable to distil rules and concepts for pushing forward the topic of open data within planetary science.

In Requirement #7 (R#7), the demand for a user-friendly web-based research data management system with basic GIS functionalities is mentioned. The reason for this is (1) the fact that the major part of our data has a direct spatial reference or could be referenced indirectly. Thus, (2) existing GIS technologies for the web-based provision and visualisation of data perfectly fit into that scope. However, in order to attract not only traditional disciplines using GIS functionalities, such as geology and geodesy, but also other areas of planetary research, such as physics or atmospheric modelling, the functionalities of the research data management system should be limited to the essential components. Besides visualisation, this includes in particular the spatial and attribute-related selection of the research data.

The current prototype is based on a well-established architecture for web-based GIS. The main system components—frontend and backend—are built upon modern technologies such as the EOC Geoservice and the UKIS. The UKIS frontend features an intuitive user guidance based on the experience of ten years of software development. It shows that the requested functionalities, especially the spatial visualisation and the search for additional research data, are possible. Via attributive linkage of other data repositories, a literature database such as elib could easily be connected. The UKIS as a mature framework for geoscientific web applications has been furthermore tested to work with all major desktop browsers.

In a next step, it should be tested to what extent the system could be enlarged via more detailed data requests, at a spatial feature level and not limited to metadata. This data management at the feature level could also pave the way for, e.g., simple analysis functionalities.

The final Requirement #8 (R#8) covers the need for user guidance. A manual is essential in order to achieve acceptance in the user community that will use the system—either for uploading their scientific results or as a source for data retrieval (research data and publications) for further studies.

The current prototype comes with a short tutorial in PDF format in order to introduce the basic functionalities of the graphical user interface. Our goal is the continuous development of the system, adding new functionalities (e.g., further and/or more complex metadata query options) and also data (e.g., from other planetary bodies and/or missions). The manual will be kept up to date accordingly.

6. Conclusions and Outlook

This paper reported on the conceptualisation and development of a working prototype of an institutional research data management system. The principal idea is the management of research data produced by and with the contribution of institutional units. In detail, this contribution had two foci: First, we presented a concept for the management of secondary research data from different disciplines in the field of planetary science. At the centre of our approach was the spatial reference (direct or indirect) of the research data. Second, the prototypical implementation of the concept had to be as resource-saving as possible. Thus, we built on existing software from the field of geosciences.

The use case was developed and demonstrated for the DLR Institute for Planetary Research. A centralised managed data and information node forms the basis for the long-lasting scientifically and financially sustainable management and handling of research findings. This approach allows the scientific community to build cross-links via spatial–temporal relations and metadata. Consequently, this allows improving cross-discipline comparisons of research data across different missions, in order to build on top of pre-existing information and knowledge. This topic furthermore fits into the current discussion about data availability in the context of open science, in particular for publicly funded research data. As the majority of research data have a spatial reference, either direct or indirect, web-based GIS-technologies appear to be a suitable development environment, but they are not limited to this. Therefore, in this approach, we adapted technologies originally developed for storing and visualizing Earth-based spatial data (geodata) and applied them to serve in the context of planetary sciences by addressing domain-specific needs. Here, the UKIS, as a DFD-developed software framework for web-based GISs, together with a geospatial data access and data management service, such as the DFD-hosted EOC Geoservice, form an ideal basis for a spatial data platform due to their flexibility and stable architecture. Both frameworks can be adapted to planetary spatial reference systems via specific system adjustments, in order to provide and visualise planetary data.

By introducing the field of application, user and system requirements, a use case, as well as a related sample dataset, objectives, and first steps for a structured development were outlined. The second step was the adaptation of the DFD developments and implementation of a prototype for a research data management system divided into its backend and frontend functionalities. In the third and final step, the development of the current prototype was evaluated by a detailed discussion and review of how the requirements were fulfilled. For the time being, public access is restricted as the developed system is targeted at the institutional level and the benefit for the public would be non-existent. Underlying framework specifications have been published and were referenced within this contribution. Modifications, adaptations, and implementations based on the requirements’ reviews were described in detail. Moreover, a technical demo application of the used framework, the UKIS, is available on GitHub (https://dlr-eoc.github.io/ukis-frontend-libraries/#/example-layers, accessed on 2 December 2021).

Based on our discussion, we conclude that on an overarching level, the developed framework constitutes a fully functional prototype of a research data management system. More specifically, this means (1) that the backend based on EOC Geoservice is capable of storing data from missions in a well-structured way, (2) that the EOC Geoservice is capable of providing data via standardised web interfaces, (3) that a frontend based on UKIS is capable of consuming data via EOC Geoservice’s interfaces, and (4) that the frontend implements an interface with the institutional electronic library elib. The last point is essential as it demonstrates the flexibility for linking further research data sources with their own interfaces in the future.

Bundling existing expertise and resulting synergies offers significant advantages: For the institution, efficient and cross-divisional and cross-departmental access to existing information and insights can be achieved. In the future, this can be further developed to an even higher level in order to establish a nation-wide node for the provision of planetary data and information.

An extension of the current development in the future would be very beneficial in order to enable multi-parameterised queries across different data types, multiple missions, and scientific disciplines in planetary science. The participation of the institute in recent and upcoming orbiter missions to Mars (ExoMars (https://www.esa.int/Science_Exploration/Human_and_Robotic_Exploration/Exploration/ExoMars, accessed on 2 December 2021)) and Mercury (BepiColombo (https://sci.esa.int/web/bepicolombo, accessed on 2 December 2021)) and to the moons of the Outer Solar System (JUICE (https://sci.esa.int/web/juice, accessed on 2 December 2021); see also [102]) would give new impulses for systematic analyses and mapping of planetary bodies and push further demand for efficient management and provision of research data. The new developments in the future should cover an expanding variety of different planetary research data types, on the one hand, and additional tools for rudimentary, but domain-specific analyses, on the other hand. However, it should also be noted that regardless of whether it is a question of medium-term support for current developments, or expansion to include new data quality and quantity, or possible expansion with analysis tools, long-term support, and thus also financing of the research data management system presented here, will be a decisive factor.