Developed by: Dr. Tarek Rashed (ITU Consultant), Dr. P. S. Ramkumar (ITU) and Dongpo Deng (Open Culture Foundation) Nabhonil Roy Chowdhury (eGov Foundation), Dan Henderson (Amazon AWS), Tanvir Quader (Aspire to Innovate), and Md. Sheikh Saidy (Aspire to Innovate)

The Cross-cutting requirements described in this section are an extension (adds on) to the cross-cutting requirements defined in the architecture specification document.

5.1 Personal Data Privacy (REQUIRED)

• Safeguard personal data and share only as authorized.

• Adhere to GovStack architecture's privacy principles.

5.2 All transactions must be Audit Logged (RECOMMENDED)

• Log transactions with timestamps, user information, and affiliations.

• Protect logs from tampering.

• Comply with Govstack's data policy and audit logging rules.

5.3 Interoperability (REQUIRED)

• Align with OGC and ISO/TC 211 geospatial standards for data sharing.

• Seamlessly integrate with other GovStack components.

5.4 Exception Handling (REQUIRED):

• Implement effective mechanisms and procedures to handle exceptions and errors.

• Ensure that errors don't lead to system crashes or data loss.

5.5 Incorporation of Relevant Open GIS Standards and APIs (REQUIRED)

• OGC APIs

• OGC Schemas

• OGC Service Standards

• GDAL Documentation

• ISO/TC 211 - Geographic information/Geomatics

10.1 Use Case Examples

• GIS-Based Incident Management System.

• Land Records/Cadastre Management.

10.2 Future Considerations

A list of topics that may be relevant to future versions of this Building Block.

The diagram below illustrates the proposed resource model that demonstrates the connections between data objects that the GIS Building Block uses. The resource models are represented by a UML class diagram. The GIS building block specification likely has many relationships between different resource types, such as layers, symbologies, and bookmarks. The class diagram concisely represents the structure and relationship between objects in the resource model.

7.1 Resource Model

7.2 Data Elements

7.2.1 Group: Map Display

MapDisplay

Navigation

SpatialBookmark

MapNote

Measuring

LayerToC

Layer

NonSpatialTable

ScaleLimit

Style

DataViewer

LayerMetadata

NonSpatialTableMetadata

GISQuery

LocationalQuery

AttributeQuery

DiscoveryQuery

QueryResult

7.2.3 Group: GIS Data Management

DataStore

DataStoreMetadata

UserControl

EditorTracking

Replica

7.2.4 Geocoding and Reverse Geocoding

AddressData

AddressAlias

AddressFormat

GeocodingBatch

7.2.5 Spatial Awareness and Analysis

Geoprocessing

ExecustionStatus

7.2.6 Reporting

MapReport

ReportQueue

ReportResource

Symbology

Label

Chart

Legend

ScaleBar

NorthArrow

7.2.7 Gefencing

Geofence

GefenceElement

ActionRule

Geofence Notification

7.2.8 Routing

Route

RouteNode

RouteSegment

ServiceArea

The various actors and their activities described in Section 2 must be supported by the key digital functions, shown in the following diagram and detailed below.

4.1 Map Display:

The Map Display for the GIS BB specifications is a fully configured GIS data viewing service that supports the passing of configured information resources between applications, delivers georeferenced map images and vector features in various formats, supports different geographic feature types, projections, and scales, allows users to explore data through panning, zooming, and rotating the map view, and conforms to OGC standards such as WMS, WFS, WMTS, WCS, WPS, and Geopackage.

4.2 GIS Query

The GIS Query KDF enables the creation and execution of GIS data discovery and query operations. It allows retrieval of GIS layer metadata, definition of feature types, and retrieval of GIS features or values based on attributes, location, or boundaries. It supports standard SQL or spatial predicates, filtering and sorting of query results, viewing results in pages, and exporting results to various formats. It conforms to OGC and ISO standards.

4.3 GIS Data Management

The GIS Data Management KDF is a configurable service that allows users to access and perform various operations on a remote GIS database, including publishing metadata, querying data, replicating schemas, extracting and transferring data, manipulating tabular data, and synchronizing changes. It must conform to OGC standards such as CSW, WMS, WFS, WCS, and ISO 19107:2019 and ISO 19168-1:2020.

4.4. Geocoding and Reverse Geocoding

