Software Architecture Document€¦ · Common Strategy for sustainable territorial development of...

Common Strategy for sustainable territorial development of the cross-border area RO-BG Project MIS ETC CODE 171

MIS-ETC-CODE171 PROJECT – Common Strategy for Sustainable Territorial Development of

the cross-border area Romania-Bulgaria (MIS-ETC code 171)

PROJECT PARTNER 9 – ASDE-ECOREGIONS

Work package WP3 Development of common resources for territorial planning analysis and

strategy

WP 3.2 Acquisition of necessary hardware equipments and software for territorial

databases

WP 3.3 Elaboration of a harmonized common territorial and land cover database for

the Ro-Bg CBA

Software Architecture Document

(Draft version 1.8)


2

Revision History

Date Version Description Author

10.10.2012 1.0 Initial version Roumen Venkov (RV)

15.10.2012 1.1 Updated 1.0 RV, Radko Radkov (RR), Vassil Vassilev (VV)

17.10.2012 1.2 Updated 1.1 RV, Ivan Filipov (IF)

20.10.2012 1.3 Updated 1.2 RV, IF

02.11.2012 1.4 Updated 1.3 RV, RR, VV

07.11.2012 1.41 Updated 1.4 RV, RR, VV, Kristian Milenov (KM),

Venko Bojinov (VB), Pavel Milenov (PM)

08.11.2012 1.5 Updated 1.41 ASDE Team




02.10.2013 1.8 Updated 1.7 RV, IF


3

Contents

Preface-General ................................................................................................................................................ 4

1. Introduction ................................................................................................................................................... 5

1.1. Purpose ................................................................................................................................................... 5 1.2. Scope ...................................................................................................................................................... 5 1.3. Definitions, acronyms, and abbreviations ............................................................................................... 5 1.4. References .............................................................................................................................................. 5

2. Overall architecture ...................................................................................................................................... 6

2.1. Spatial database definitions .................................................................................................................... 6 2.1.1. General definition ............................................................................................................................. 6 2.1.2. OGC spatial database ..................................................................................................................... 6 2.1.3. ESRI geodatabase ........................................................................................................................... 6

2.2. Detailed architecture ............................................................................................................................... 6 2.2.1. Overall schema ................................................................................................................................ 6 2.2.2. Architecture features ........................................................................................................................ 8

2.3. Users and roles ....................................................................................................................................... 8 2.4. Open questions ....................................................................................................................................... 8

3. Production site ............................................................................................................................................. 9

3.1. Tasks ....................................................................................................................................................... 9 3.2. Architecture ............................................................................................................................................. 9

3.2.1. GDB ................................................................................................................................................. 9 3.2.2. Export/share features .................................................................................................................... 10

3.3. Interoperability ....................................................................................................................................... 10 3.3.1. Export and import geodatabase schemas. Geodatabase XML ..................................................... 10 3.3.2. Metadata capabilities ..................................................................................................................... 10

3.4. Land Cover workflow ............................................................................................................................. 11 3.5. Open questions ..................................................................................................................................... 12

4. Publication site ........................................................................................................................................... 13

4.1. Tasks ..................................................................................................................................................... 13 4.2. Architecture ........................................................................................................................................... 13

4.2.1. Description ..................................................................................................................................... 13 4.2.2. OpenGeo suite ............................................................................................................................... 14 4.2.3. PostGIS .......................................................................................................................................... 14 4.2.4. Geoserver ...................................................................................................................................... 15 4.2.5. Geoserver tiers architecture .......................................................................................................... 15

4.3. Main use cases ..................................................................................................................................... 15 4.4. Integration and interoperability .............................................................................................................. 16

4.4.1. Interoperability ............................................................................................................................... 16 4.5. Possible future extensions .................................................................................................................... 17 4.6. Open questions ..................................................................................................................................... 20

4.7 Regular monitoring, data harmonization, risk prevention, strategy planning scenarios simulation .......................................................................................................................................................................... 13


4

Preface-General

Objective The objective is to have a harmonized land cover database, which is a very important integrated tool in our analysis and Strategy, and in the same time a very important result of this project. Activities PPs will participate within this sub working package according to their expertise.

