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

2.2 Current scope

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

• GIS-Based Incident Management System ()

• Land Records/Cadastre Management ()

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.

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.

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).

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.

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)

10.1 Use Case Examples

• GIS-Based Incident Management System.

• .

10.2 Future Considerations

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)

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.

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

• 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. (REQUIRED)

• 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. (RECOMMENDED)

• 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. (OPTIONAL)

6.2 GIS Query

• 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 (REQUIRED):

6.3 GIS Data Management

• 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)

6.4 Geocoding and Reverse Geocoding

• 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)

6.5 Spatial Awareness and Analysis

• 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 (REQUIRED):

6.6 Reporting

• 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 (REQUIRED):

  • Symbology

  • Charts

6.7 Geofencing

• 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)

6.8 Routing

• 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 (REQUIRED):

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 , 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 OGC web API principles and guidelines 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