The Geocoding and Reverse Geocoding KDF for the GIS BB specifications convert addresses into coordinates and vice versa. It requires a large gazetteer of addresses and coordinates from various sources, can display coordinates on a map, and can find addresses for geographic features. It can also return results in different languages, filter searches, and conforms to the OGC Open Location Services Interface Standard.

4.5 Spatial Awareness and Analysis

The Spatial Awareness and Analysis KDF for GIS BB specification allows the design, authoring, and publishing of GIS analytical operations. It offers a range of processing operations and tools for geospatial awareness and analysis, including spatial analysis, data conversion, and map production. The KDF supports listing, describing, executing, and consuming GIS processes, as well as managing job status, cancellation, and result retrieval. It conforms to the OGC processing standards.

4.6 Reporting

The Reporting KDF for GIS BB specification outlines a framework for consistent reporting of GIS data. It includes the ability to select reporting templates, access GIS layers and attribute tables, specify a destination for reports, prioritize and schedule report delivery, manage the report queue, and adhere to OGC standards.

4.7 Geofencing

The Geofencing Key Delivery Framework (KDF) for GIS BB specification enables the creation and management of virtual geofences or redlines on a GIS map display. It allows users to draw, modify, and delete geofence boundaries, authorize and manage rules for geofences, track objects within geofences, and receive real-time alerts when objects enter or exit geofences. The framework also conforms to OGC API - Common and OGC API - Features standards.

4.8 Routing

The Routing KDF for GIS BB specification enables the creation and management of network routes independently of a specific routing engine. It computes new routes based on the shortest distance between starting and ending points and allows for the specification of additional routing rules and parameters. It also includes features such as service area parameters, route direction reports, and compliance with OGC standards.

Section 4 of the GIS BB specification covers the key digital functionalities required for managing, processing, and using geospatial information and their integration with other types of information and building blocks. The GIS BB offers these functionalities through RESTful API interfaces that exchange service requests and responses with external building blocks or applications. This section on functional requirements lists the technical components that each key digital function requires. The figure below summarizes these components for each key digital function.

6.1 Map Display

• [REQUIRED] The map display must provide access to GIS data through a data viewer (a web-based, desktop, or mobile application that allows viewing and querying of GIS data). The viewer should display a graphic representation (points, polygons, lines, or raster grids) of geographic or spatial information through thematic GIS layers or attribute tables. The symbology (pre-defined styles) for each map layer (how the geographic features of this layer are portrayed on the data viewer) must be displayed as a legend alongside a table of contents listing all layers provided by the service.

• [REQUIRED] The map display must allow the data viewer to manipulate the displayed data layers. This includes hiding or displaying geographic features on the map display, changing their order, changing symbology, or classifying displayed geographic features. It must also provide access to attributes and metadata associated with the layer.

• [REQUIRED] The map display must enable the GIS data viewer to offer the basic navigation capabilities of a typical GIS data viewer. This includes zooming in and out of a map, panning, searching for geographic features by attribute or by coordinates, and measuring distances and areas on the displayed map.

• [RECOMMENDED] The map display should enable users to capture the spatial extent of a given location as a spatial bookmark in a GIS data viewer. Users should be able to name the bookmark and zoom to the exact extent whenever needed by selecting the bookmark's name. Users can also add, rename, and remove spatial bookmarks as necessary.

• [RECOMMENDED] The map display should allow users to set minimum and maximum scale limits for each layer, specifying whether or not a layer is identifiable and/or selectable on the data viewer. These settings are saved as a cache by the data viewer app and are reserved for future data viewer displays. The settings are reset to default when the cache is cleared.

• [OPTIONAL] The map display may allow the GIS user to add and share brief notes on the GID data viewer. Other users can view and comment on these notes. Notes can only be deleted by the creator of the note. Notes are saved and served as a web feature service.

6.2 GIS Query

• [REQUIRED] The GIS query must allow for transactions on and access to geographic features independently of the underlying data store.

• [REQUIRED] If feature metadata is not found in the metadata repository, the GIS Query must return a warning message.