- Development of an unified cross-border reference land cover database based on the LCCS (Land Cover Classification System) using a set of independent diagnostic criteria that allows correlation and standardization of the land cover class types, with respect of the existing classifications and legends, in compliance with the rules and requirements of essential EU Directives and documents for spatial database harmonization, environmental and risk protection, crisis and disaster assessment and management;

- Integration and harmonization of the reference land cover database based on the LCCS with existing thematic layers developed under National (BG and RO) and EU financed projects and programmes for environment protection (e.g. Natura 2000), for the aims of better crisis and disaster management and risk prevention, effective territory management; Quality assessment of the prepared unified reference land cover database;

- Development of technical specifications for harmonizing data and services up to level 3 of interoperability (syntactic); Provision of harmonized spatial data and services for the thematic layers within the project, and vice versa, integration of thematic databases into the harmonized database, through the development and maintenance of WEB GIS portal;

- Setup and development of systems and information services allowing the integration of the new, harmonized spatial databases and services with the existing information systems at county/district level;

- The database will ensure the necessary data for a comprehensive set of indicators at NUTS 3, 2 and LAU (local administration unit) level.

Results

- a common land cover database which could be the basis of the future studies, analyses and management;

- Knowledge and good practice exchange on regional and national level; staff exchange. Outputs

- Database harmonized and classified on the basis of LCCS; - Establish the technical specifications for harmonizing data and services up to level 3 of

interoperability (syntactic) developed and issued; - Integration between the thematic layers and the harmonized database established; - Correlation between the existing information services and the newly developed integrated product

carried out; - 1 workshop (Bg)/1 day [TD]

Indicators

- no of The technical equipment for the end users needs delivered; - Quality check of the integrated and harmonized land cover database on the basis of LCCS carried

out; - WEB GIS Portal developed/launched; - No Integrated information system developed.


5

1. Introduction

1.1. Purpose

This document provides a comprehensive architectural overview of the SmartCover (not official, proposed system name - it is intended to be developed in the future as a joint proposal of Bulgaria and Romania for the Danube region as DanubeSmartCover), using a number of different architectural views to depict different aspects of it. It is intended to capture and convey the significant architectural decisions that have been made on the system.

The document Software Architecture Document is intended for internal use only ! Remark: Highlighted texts mean:

Internal, used for internal discussion only

To do [TD].

1.2. Scope

This Software Architecture Document applies to the SmartCover System, which being developed by the AURE Team (see [1]).

1.3. Definitions, acronyms, and abbreviations

See ‘Glossary’ [1].

1.4. References

[1] Glossary [2] SmartCover system description

The above documents are under preparation.


6

2. Overall architecture

The SmartCover infrastructure consists of a Production Site (ProdSite) and a Publication Site (PublSite). ProdSite is intended for development needs. It hosts GIS (an ArgGIS implementation and open source solutions) and the production database (prodDB) as its part. ProdSite builds spatial objects as models, datasets, etc. Some of them are transferred to the Publication Site. PublSite hosts a spatial database, named publication database (publDB). This database is the main deliverable of the project and contains datasets related to the spatial planning with focus on LandCover and (partially) on LandUse. These datasets could be used by different SmartCover users to produce layers, maps, reports, etc. PublSite will be implemented as free open source (FOS) software. In correspondence with user needs there is a capability for development of additional section, related to the use of simulation and prognostic software tools.

2.1. Spatial database definitions

In order to avoid misunderstandings, it is necessary to refer to spatial database definitions of OGC and ESRI.

2.1.1. General definition Spatial database is a database that models space, objects in space, or a combination of both. Geodatabase is a specialized spatial database that deals specifically with geographical data, i.e. geodatabases are a type of spatial database.

2.1.2. OGC spatial database A spatial database is a database that is optimized to store and query data that is related to objects in space, including points, lines and polygons. While typical databases can understand various numeric and character types of data, additional functionality needs to be added for databases to process spatial data types. These are typically called geometry or feature. The Open Geospatial Consortium created the Simple Features specification and sets standards for adding spatial functionality to database systems.

2.1.3. ESRI geodatabase The geodatabase is a collection of thematic layers which you can present and overlay on a map. The geodatabase stores and organizes your geographic data as points, lines, polygons and attributes with which you model these real world entities.

2.2. Detailed architecture

2.2.1. Overall schema The SmartCover architecture (current draft variant) is shown on Fig.1. This architecture will be implemented in phases. The first phase (CBC project) does not include the realization of modules for Changes Management, Risk Assessment and Metadata Management.


