Digital platform (GIS system) for managing spatial data on wetlands

Abstract

A digital platform (GIS system) for managing spatial data on wetland habitats. The platform is aligned with international standards in the spatial information domain, enabling a fast, efficient, and high-quality way of managing and analyzing data without direct contact with the object and without the need for field research.

Description

[0001] Digital platform (GIS system) for managing spatial data on wetlands.

[0002] DESCRIPTION

[0003] The invention relates to a digital platform (GIS system) for managing spatial data on wetlands collected by integrated multi-sensor measurement systems, which include the collection of spatial data from the air and from the water body.

[0004] Databases on wetland habitats are of exceptional importance for aligning measures with the ecological needs of species and habitat types. For instance, the EU Floods Directive emphasizes giving more space to rivers and maintaining and / or restoring floodplains.

[0005] Users of such databases include governments, environmental protection organizations, as well as land and resource management practitioners, farmers, or fishermen.

[0006] Many developed countries, including Croatia, have completed the collection of topographic data for the entire country, and various datasets are available on the market, including data on wetland habitats. However, existing datasets are not tailored to users' needs and have limited diversity in classification systems and the level of detail in mapping.

[0007] The purpose of the present invention is to address the mentioned shortcomings of existing wetland habitat datasets and to create the HABIGIS web application adapted to international standards in the spatial information domain.

[0008] The digital platform (GIS system) consists of a database management system, server, geoserver, and user interface. For the HABIGIS system, PostgreSQL version 15.1 extended with PostGIS extension version 3.3 is used. The main reason for choosing PostgreSQL is the available extension that adds support for geographical objects enabling spatial queries in SQL - PostGIS. The spatial component in SQL queries can significantly speed up processing if used correctly. Besides faster processing, there is a wide range of spatial functions that PostGIS offers.

[0009] The Django framework is used to create the application programming interface. Django is an open source web development environment written in the Python programming language. It's a high-level framework that promotes fast and secure web application development using pure and pragmatic design. For the HABIGIS system, Django is primarily used to create an API with a REST architectural style. The API, or application programming interface, facilitates structured data transfer between software applications, specifically between the backend and frontend parts of the system in this case. This approach enables the complete separation of development and serving of the backend and frontend components of the application, making further system development and maintenance easier and contributing to better overall application performance and security.

[0010] To serve the developed Django application or API, Daphne is used as an application server for ASGI (Asynchronous Server Gateway Interface). It's designed to provide a standard interface between asynchronously capable Python web servers, frameworks, and applications. By utilizing this application server, the system offers the development of more advanced functionalities within the web application, such as using websockets to implement direct communication between the client (browser) and server. Additionally, it enables the development of background asynchronous processes for automatically executing more complex tasks.

[0011] International standards covered by HABIGIS:

[0012] 1. The facility catalogue is based on a JRC template developed on the basis of ISO 19110:2003 Geoinformation - Methodology for the cataloguing of facilities

[0013] The inventory of objects serves to document all types of objects and their properties and is necessary for the conversion of spatial data into useful information. Such data catalogues shall promote the dissemination, sharing and use of spatial data by providing a better understanding of the content and meaning of the data. One of the purposes of catalogues is also the use of well-defined spatial types of objects that can use different application schemes.

[0014] To convert data into useful information, catalogs of objects are indispensable because they define the types of objects, their operations, attributes, and relationships of geodata. If the provider and user of geodata do not share an identical understanding of the real- world phenomena that these data represent, users are unable to assess whether this data suits their needs.

[0015] ISO 19110 standard provides a standardized framework for organizing and documenting the classification of real-world phenomena into a set of geodata. Each set of geodata is a significantly simplified and reduced abstraction of the complexity and diversity of the real world. A catalog of object types cannot encompass the richness of geospatial reality. However, such a catalog of objects should be a specific abstraction presented in a clear, precise manner, and in a form that will be understandable and acceptable to data users.

[0016] Geospatial data has a dual manifestation: instances and types. At the instance level, a geospatial object is represented by a discrete phenomenon that is linked to its spatial and temporal coordinates and can be displayed by a specific graphical symbol. These individual object instances are grouped into classes with common characteristics - object types. It is known that each geoinformation is subjectively perceived, and its content depends on a specific application. The need for a specific application determines how instances are grouped into types in certain classification schemes.