• [REQUIRED] The GIS query must retrieve metadata that describes the layers and non-spatial tables offered by the GIS schema and their feature types from a data store. The query results must display the title, abstract, author, keywords, data format, and a snippet of the queried layers, along with their spatial extent and temporal information. The service must provide the following options for the retrieved metadata:

  • Display the retrieved metadata record for all datasets and features meeting the selected criteria.

  • Generate and print metadata record reports for the datasets.

  • Visualize layers on a map view.

  • Download or import the layer to the data store (if the service permits).

• [REQUIRED] The GIS query must allow searching for features and their attributes. It must also provide different options for retrieving features or values of feature properties embedded in GIS layers from the data store (e.g., selected features meeting the query criteria will be highlighted on the data viewer of the map display and the attributes table (as records corresponding to the selected features)). The query options should be based on constraints defined by the client, including:

  • Interactive selection of one or more features from the map display, either by directly clicking on them or using a graphical element (such as a box, circle, rectangle, transect, etc.).

  • Ad hoc SQL queries based on attribute tables.

  • Ad hoc queries based on locational information, such as geographic features located within a layer's boundaries, overlapping with a layer's boundaries, or near geographic features in a different layer.

  • Execution of a predefined query.

6.3 GIS Data Management

• [REQUIRED] The GIS data management system must allow the publishing of the schema, metadata, and contents of a GIS datastore for data query, extraction, and retrieval by clients. To conform to standards, the vector contents of the GIS layers must be available as OGC Web Feature Service (WFS), while the raster contents must be available as OGC Web Coverage Service (WCS).

• [REQUIRED] The GIS data management system must enable clients to retrieve geographic features and GIS layers (a collection of features) from the underlying data store based on simple selection criteria defined by the client.

• [REQUIRED] The GIS data management system must present geometry-valued properties of geographic features in one of the supported Coordinate Reference Systems (CRS).

• [REQUIRED] The GIS data management system must access and process the coordinates and geometry properties of geographic features and the bounding boxes of these features.

• [REQUIRED] The GIS data management system must support editing operations of individual geographic features in GIS layers. Operations include:

  • adding or creating a new geographic feature in a GIS layer,

  • updating geographic features by either replacing them or modifying some of their properties,

  • deleting individual geographic features from a GIS layer.

• [REQUIRED] The GIS data management system must support various replica operations for GIS features, layers, and databases, including creation, synchronization, and data extraction. It is up to the implementers of the service to decide how the GIS data management system will handle the creation of large replicas, the synchronization of large numbers of edits, or the extraction of large amounts of data.

• [RECOMMENDED] The GIS data management system should provide the following access control levels for the editing capabilities provided by the services to control how the client can consume the services:

  • Editor permissions (at both the GIS layer and geographic feature levels) control whether users can add, delete, or modify features in the service. For example, prevent or allow users to edit feature geometry.

  • Editor tracking that records who created or updated the features and when they did it. This is useful when accountability for the edits is required. An optional history tracking feature maintains information about feature changes over time, allowing edits to be rolled back.

  • Ownership-based access control that limits access to geographic features based on who created them.

6.4 Geocoding and Reverse Geocoding

• [REQUIRED] The Geocoding and Reverse Geocoding service must provide a solid set of reference GIS layers (street parcels, street centerlines, postal codes, points of interest, landmarks, etc.), additional sets of potential aliases for these addresses, and a designated attribute table with designated fields that are used for geocoding, as well as indexes and local addressing knowledge that helps return the best match with an appropriate resolution.

• [REQUIRED] The Geocoding and Reverse Geocoding service must provide the best match using explicit rules to promptly geocode locations (i.e., convert an address into geographic coordinates) or reverse geocode (convert geographic coordinates into an address) in an area of interest. Rules efficiency and performance depend on the underlying GIS data (e.g., land parcel vs. street centerline) and local knowledge.

• [REQUIRED] The Geocoding and Reverse Geocoding service must be performed either from a single query (the address bar) or a batch query (e.g., a table file with multiple addresses or geographic coordinates).

• [RECOMMENDED] The Geocoding and Reverse Geocoding service should offer multi-role and/or multiple reference data layers with different geometry types that can be combined and processed with the appropriate rules to interpret the geocoded location from many sources.

• [RECOMMENDED] The Geocoding and Reverse Geocoding service should support multiple address formats if required by the implementation context.

• [RECOMMENDED] The Geocoding and Reverse Geocoding service should support multiple languages if required by the implementation context.

6.5 Spatial Awareness and Analysis