7

Fig. 1

Publication Site

Metadata

Production Site

Desktop GIS

Procedures

LCCS 2/3

Production db

Input data : Original images Datasets Shapes , GML

XML , ...

Models UML , XML

ERDAS OpenGeoSuite ( Server Part )

Procedures

MD Editor

Publication db

Models UML , XML

ETL

Regular user Key user Developer

Shapes XML , ...

WS

IS

Server

WS

IS

Server

portal

Integrated map

Risk Assessment

SmartRisk

Future extension Legend

XML / HTTP IMG / HTTP

User Interface

Application Server

Database

portal

Ancillary data


8

2.2.2. Architecture features 1) Best in class solution, using EC recommendations for information technologies in this field. 2) Implementation based on free open source. 3) Low operational cost. 4) Based on OGC standards, high level of harmonization and standardization. 5) Interoperability and future integration. System architecture facilitates elaboration of interfaces with other

systems based on SOA/OGC. 6) Using PostGIS - high performance, object-relational DBMS. PostGIS adds types, functions and indexes

to support the storage, management, and analysis of geospatial objects. 7) Prerequisite for covering of all project requirements (Interoperability, INSPIRE, etc.). 8) Could be used effectively for the needs of spatial planning. 9) Reusable, easy to maintain and extend. System architecture allows the future development of specific

extensions (i.e. support the indicators at NUTS 3, NUT 2 and LAU levels, etc). 10) Proven feasibility. 11) Part of WEB GIS portal which provides the integration interface to other systems. Remark:

A pilot version of the Production Site was installed (at ASDE site). In order to prove the feasibility of the proposed architecture were performed several tests as well as a load of shape files (for land cover) in Geoserver using PostGIS for its workspace. We produced a research regarding GeoServer SDK (incl. GeoServer INSPIRE extension).

2.3. Users and roles

The users could be:

- Admin – system administrator - Developers – develop and maintain prodDB and publDB, incl. data transfer - Key users – add/delete proper data, create proper layers/maps/reports and analysis (future

extension) - Regular users) – only search/view/download.

2.4. Open questions

No Question Answer

1) On which server will be hosted PublSite For project needs: ASDE Exploitation phase: BG and ROM ministries of development

(*)

2) What spatial objects to be transferred from prodDB to publDB/Geoserver

Datasets

3) In what format will be transferred Shape

4) Filtering of existing shape files (only for CBC spatial planning needs) and their later loading into publDB

Yes

5) After datasets transfer from prodDB to publDB all layers, maps, reports, etc. are created in PublSite environment

Yes

6) All datasets are created (or preprocessed/prepared) in ProdSite Yes

* Setting up a common data center at the level of the 2 line ministries


9

3. Production site

For the project needs, the environment of AURE will be used as ProdSite.

3.1. Tasks

1) Collecting data from different sources of information, organizing them in datasets. Some of them later will be transferred to PublSite. Provision of harmonized data for the thematic layers within the project.

2) Design/Implement/(Load) spatial database (SDB). SDB contains objects (tables/classes) at least for: - LandCover - LandUse - Part of selected (simple) datasets related to the spatial planning.

3) Ensures publDB actualization. 4) LandCover/LandUse

- Using LCML (LCCS3) for description of LandCover classes - Could be used LCCS2 also.

5) Creates LandCover/LandUse datasets related to the spatial planning as well as to other points of interest.

6) Provides interface to PublSite: - Import from GeoServer (shapes) - Direct import/export from/to PostGIS (shapes, XML).

7) Creates and manages metadata.

3.2. Architecture

1) Uses desktop GIS: open source (QGIS) or commercial software (ArcGIS) 2) Partially uses FOS 3) Software: ERDAS, LCCS3 (and LCCS2 optionaly) 4) Database – specified by used desktop GIS.

ProdSite is the single source of information for initial loading of publDB. It collects and validates data from different sources:

- Original satellite images and ancillary data - Available shape files - LCCS2/LCCS3 classes, etc.