[0017] While the full description and content of the structure of a set of geodata are given in an application schema developed in accordance with ISO 19109, the catalog of objects defines the meaning of object types and their attributes, operations, and relationships contained in the application schema.

[0018] The collection criterion used to identify individual real-world phenomena for their representation as object instances is not specified in this international standard. Because it is not included in the standard, the collection criterion should be separately included in product specifications for each dataset separately.

[0019] A standardized way of organizing information in the catalog of objects will not automatically result in the harmonization or interoperability of applications. In situations where object classifications differ, this international standard can serve to clarify differences and thus help avoid errors that may arise from ignoring them. It can also serve as a standardized framework within which catalogs of objects within matching application domains could be harmonized.

[0020] The main requirement of ISO 19110 is that the names of all object types, their attributes, relationships, and operations contained in an individual catalog of objects must be unique. If one name appears multiple times in the catalog, the definition of that element must be identical.

[0021] Definitions of all catalog elements must be described in natural language. The application of alphanumeric codes is recommended for the unambiguous identification of all object types, attributes, and relationships. For each attribute, specifying the data type that its values can take is recommended. Although recommendations, the ARKOD catalog of objects fulfills this segment as well.

[0022] The current version in effect is 19110:2005, from 2005. The new version of the ISO 19110 standard utilizes formal language to a greater extent for description (UML):

[0023] • Instead of using the element name 'version number' in catalog description, the attribute name defining that element is now used - 'versionNumber.'

[0024] • Data types are standardized - for instance, instead of text as the data type for the 'Producer' attribute, a complex type CI_ResponsibleParty defined in ISO 19115 Metadata is now used.

[0025] 2. The use of the UML profile specified in ISO / TS 19103 and 19109 for describing the application schema at a conceptual level

[0026] Closely related to the catalog of objects is the application schema and data specification.

[0027] The application schema is a conceptual data schema for a specific application. Besides defining the content and structure of data, the application schema specifies services for application access and data management. The application schema specifies specific objects in the observed domain that represent a particular view of the real world according to the information requirements of that domain. Spatial object types, along with their definitions, properties, possible constraints, and operations, form the meaningful core of the target concept. In other words, the application schema describes the semantics of the model. The application schema is described in a formal language, the language of the schema. In the geoinformatics community, the practice is to use the UML profile specified in ISO / TS 19103 and 19109 to describe the application schema at the conceptual level.

[0028] ISO standard 19109 Geoinformation - Rules for application schema defines rules for creating and documenting application schemas, including the principles of object definition.

[0029] The purpose of the application schema is twofold:

[0030] • It provides a description of data with definitions of their structure that is understandable to computers, enabling the application of mechanisms for automatic data management.

[0031] • It achieves identical and correct understanding of data by documenting data content for a specific field of application, allowing unambiguous referencing of desired information.

[0032] ISO 19109 does not standardize application schemas; it only defines rules for creating application schemas in a consistent manner (including consistent object definition), thereby facilitating the collection, processing, analysis, access, display, and transfer of geodata among different users, systems, and locations. In the case of data transfer or exchange, the rules from this standard can be used by both geodata providers and users for:

[0033] • Creating an application schema for data exchange.

[0034] • Translating the semantics of the dataset being exchanged concerning the user's structure of local data.

[0035] • Determining the necessary transformations between two datasets.

[0036] The rules outlined in this international standard assist users of similar data requirements in applications in developing a common interface between the application schema of their system and data. Mapping from one application schema to another can be challenging or even impossible if the two schemas are too divergent. ISO 19118 defines the encoding of a specific dataset defined by one application schema in UML. 3. The system is tailored to meet the requirements of INSPIRE.

[0037] By adhering to the harmonization framework set by INSPIRE, interoperability within the European Spatial Data Infrastructure (ESDI) is achieved. Each member country will maintain its own national infrastructure but will adapt to a framework that will facilitate linking existing datasets through interfaces for transforming heterogeneous data into a unified model.

[0038] The identical approach to achieving interoperability at the European Union level can be applied within the National Spatial Data Infrastructure (NIPP) of the Republic of Croatia, where every entity is obliged to comply with the harmonization framework by adjusting its system to the requirements of NIPP directly derived from INSPIRE requirements.