• [REQUIRED] The Spatial Awareness and Analysis service must allow retrieval of metadata that describes the purpose and functionality of geospatial analysis tasks or processes.

• [REQUIRED] The Spatial Awareness and Analysis service must allow retrieval of detailed information that describes the processes that can be run on the service.

• [REQUIRED] The Spatial Awareness and Analysis service must allow for the execution of one or more geoprocessing tasks to perform basic spatial analysis operations, using the input parameter values provided and returning the output values produced. The minimum set of tasks required by this service includes:

  • Finding the nearest neighbor of a point.

  • Calculating the area of a polygon.

  • Buffering a geographic feature (point, line, or polygon).

  • Ingesting or merging two or more datasets (GIS layers) into a single dataset.

  • Creating a new GIS dataset (GIS layer) from an existing dataset.

  • Exporting a GIS dataset to a different format, such as a shapefile, GeoJSON file, or KML file.

• [REQUIRED] The Spatial Awareness and Analysis service must support both asynchronous and synchronous modes of executing the tasks. The publisher of the service sets either one or both of the modes. The asynchronous task must have logic implemented to check the status of a task and handle the result once execution is finished as the following:

  • returns the status of an asynchronously executed job.

  • returns the result of a finished processing job that was invoked asynchronously.

  • allows a client to terminate asynchronous processing jobs.

• [REQUIRED] The Spatial Awareness and Analysis service must fully support all parameter data types used as input or output parameters for OGC WPS services.

6.6 Reporting

• [REQUIRED] The GIS Reporting service must provide endpoints for templates and resources that can be used to create map layouts and cartographic reports, including the following:

  • Symbology

  • Charts

  • Dot density maps

  • Graduated color maps

  • Graduated or proportional symbol maps

  • Legends

  • Scale bars

  • North arrows

• [REQUIRED] The GIS Reporting service must allow for adding or removing dynamic GIS layers to or from a map layout or report.

• [REQUIRED] The GIS Reporting service must allow for defining and managing labels and annotations on a map layout.

• [REQUIRED] The GIS Reporting service must allow for prioritization and scheduled delivery of reports.

• [REQUIRED] The GIS Reporting service must allow for managing the report queue and canceling or recalling reporting tasks.

6.7 Geofencing

• [REQUIRED] The geofencing service must allow for the creation of new geofences.

• [REQUIRED] The geofencing service must allow for updating or modifying the size and shape of geofence boundaries.

• [REQUIRED] The geofencing service must allow for deleting existing geofences.

• [REQUIRED] The geofencing service must allow for listing and visually displaying all the geofences provided by the service on a map.

• [REQUIRED] The geofencing service must allow for activating or deactivating geofences. Once a geofence is activated, the service will start monitoring elements of interest (vehicles, devices, assets, and people) and send notifications when the device enters or exits the geofence. Once it is deactivated, the service will no longer monitor a geofence or if you need to change your geofence configuration.

• [REQUIRED] The geofencing service must allow for retrieving the status of a specific geofence (i.e., activated or deactivated).

• [REQUIRED] The geofencing service must support the specification, modification, deletion, and overall management of rules and actions that may be taken once elements of interest enter or exit a geofence.

• [REQUIRED] The geofencing service must support GPS or RFID tags or a combination of both to monitor the elements of interest.

• [RECOMMENDED] The geofencing service should support multiple notification types, such as push notifications, SMS notifications, and email notifications.

6.8 Routing

• [REQUIRED] The Routing service must allow for creating routes based on start and end nodes.

• [REQUIRED] The Routing service must allow for fetching and deleting routes stored on the server.

• [REQUIRED] The Routing service must offer one or more of the following commonly used routing parameters:

  • specifying the type of transport when computing the route

  • specifying intermediate passthrough points along the route

  • specifying restrictions along the route (e.g., turn and direction restrictions, height restrictions for underpasses, bridge weight restrictions, etc.) or obstacles to avoid

  • specifying additional routing rules and parameters (e.g., type of route for cars, buses, or humans, route barriers such as traffic conditions or the presence of over- and under-passes, adding stopping points, traffic conditions, road-turn directions, etc.)

  • creating and managing service area parameters along the route

• [REQUIRED] The Routing service must generate direction and routing reports.