3.2.1. GDB At its most basic level, an ArcGIS geodatabase is a collection of geographic datasets of various types held in a common file system folder, a Microsoft Access database, or a multiuser relational DBMS (such as Oracle, Microsoft SQL Server, PostgreSQL, Informix, or IBM DB2). All GIS (ProdSite) users will work with three fundamental dataset types regardless of the system they use. They'll have a set of feature classes (much like a folder full of ESRI shapefiles); they'll have a number of attribute tables (dBASE files, Microsoft Access tables, Excel spreadsheets, DBMSs, and so forth); and most of the time, they'll also have a large set of imagery and raster dataset.


10

3.2.2. Export/share features The used desktop GIS provides export of feature classes to shapefiles, PostGis, etc. .

3.3. Interoperability

3.3.1. Export and import geodatabase schemas. Geodatabase XML The used desktop GIS publishes and maintains the complete geodatabase schema and content as an XML specification and provides sample implementations to illustrate how users can share data updates between homogeneous systems. XML interchange of geospatial information to and from the geodatabase is greatly simplified using the geodatabase XML specification.

3.3.2. Metadata capabilities The used desktop GIS allow users to create, manage, and edit metadata stored in an XML representation of Federal Geographic Data Committee (FGDC) Content for Digital Geospatial Metadata or the ISO 19115 Metadata Standard. (refer to INSPIRE also).


11

3.4. Land Cover workflow

Fig. 2

The original images are preprocessed. The preprocessing includes different types of corrections like geometric, atmospheric and radiometric corrections. This means assigning a coordinate system to the image, stretching and shrinking the image by using DEM to make the image to act as a topographic map, removing the haze, clouds etc. All these corrections are mandatory for easy and correct interpretation of the image. A lot of types of ancillary data are used for better recognitions of the real object on the ground and correct image interpretation and right classification.

Original Images

Preprocessing ( Geometric correction and Atmospheric corrections , Radiometric corrections ,

Image enhancement , Spatial filtering , etc .

Data Integration

Ground

Topograhic maps

Archive VHR images

Aerophoto images

Cadastre plans ( urban , argicultural )

Forest plans

LPIS

Ancillary data

Visual Interpretation

Conceptual modeling

using LCCS v . 3 Image Interpretation

Automatic feature

extraction

On - screen vectorisation and classification

Object - oriented classification

Data Validation ( DQA )

Land Cover ( (LC)

Thematic Layers

Field checking

Production Database

To Publication Site

Digital urban atlas

Water bodies

Soil

Others thematic data


12

The main approach for image interpretation is semiautomatic object oriented classification, but in some cases (i.e. roads, rivers) visual Interpretation is needed. The product of image interpretation and classification is LandCover vector layer with containing polygon objects without any gaps or overlaps. The product must be validated by data from conducted field checks. After creating the Style layer descriptor (the rule how to visualize the data) the data is ready to be loaded in Publication database.

3.5. Open questions

No Question Answer

1) Definition of (minimum) datasets needed for spatial planning (simple structures)

Yes, TD

2) Harmonization (BG, ROM) of nomenclatures, LandCover classes, etc.

Yes, TD

3) Export to publDB - Only datasets in following formats: shape files, XML, GML. - no export of layers and maps - Interfaces: PostGIS and GeoServer

shape files yes yes

4) Metadata management (through overall workflow).

Yes


13

4. Publication site

The Publication site (PublSite) hosts the spatial database (Publication database, publDB) which is the main output of the project.

4.1. Tasks

1) Contains the kernel of enhanced GIS, ensuring its future extension and integration. 2) Provides several services through user interface 3) Holds database (as well as the GeoServer workspace). 4) Design/Implement/Load spatial database (SDB). SDB contains objects (tables/classes) at least for:

- LandCover - LandUse - Part of selected datasets related to the spatial planning.

5) Realization of import schema. 6) Creates thematic layers/maps/reports 7) Maintains Metadata. 8) Supports open interface to other systems based on SOA. 9) Supports different formats: shapes, XML, GML, KML,… 10) Using of Publish – Find – Bind pattern.

4.2. Architecture

4.2.1. Description

The SmartCover provides user-friendly tools for navigating, querying, searching and selecting areas of interest. The site hosts OGC services which are accessible from any compatible client application and a web viewfinder of maps which provides the basic viewing functions. The web is structured in the following sections:

Search: find information available using metadata

OGC services: CSW, WMS, WFS, WCS

Downloads: data file download, via HTTP, to use with local applications.

Map Viewer: a lightweight, web based, map viewer that provides the basic viewing functions for the data.