[0039] The adaptation of a system to INSPIRE requirements occurs on several levels:

[0040] 1. The first level is content-based, involving aligning existing spatial data of member states with data specifications for themes outlined in the annexes of INSPIRE.

[0041] The targeted theme to which HABIGIS data should conform is a theme from Annex III of the INSPIRE Directive - Habitats and Biotopes (abbreviated as HB). The data model of this theme pertains to information about geographical areas characterized by special ecological conditions, structure processes, and functions (for maintaining life) that physically support organisms living within them. This includes terrestrial and aquatic areas differing in geographical, abiotic, and biotic features, whether entirely natural or semi-natural.

[0042] The 'Habitats and Biotopes' category of spatial data defined in the INSPIRE Directive is one of several themes within the broader group of biological organisms and communities - biodiversity. It encompasses habitats and biotopes as areas and their boundaries. Common to all spatial data falling under this category is the characterization of geographic area distributions that function as living organism functional surfaces, biotopes that are the spatial and biotic environment of a biotic community / biocoenosis, while habitats are the spatial environment of specific species. Climate, geological, chemical, and biological conditions influence the distribution of species and communities, thus affecting the distribution and conditions of habitats and biotopes. Some species have strict specific requirements for the environment, while others accept a wide range of environmental conditions. Hence, biotopes and habitats can widely vary among different organisms. Some species alter biotopes throughout the year, with changes during seasons or due to migration. Some habitats / biotopes depend on management, e.g., all types of cultivated landscapes. Time series mapping can be used to identify changes in biotopes / habitats.

[0043] Describing living surfaces for any biota species is primarily used to describe areas used by zoo-biota. Habitats commonly follow geo-botanical / bio-geographical areas / vegetation types. In broad terms, land cover classes and vegetation classes represent terrestrial habitats. Habitats can also be described at a more detailed level, e.g., hedges, streams, etc. In the sea, differences in temperature, salinity, currents, depth, topography, and geology of the seabed can form different habitats. Habitat and biotope data can be produced through field mapping, remote sensing, interpretation of aerial photographs, or modeling.

[0044] Different documents and communities follow various definitions for habitats and biotopes. An example is Council Directive 92 / 43 / EEC on the Conservation of Natural Habitats and Wild Fauna and Flora. EUNIS has been developed as international nomenclature for habitats. Different countries or communities have different classification systems. Difficulties may arise in accurately mapping specific habitat classes between national nomenclatures and also between national and European nomenclatures. To find common European definitions and nomenclatures, it's necessary to consider both national systems and the different definitions used by international communities.

[0045] Habitats and biotopes only include areas represented by natural boundaries classified by their ecological or physical state. Habitats and biotopes labeled as protected areas are not included, as they fall under another category of the INSPIRE theme, mainly 'Protected areas,' as they represent regulations of administrative areas rather than ecologically- based boundaries. Expressions like 'natural' or 'semi-natural' need clarification. Artificial landscapes that are habitats (cultivated landscapes like urban areas, cultivated land, orchards, pastures, etc.) can be defined to be outside the scope of this theme.

[0046] These data specifications should not be seen as a separate entity from other INSPIRE themes or other EU reporting obligations, and during its initial development, it was noted that new user requirements are expected to expand the data model.

[0047] Assessments of landscape changes and impacts on wildlife and flora. Linked to the Habitat Directive. Habitats defined by the Directive are mentioned in the 'land surface regulation' data component.

[0048] The selection of valuable habitats is determined by Directives for habitats and birds. In the marine environment, the selection of valuable habitats is also determined by the OSPAR and HELCOM conventions.

[0049] It's documented and used to identify biological diversity within regions or countries, such as geographical representation, diversity, and frequency of representation. It's used for planning the protection and management of biodiversity in natural, semi-natural, and artificial environments. Users include governments, environmental protection organizations, as well as land and resource management practitioners, farmers, or fishermen. A wide variety of different classification systems and levels of detail in mapping.

[0050] • Scale: Indication of the usual mapping scale: from 1 :5,000 to 1 :1 ,000,000.

[0051] • Community policy: 6EAP, Habitat and Birds Directive, CAP.