The following internal workflows describe the processes the GIS Building Block executes to fulfill a request from an external application or Building Block to meet the functional requirements stated in Section 6 of this specification. In the current scope, examples are drawn from the user-journey steps of the use-cases of the GIS-Based Incident Management System and Land Records/Cadaster Management provided in Section 2. The below common preconditions should be met before utilizing the GIS BB Services:

• Information Mediator BB Configuration: All the service endpoints of the GIS BB APIs should be configured in the Information Mediator BB.

• Conformance to Open Standards: Developers of the GIS BB APIs should adhere to the OGC web API guidelines and principles, and Cross-Origin Resource Sharing (CORS) to enable seamless integration and data exchange of GIS data between GIS BB APIs and GIS API services offered by other systems.

• Data Format Compatibility: The geospatial data source handled by the GIS BB APIs, whether vector data (points, lines, and polygons) or raster data (imagery, elevation data), should be in a format compatible with the specific API used (e.g., GeoJSON, GML, KML, etc.) per Section 7 of this specification. External adapters may be used to transform non-compliant data formats and exchange protocols to become compatible with Section 7 Apis.

• Coordinate System Awareness: Developers and users should understand the coordinate system and projections used in their geospatial data to prevent inaccuracies in analysis and visualization.

• No Authentication or API Keys: As a general rule, developers of the GIS BB APIs should avoid mandatory authentication mechanisms or API keys that can limit access; make the API accessible to anyone without a signup process unless there is a legitimate requirement to impose authentication mechanisms.

9.1 GIS Map Display

9.1.1 Interactions between an external application or a Building Block and the MapDisplay API with data store integration

9.1.2 Example 1: Cadastral User Displaying Land Use and Title Layers with Parcel Zoom

9.1.3 Example 2: Emergency Dispatcher: Accident Location Bookmarking and Map Note Addition

9.2 GIS Query

9.2.1 Interactions between an external application or a Building Block and the GISQuery API with data store integrationsequenceDiagram

9.2.2 Example 1: Cadastre User Discovery Query for Privately Owned Land

9.2.3 Example 2: Locational Query for Landmarks near Incident Location

9.3 GIS Data Management

9.3.1 Interactions between an external application or a Building Block and the GIS DataManagement API with data store integration

9.3.2 Example: Editing Land Parcel information

9.4 GeoCoding and Reverse GeoCoding

9.4.1 Geocoding and Reverse Geocoding API Integration with Data Store

9.4.2 Example: Reverse Geocoding of Incident Dispatcher's Landmark Coordinates

9.5 Spatial Awareness and Analysis

9.5.1 Interactions between an external application or a Building Block and the SpatialAwarenessAndAnalysis API with data store integration

9.5.2 Example 1: GIS Cadastral User Performing Green Space Analysis

9.5.3 Example 2: Emergency Dispatcher Creating Safe Zone Buffer Around an Incident Spot

9.6 GIS Reporting

9.6.1 Interactions between an external application or a Building Block and the GIS Reporting API with data store integration

9.7 Gefencing

9.7.1 Interactions between an external application or a Building Block and the Geofencing API

9.7.2 Example: Geofencing API Usage for Redlining Emergency Operation

9.8 Routing

9.8.1 Interactions between an external application or a Building Block and the Routing API

9.8.2 Example: Emergency Response Routing Scenario

This section provides a reference for the APIs implemented by the GIS Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.

The GIS BB APIs conform with the and should be deployed as a set of microservices to provide clients consistent access to the key digital functionalities and geographic data in different representations. Microservices are defined to receive requests with relevant inputs and return processed results from key digital functionalities of this Building Block. Microservices are small, independent, and loosely coupled services that perform specific functions within the larger GIS BB key digital functionalities. Each microservice is kept simple and intuitive by focusing on one particular task, and together they form a cohesive and scalable GIS architecture. Each microservice can be developed, deployed, and maintained independently, making it easier to manage and scale the system as needed.

This section provides a reference for APIs that this Building Block should implement. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. The Building Block may implement additional APIs, but the listed APIs define a minimal set of functionality that any implementation of this Building Block should provide.

The provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here.

8.1 Map Display

8.2 GIS Query

8.3 GIS Data Management

8.4 Geocoding and Reverse Geocoding

8.5 Spatial Awareness and Analysis

8.6 Reporting

8.7 Geofencing