Where the main components are deployed integrating the following open source technologies:

Geo-database: PostgreSQL with PostGIS spatial extension

Map server and map services (view, download, SRS transform): Geoserver

Catalogue management and services: GeoNetwork (optional)

Thin client (web front-end): based on Geoexplorer, GEOExt, Openlayers

Thick client (desktop front-end, GIS authoring, thematisation): uDig, QGis.

SmartCover realization is based on has been build using free opensource tools. Basically, GeoNetwork in order to provide searching services in metadata (CSW), GeoServer in order to provide map/features/visualization/download services (WMS and WFS) and PostgreSQL/PostGIS for vector data and metadata along with filesystem for shapefile data and/or raster.

Thematic maps are created using Styled Layer Descriptor (SLD), an XML standard defined by the Open Geospatial Consortium (OGC) to define the appearance of map layers.


14

4.2.2. OpenGeo suite The OpenGeo Suite (Community Edition) brings together the Open-Geo Architecture into a single, easy-to-install integrated software package. Open-Geo ensures the fastest way to get geospatial information on the web, leveraging the power of best-of-breed open source geospatial software. The OpenGeo Suite is the complete, OGC standards-compliant web mapping platform built on powerful, cutting-edge, open source geospatial components.

Storage: PostGIS / PostgreSQL spatial database Application server: GeoServer map/feature server User interface framework: GeoExt / ExtJS User interface map component: OpenLayers

4.2.3. PostGIS PostGIS “spatially enables” the PostgreSQL open source relational database. The database can then be used to store and query spatial data (points, lines and polygons). PostGIS ensures:

1) High performance, robust spatial database built on PostgreSQL 2) 100% SQL92 standards support. 3) It is certified as compliant with the OGC "Simple Features for SQL" specification 4) Proven reliability and transactional integrity (ACID compliance) 5) Triggers, views, foreign key constraints, user-defined functions, and procedural programming

languages in the back-end. Build, maintain and guarantee complex data models 6) Role-based security and authentication infrastructure 7) Provides spatial representations of geometry types (points, lines, polygons) 8) Support for common and advanced spatial operations such as geometry creation and conversion,

reprojection, buffer, convex hull, generalization, union, and more PostGIS is widely supported as a spatial database back-end to client and server software, including:

- Open Source Server: GeoServer, Mapserver, Mapnik, DeeGree, SharpMap - Open Source Desktop: GRASS, QGIS, uDig, gvSIG - Proprietary Server: ArcServer, Ionic Enterprise, MapDotNet Server - Proprietary Desktop: ArcGIS, Manifold, Safe FME, CadCorp SIS, MapInfo Professional.

The spatial SQL functions available in PostGIS make analyses possible that were previously the domain of workstation GIS systems. They also provide the following:


15

• Join two layers based on spatial containment rules (e.g. "what is the census profile of our customers", "SELECT avg(census.income) FROM census JOIN customers ON (ST_Contains(census.geom, customers.geom )" )

• Summarize layers based on spatial aggregates (e.g. "generate the polygon of all census tracks with annual income more than $50K", "SELECT ST_Union(census.geom) FROM census WHERE census.income > 50000")

• Create new layers through spatial operations (e.g. "buffer all the roads by 100 meters and union the result into an output polygon", "SELECT ST_Union(ST_Buffer(roads.geom, 100)) FROM roads" ).

4.2.4. Geoserver GeoServer is an open source server to publish and to maintain geospatial data. Provides strong support for Open Geospatial Consortium (OGC) standards, including WMS, WFS, Filter and SLD. Translates from existing databases to a variety of formats:

- Inputs: PostGIS, Oracle Spatial, DB2, ArcSDE, MySQL, Shapefile, WFS - Outputs: GML, Shapefile, KML/KMZ, JPEG, PNG, GIF, SVG, PDF.

4.2.5. Geoserver tiers architecture

4.3. Main use cases – potential development on a next stage

[TD] The functions of each user to be described/Да се опишат функциите на всеки отделен тип потребител.


16

4.4. Integration and interoperability

To solve the interoperability problems, the OGC has introduced some standards by publishing specifications for the GIS services. INSPIRE The OGC standards baseline comprises more than 30 standards, including:

WMS - Web Map Service: provides map images