[0052] • Initiatives: NATURA2000, RAMSAR database, CORINE habitats, etc.

[0053] Examples of data:

[0054] Biotopes areas: Areas of ecological biodiversity interest, captured under the Natura program. Sites of specific ecological interest in nature conservation captured whether protected or not. Attributes: statistics from site, habitat data, mammals, birds, amphibians, fish, invertebrates, plants, marked site status.

[0055] Important object types and attributes:

[0056] Biotop (area):

[0057] Classification / Nomenclature system

[0058] Category hierarchy level

[0059] Category name

[0060] Category code

[0061] Mapping date: verification date

[0062] Species or typical species found in the biotope

[0063] Site description

[0064] Habitat area:

[0065] Classification / Nomenclature system

[0066] Category hierarchy level

[0067] Category name

[0068] Category code

[0069] Mapping date: verification date

[0070] Species or groups of species to which the habitat relates

[0071] Site description

[0072] HABIGIS uses a Single Object Type in this application scheme - Habitat (HB), defined by attributes: habitat - type HabitatTypeCoverType habitatSpecies - type HabitatSpeciesType habitatvegetation - type HabitatVegetationType

[0073] The definition of the object type Habitat is as follows: Geographic areas characterized by specific ecological conditions, processes, structure, and functions that physically support the organisms living there.

[0074] Identifier Management

[0075] HB data specifications use the INSPIRE data type Identifier to create an Inspire identifier - the Inspireld attribute, defined by the generic conceptual model (DS-D2.5 General Conceptual Model). The INSPIRE data type Identifier is a complex type consisting of an internal identifier of the system from which the object comes (HABIGIS identifier) - localld, and the namespace of the data source and optionally a version number to enable versioning, i.e., tracking the object's life cycle. For example, in geographic names, the syntax of the Inspireld element would look like this: gn:inspireld

[0076] <base: Identifier xmlns:base="urn:x-inspire:specification:gmlas:BaseTypes:3.2"> base:localldHRRGIIM00000002< / base:localld> base:namespaceHR.CGI.GN< / base:namespace>

[0077] < / base: Identified

[0078] < / gn:inspireld>

[0079] Temporal Representation of Objects

[0080] In addition to the temporal elements beginning and end of the object's life cycle (attributes beginLifespanVersion and endLifespanVersion), the HB model includes attributes:

[0081] • ValidFrom: an attribute describing the exact date when the data became valid in the real world (the beginLifespanVersion attribute refers to the date the data originated in the dataset). • ValidTo: an attribute defining the exact date when the data became valid in the real world (the endLifespanVersion attribute refers to the date the data was removed from the dataset).

[0082] As it was not possible to identify data on the creation of a specific reference parcel or agricultural holding in the real world, and these attributes are not mandatory, in the adaptation of HABIGIS data to the HB application schema, only the attributes related to the date of creation corresponding to the beginLifespanVersion and endLifespanVersion attributes were used.

[0083] Geometric Representation of Objects

[0084] Article 12(1) of the implementing rules for the interoperability of spatial datasets and services restricts the value1domain of object spatial properties to the Simple Feature spatial schema according to the OpenGIS® implementation standard for geoinformation - Simple feature access - part 1 : Common architecture, version 1.2.12unless a specific theme or data type explicitly defines otherwise. The equivalent ISO standard defining the Simple Feature spatial schema is EN ISO 19125-1. It limits the spatial schema to 0-, 1-, and 2-dimensional geometric objects that can exist in a 2-dimensional coordinate space, excluding the use of a 3rd coordinate.

[0085] Coordinate System

[0086] INSPIRE requires spatial data in coordinate systems based on the ETRS89 reference ellipsoid for continental and ITRS outside continental Europe. As the HABIGIS data is in the HTRS96 coordinate system based on the ETRS89 reference ellipsoid, it automatically complies with this requirement.

[0087] Mapping Data Schema of HABIGIS to INSPIRE Habitat and Biotopes Theme

[0088] 1REGULATION (EU) No 1089 / 2010 of 23 November 2010 on implementing Directive 2007 / 2 / EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services concerning spatial data.