8.8 Routing

Geospatial information represents Earth's features, including maps, images, addresses, zip codes, phone numbers, landmarks, events, and more. Location and time are fundamental properties of geographic information, providing a unifying theme to understand the context of most real and abstract phenomena.

The GIS (geographic information services) building block enables various applications with location-based capabilities. By integrating a wide range of spatial data, such as maps, imagery, and location-based services, users can access and process geospatial data from different sources and link geographic locations to various "objects" within an open information technology environment. For example, users can link geographic locations to people, such as patients, doctors, farmers, and agricultural extension practitioners. They can also link geographic locations to hospitals, ambulances, labs, seed production facilities, and more. Additionally, equipment such as ventilators and vaccine containers can be linked to geographic locations, as can sites like water sources and agricultural fields. This geographic association can also be tagged with a unique digital identifier and a timestamp of when it was acquired.

Applications or components using geographical information services can collect, share, and use temporal and spatial information with other applications, such as map repositories and data visualization tools. These tools can display the collected information on geographical maps, giving users a powerful visual representation of the data. Furthermore, the collected data can be combined with other datasets, such as population, surveillance, or supply chain datasets, to enable interoperable geospatial and spatiotemporal analysis. This can help identify patterns and trends in the data that might not otherwise be apparent.

2.1 Relation to Existing Geospatial Information Standards

The GovStack GIS BB specifications are not meant to replace or compete with existing standards in GIS but rather to extend them to address a new niche related to application use cases serving specific sectors. There are several initiatives and entities dedicated to creating standards for geographic data, the most popular of which are: (1) ISO Technical Committee 211 on Geographic Information/Geomatics (ISO/TC 211) which produces the ISO 19xxx standard series, and (2) the Open Geospatial Consortium (OGC). Although these two organizations are independent and sometimes produce overlapping standards, they generally coordinate closely to maximize mutual development and minimize duplication.

ISO standards are generally focused on the nature of geographic information and standards to encode and represent it in digital environments, while OGC standards are more focused on the implementation of services and APIs for serving and processing GIS over the internet or across systems. Links to the respective standards and resources that are incorporated in the GIS BB can be found in section 5.5 of the GIS BB specifications.

The GovStack GIS BB specifications were developed to fill a new niche in the GIS standardization landscape. Instead of dealing with each standard in isolation or representing them abstractly, these specifications focus on converging existing standards and aligning them in a useful and applicable way to real-world scenarios or use cases relevant to governments and municipalities.

Specifically, the GovStack GIS BB specifications aim to:

• Make it easier for governments to adopt and use open standards for GIS.

• Help governments build more interoperable and reusable GIS applications and integrate them with other building blocks.

• Enable governments to deliver more efficient and effective geo-enabled services to citizens and businesses.

By extending existing standards and focusing on application use cases, the GovStack GIS BB specifications can help governments realize the full potential of GIS to improve public services and decision-making. Below are a few examples of the many sectors that can benefit from GIS services and applications.

• Local government: cadastral mapping and management, land use and transportation planning, and optimization of service delivery such as postal services, trash collection, etc.

• Incident Management and Emergency Response: call services, dispatching, tracking emergency vehicles and resources, redlining, etc.

• Law enforcement: tracking crime patterns, investigating crimes, and public safety planning

• Natural resources: managing water resources, monitoring forests, and conservation planning

• Planning: planning for development, transportation, and other infrastructure projects

• Agriculture: tracking crop yields, providing weather information for farmers, planning for agricultural development, and precision farming

• Business: tracking assets and customer shopping habits, analyzing store locations, and supply chain management

• Construction: planning construction projects, tracking progress, and identifying potential hazards

• Energy: management of energy resources, planning for green energy development, and monitoring energy use

• Environment: measuring pollution, monitoring wildlife populations, and environmental protection

• Healthcare: managing disease outbreaks, planning for healthcare facilities, and improving access to patient care

• Risk management: modeling hazards, exposure, vulnerability analysis, and risk assessment and management

• Transportation: planning transportation routes, tracking traffic, and improving public transportation

• Utilities: utility infrastructure management, customer data management, and utility expansion planning

2.2 Current scope

The functional requirements to cover the services required from the GIS Building Block currently consider the specific use cases of:

These two use cases cover a wide range of GIS services, including core functionality such as GIS data access, display, and visualization, GIS data query, GIS layer management and manipulation, metadata and cataloging services, locational analysis, geocoding, and reporting. The endless combination of these GIS services can be used to respond to the needs of various applications across many domains and sectors, as listed above.

The following actors have been identified as "users" of the GIS Building Block:

• "GIS Data Viewer": displays and views spatial data to find information about a particular location, compare different datasets, or create spatial data visualizations.

• "GIS Data Editor": performs spatial data editing by adding, updating, or deleting geographic data features from a dataset or changing the properties and attributes of these features.

• "GIS Admin": manages GIS data by creating, maintaining, and organizing geographic datasets and ensuring that data is accurate and up-to-date.

• "GIS Application Developer": develops GIS applications by deploying one or more GIS BB services to serve business needs.

• "Discovery Tools": search for metadata about spatial data to find information about the content of a dataset, the creators of a dataset, or the methods used to create a dataset.

• "Other Building Blocks and Applications": display and consume GIS services to perform specific GIS operations such as creating maps, generating reports, and more.

The GIS BB services MUST enable these actors to perform the basic functions and tasks associated with their role as follows:

• Enable GIS Data Viewers to explore, and analyze spatial data, interact with various types of spatial data, manipulate layers, perform spatial analysis, generate reports and create spatial information products, create visualizations in different formats, and share them with others.

• Provide capabilities for GIS Data Editors to add, delete, update, and modify features in a dataset. It should also support merging or dividing datasets, checking accuracy and completeness, and exporting datasets for use in other software applications.

• Enable GIS Data Admin to migrate data between databases, create and manage layers, connect to remote databases, import/export data from external sources, search for data, transform projections, generate and manage metadata, enforce metadata standards, enforce data manipulation policies and integrity constraints, and track changes to data and metadata.

• Allow GIS Developers to expose capabilities for accessing GIS databases, provide access to database contents, access map contents, develop interoperable applications, create mobile apps for geospatial data, and integrate and communicate with other GIS applications and data sources.

• Enable Discovery Services to catalog, search, visualize, and provide access to geospatial data by providing information about the data, using keywords or tags, displaying it on a map, and allowing users to download, use, or generate reports.

• Allow other building blocks and applications to retrieve geospatial data for creating interactive maps and applications, perform geospatial analysis for spatially-informed decisions, and manage geospatial data in various formats.

2.3 Future Scope

The following aspects are on the future scope for the GIS Building Block specifications considered in this document:

• Processing of raster data (e.g., satellite and drone imagery, gridded data) such as performing image classification, image enhancement, segmentation, and other types of analysis.

• Performing complex geospatial analysis, such as spatial interpolation or complex spatial statistics (e.g., spatial autocorrelation and spatial regression)

• Handling and performing analysis of geometric networks (typically associated with rules-based networks such as water distribution lines, power utilities, electrical lines, gas pipelines, telephone services, and stream/river water flows).

• Sharing and accessing GIS 3D data models such as TINs, BLMs, and scenery.

• Analysis of 3D GIS data models such as performing LiDAR analysis, volumetric calculations, or 3D modeling.

• Supporting time-based dynamic tracking of objects, whether those that are GPS/sensor-based such as Automatic Vehicle Location (AVL) or spatiotemporal based on time-stamped such as traffic accidents or weather storms.

2.4 Out of Scope

The following aspects are out of the scope of the current version of the GIS Building Block specifications considered in this document:

• The GIS BB specifications do not address a country's specific data privacy policies, as well as any legal or ethical implications associated with the amount and level of information that can be gathered by GIS BB services. It is crucial to carefully consider any legal or ethical implications associated with using these tools and to take steps to ensure that any collected data is being used responsibly and appropriately.

• The GIS BB specifications do not define the security measures that should be used to protect GIS data. Security requirements for geographic data can vary depending on the sensitivity of the data and the environment in which it is used.

• The GIS BB specifications do not define the data formats that should be used to store or exchange geographic data. Many different data formats are available, each with its advantages and disadvantages.

• The GIS BB specifications do not define the quality of the geographic data that should be used. The quality of geographic data can vary depending on the source of the data and the methods used to collect it.

• The GIS BB specifications do not define how geographic data should be visualized. This is because geographic data visualization is a subjective process that depends on the user’s needs.

  .