WFS - Web Feature Service: for retrieving or altering feature descriptions

Styled Layer Descriptor (SLD). Follows a diagram showing how a WMS turns data into a map image.

Follows a diagram showing how a WFS turns a request into a response

4.4.1. Interoperability

4.4.1.1. Intro

To solve the interoperability problems, the OGC has introduced some standards by publishing specifications for the GIS services. The OGC is a global, not-for-profit organization comprised of more than 400 companies, government agencies, research organizations and universities. They all participate in a consensus process to develop publicly available geospatial standards that help end users to achieve interoperability and subsequently derive business value.


17

Interoperability and Standards with GIS The several aspects of the interoperability and related standards are shown below

Visualization Open GIS Web Map Service (WMS)

Data access and attributes Web Feature Service (WFS)

Data exchange Geographic Markup Language (GML)

Data presentation and styles Styled Layer Descriptor (SLD)

Metadata ISO metadata standard 19115

4.4.1.2. Working with GML

The Open Geospatial Consortium, Inc.'s (OGC) Geography Markup Language (GML) Encoding Specification is a standard protocol for expressing geographic features, their geometries, and attributes using XML. GML has two key parts: an application schema that describes the GML document and the document that contains the actual data encoded using XML. The Desktop GIS has to provide the support of GML description for datasets.

4.4.1.3. Map export

Map export formats - to several industry-standard file formats. EMF, EPS, AI, PDF, and SVG are referred to as vector export formats, since they can contain a mixture of vector and raster data. BMP, JPEG, PNG, TIFF, and GIF are referred to as image export formats. These are raster graphics file formats.

4.5. Possible future extensions

1) Clearing house module (for metadata descriptions synchronization). 2) Interface to other systems, integration using web services – realization of integrated maps. 3) SmartRisk – elaboration of integrated risk map (as thematic map). 4) Urban Growth Simulation (UGS). 5) Risk Manager – risk assessment, prevention and risk reduction maps. 6) Risk Navigator – data mining. 7) The proposal for a regional mechanism for regular monitoring, data coordination and harmonization,

etc. – The Regional Center for integrated risk and territory management for Lower Danube – positioned in the Euroregion Ruse-Giurgiu;

Natural Risk Zones According to the document D2.3 [INSPIRE] "Definition of Annex Themes and Scope", Natural Risk Zones (NRZ) are defined as vulnerable areas characterized according to natural hazards. In particular, they are zones where natural hazards areas intersect with highly populated areas and/or areas of particular environmental/ cultural/ economic value. A future extension of SmartCover - generic model for NRZ (related to LandCover and spatial planning themes) is intended.


18

Examples of risk, project realization and funds spending monitoring and changes detection maps NCAR

Integrated risk map and risk matrix - ESPON

EU Structural Funds – Operational Program, Regional Development – Integrated City Plans For Rehabilitation and Development /example – the Euroregion Ruse-Giurgiu/


19

TEN-T Priority Project 18 – RHINE-MOESEL-MAIN-DANUBE

GLOBCOVER – Global Spatial Data – Land Cover GLOBAL - BULCOVER – INSPIRE Reference Land Cover SDI – link to GLOBCOVER

Cross-border Cooperation in GMES operational service – Bulgaria and Romania


20

4.6. Open questions

No Question Answer

1) Design and implement PublSite container

Yes, TD

3) Definition of the services provided by SmartCover

TD

4) Using of OGC services for implementation of the above services

Yes

6) Precise the import procedure (SmartPipe, etc.)

shape files format

7) Thematic layers/maps are created in PublSite/ProdSite

Yes/Yes

8) Searching

Alt Layer level

9) History/Versioning

No/No

4.7. Regular monitoring, data harmonization, risk prevention, strategy planning scenarios simulation – The Regional Center for Integrated Risk and Territory management for the region of Lower Danube The proposal for a regional mechanism for regular monitoring, data coordination and harmonization, etc. – The Regional Center for integrated risk and territory management for Lower Danube – positioned in the Euroregion Ruse-Giurgiu;


21


22

Developed for PP9: October, 2013

Rоumen Venkov RR/VV/IF/KM/VB/PM

Software Architecture Document€¦ · Common Strategy for sustainable territorial development of...

Documents

Transcript of Software Architecture Document€¦ · Common Strategy for sustainable territorial development of...