[0089] 2htps: / / portal.opengeospatial.org / files / ?artifact_id=25355 Data schema harmonization is the process of identifying semantic similarities between two definitions of object types from different data models. Data mapping is the specific transformation of data from one schema to another, usually performed based on a clearly defined mapping schema. Mapping schemas can be implemented in various ways, with the most common being .xml files (XSLT transformations) or Excel spreadsheets (attached .xsl file).

[0090] 2. The second level is technical, involving enabling access to data through INSPIRE web services.

[0091] INSPIRE Web Services

[0092] INSPIRE web services are based on international ISO and OGC standards, with additional requirements for multilingualism and describing the web service itself. Standard GIS applications "read" INSPIRE web services in the same way as standard ISO / OGC web services, disregarding additional elements contained in INSPIRE web services. To utilize the additional functionalities of INSPIRE web services, it's necessary to use appropriate clients compliant with INSPIRE, such as the INSPIRE geoportal. HABIGIS utilizes INSPIRE browsing and download services.

[0093] View Services

[0094] INSPIRE View Services enable users or software applications to view spatial datasets. The service is thoroughly described in the technical guidance for the implementation of view services (Technical Guidance for Member States to implement INSPIRE View Services3).

[0095] The view service is based on ISO standard 19128 - Web Map Service (WMS) version 1.3.0 and can be implemented using OGC specifications: WMS 1.1.14or Web Mapping

[0096] 3htp: / / inspire.jrc.ec.europa.eu / documents / Network_Services / TechnicalGuidance_ViewServices_v3.ll.pdf

[0097] 4htps: / / portal.opengeospatial.org / files / 7artifact Jd=1081&version=l&format=pdf Tiling Service - WMTS 1.0.05. In addition to the mentioned standards, the technical guidance also utilizes OGC specifications to define display symbology: Styled Layer Descriptor6[OGC SLD] and Symbology Encoding Implementation7[OGC SEIS].

[0098] The technical guidance for implementing view services defines an INSPIRE profile based on the WMS standard for implementing the following operations:

[0099] • Get View Services Metadata: retrieving metadata about a specific web service - INSPIRE extension of the standard GetCapabilities operation of WMS.

[0100] • Get Map: an operation that returns a map of a specific area - equivalent to the GetMap operation of WMS.

[0101] • Link View Service: enables the linking of view services.

[0102] Additionally, it specifies how multilingualism needs to be implemented.

[0103] Implementation rules for INSPIRE web services require that these services respond to requests for retrieving service metadata with parameters not included in the standard parameters of OGC GetCapabilities response. Therefore, these parameters need to be implemented through extended capabilities mechanisms.

[0104] Download Services

[0105] INSPIRE download services enable users or software applications to download spatial datasets. The service is thoroughly described in the technical guidance for the implementation of download services (Technical Guidance for Member States to implement INSPIRE Download Services8).

[0106] The INSPIRE directive mandates member states to establish and maintain a network of download services, enabling the download of copies of spatial datasets or parts of these datasets, and where possible, direct access to data. Furthermore, when public authorities

[0107] 5htp: / / portal.opengeospatial.org / files / ?artifact_id=35326

[0108] 6htp: / / portal.opengeospatial.org / files / 7artifact_ich22364

[0109] 7htp: / / portal.opengeospatial.org / files / 7artifact_ichl6700

[0110] 8htp: / / inspire.ec.europa.eu / documents / Network_Services / Technical_Guidance_Download_Services_v3.1.pdf charge for download services, member states will ensure the possibility of e-payment for the service (including Rights Management Services).

[0111] According to the implementation rules for web services, the download service must support the following four operations:

[0112] • Get Download Service Metadata - retrieve download service metadata

[0113] • Get Spatial Dataset - retrieve spatial dataset

[0114] • Describe Spatial Dataset - describe spatial dataset

[0115] • Link Download Service - link download service

[0116] 3. The final level of compliance is also technical, focusing on the quality of web services through which spatial data access is facilitated.

[0117] The implementation rule for web services requires ensuring service quality criteria related to performance, capacity, and availability. As the State Geodetic Administration (SGA) has taken over the establishment of the discovery service through the implementation of the NIPP geoportal, the criteria fulfilled by the HABIGIS platform, aligned with the NIPP portal, are outlined below.

[0118] 1. PERFORMANCE

[0119] 7.7. View Service

[0120] For an image of 470 kilobytes (e.g., 800x600 pixels with 8-bit color depth), the response time for sending the initial response to a "Get Map" request to the view service is a maximum of 5 seconds under normal circumstances.

[0121] Normal circumstances represent periods outside peak load, set at 90% of the time, meaning the result will be based on the 90% best results. Continuous performance measurement of the view service is required by sending a minimum of ten reference requests per hour throughout the service's lifecycle. 1.2. Download Service

[0122] For the Get Download Service Metadata operation, the time to send the initial response will be a maximum of ten seconds under normal circumstances.

[0123] For operations like Get Spatial Data Set and Get Spatial Object, as well as queries consisting solely of spatial coverage, the time to send the initial response will be a maximum of 30 seconds under normal circumstances. Additionally, the download service must maintain a response of at least 0.5 MB per second or more than 500 spatial objects per second continuously.

[0124] The request for the Get Spatial Object operation must necessarily include the BBOX parameter. In cases where the service allows downloading multiple different object types or datasets, it suffices for the request to contain one object type or dataset.

[0125] For the Describe Spatial Data Set and Describe Spatial Object Type operations, the time to send the initial response will be a maximum of ten seconds under normal circumstances. Additionally, the download service must maintain a response rate of at least 0.5 MB per second or more than 500 descriptions of spatial objects per second continuously.

[0126] Normal circumstances denote periods outside peak loads, set at 90% of the time, meaning the measurement results will be based on the 90% best results. To assess the download service's performance, continuous measurement is required by sending a minimum of ten reference requests per hour throughout the service's lifecycle. To prevent prolonged operations, the number of requests can be reduced by delaying sending a new request for up to six minutes after the completion of the previous request.

[0127] 2. CAPACITY

[0128] 2.1. View Service

[0129] The minimum number of served simultaneous requests to the view service, in accordance with the service's performance quality, will be 20 per second. Testing involves sending 20 reference requests per second over a period of one minute. It's recommended to conduct this testing once a month during off-peak usage times of the web service. Combining Get Map requests (90% of requests) with Get View Service Metadata (10% of requests) is preferable.

[0130] 2.2. Download Service

[0131] The minimum number of served simultaneous requests to the download service is 10 per second. The number of parallel requests supported by the service is limited to 50.

[0132] Testing involves sending 10 different requests per second over a period of one minute. It's recommended to conduct this testing once a month during off-peak usage times of the web service.

[0133] It is advisable to combine requests such as Get Spatial Data Set or Get Spatial Object (80% of requests), Get Download Service Metadata (10% of requests), and Describe Spatial Data Set or Describe Spatial Object Type (10% of requests). A minimum of 2% of requests must consist of the Get Spatial Data Set request.

[0134] AVAILABILITY

[0135] 3.1. Browsing and Downloading Services

[0136] Browsing and downloading network services will be available 99% of the time. The service's availability needs continuous measurement by sending at least ten reference requests per hour throughout the network service's lifetime. As the availability measurement request is identical to the performance measurement request, it is recommended to send an identical request that would measure both quality criteria. The period for measuring availability is one year during which the network service can be unavailable for a maximum of 3.63 days. It is important to note that periods of planned maintenance announced at least one week in advance are not counted as unavailable service time. The recommended maintenance time is up to 10 hours per month.

Claims

PATENT CLAIMS:

1. Database for managing spatial data on wetland habitats, indicated as a digital platform (GIS system) consisting of:- database management system,- server,- geoserver,- user interface, wherein the database management system is PostgreSQL version 15.1 extended with PostGIS extension version 3.3.

2. Database according to patent claim 1 , indicated as using the Django development environment with REST architectural style for creating the application programming interface.

3. Database according to patent claim 2, indicated as using Daphne as an application server for ASGI (Asynchronous Server Gateway Interface) to serve the developed Django application.

4. Database according to patent claim 1 , 2, or 3, indicated as having an Object Catalog created according to the JRC template based on ISO 19110:2003 Geoinformation - Methodology for cataloging objects.

5. Database according to patent claim 1 , 2, 3, or 4, indicated as using a UML profile specified in ISO / TS 19103 and 19109 to describe the conceptual-level application schema.

6. Database according to patent claim 1 , 2, 3, or 4, indicated as being compliant with INSPIRE requirements.