Geospatial Data Infrastructure of the KSA Border Guard

Dr Ulrich Lenk Cassidian – an EADS Company, Germany

Dr Ahmed S Alzahrani Ministry of Interior, Kingdom of Saudi Arabia

The Kingdom of Saudi Arabia (KSA) Ministry of Interior (MOI) has initiated a major development program for its Border Guard (BG) to develop the BG’s organization into a 21st century security force capable of delivering comprehensive border protection [KSA MOI 2007]. Such a sustainable approach requires a comprehensive modernization and integration of command, control, communications, computers, intelligence, surveillance and reconnaissance (C4ISR), supporting telecommunications and information technologies, organizational development and training as well as air, land and sea assets and infrastructure to create an effective border security and protection system. The main purpose of the target border security system is to [KSA MOI 2007]:

• Deny illegal entry of people and contraband into the Kingdom;
• Provide front-line staff the best possible environment to effectively deter, detect, identify, classify, respond to and resolve border security situations;
• And to balance the need for efficient border crossing processes to encourage economic growth while also ensuring that threats are countered before they impact the country, therefore protecting the citizens and legitimate residents of the Kingdom.

This overall development program was contracted in two parts. The first tranche is a pilot that aims for the protection of the northern part of the border of the Kingdom towards Iraq and is therefore called NBS (Northern Border Security). It covers only land sectors. The second tranche deals with the full scope of the border while having a supplemental requirement to provide for an integration of the NBS solution into the overall target system solution. It covers not only land sectors like NBS but also the shores of the Red Sea and the Arabian Gulf, thus land and maritime sectors. As this second tranche deals with the integration of several system elements into an overall system while encompassing as well the integration of NBS and interfaces to other KSA agencies and existing infrastructures, it was therefore called the Systems Integration Engineer (SIE) project.

Similarly to the NBS system, as part of the SIE system surveillance sensors will be installed along the border, and incidents detected on the basis of sensor observations are nowadays displayed in a graphically enabled application to provide the system operators the full overview of the situation along the border, showing amongst others the detected incidents, own installations and forces together with geospatial and environmental data. Consequently such a system provides for what is typically termed a Common Operational Picture (COP).

One major part within a COP is geospatial and environmental data that is used on the one hand for visualization purpose and on the other hand to support the decision making process in the headquarters, for example by geospatial analysis of bounding conditions of a mission to be conducted. Besides this use geospatial data is also needed for processing and georeferencing the observations from the sensors. To enable that all levels of echelon have access to the same data based on the single source of information principle, a central management and provision of this data is required. Therefore the Geospatial & Environmental Reference System Element (G&ERSE) is a fundamental part of the system, which serves all other system elements on all levels of echelon with up-to-date geospatial and environmental data, irrespective of operational domains, environments and locations.

In the following the requirements for this G&ERSE are summarized for both data and technical aspects and an outline of its architecture including an overview of its interfaces is provided. This is followed by an introduction into two prototypes that have been developed to de-risk and prepare for the development of the target G&ERSE architecture.

Requirements for the border guard’s future geospatial data infrastructure

Requirements for the technical geospatial infrastructure

Whereas the geospatial data for NBS was provided by the KSA MOI as a customer furnished item to be integrated by the contractor into the system, this is different for the SIE approach. The delivery of geospatial data is within the scope of the contract for the SIE system, and dedicated comprehensive requirements for both the GIS software infrastructure and the geospatial data are part of the request for proposal [KSA MOI 2007]. The main requirements that have been stipulated for the future geospatial data software infrastructure may be summarized as follows:

• A central geospatial database in the system, and provision of data to other system elements on the same and subordinated levels of echelon;
• Ability to easily update geospatial and environmental data within the system on all levels of echelon assuring data integrity and consistency;
• Capability of accessing Esri compatible data and ability to consider existing Border Guard Esri installations;
• Integration of the NBS geospatial installation;
• Interoperability with other KSA agencies, neighbours and allies, where applicable;
• exploit national, allied and coalition standards.

Requirements for geospatial & environmental data

Geospatial data to be included in the system comprise:

• Maps: both raster and vector based on DIGEST standards;
• Satellite imagery with a ground sampling resolution of better than 1 m;
• Digital Terrain Elevation Data (DTED) Level 2;
• Air Charts and Maritime Charts.

Whereas it is straightforward to include georeferenced scanned raster maps into a GIS, for a comprehensive vector map it is clearly necessary to define the feature catalogue that shall be used for digitization. As there are as well requirements to be interoperable with neighbours and to adopt existing standards, the choice for the feature catalogue was to base the future Border Guard Feature Catalogue on the Defence Geospatial Information Working Group (DGIWG) Feature Data Dictionary (DFDD), i.e. to make a profile of DFDD and adding relevant Border Guard specific features and mapping as well the existing NBS feature catalogue to this new Border Guard Feature Catalogue. The DFDD is the successor of the well-known FACC, the Feature and Attribute Coding Catalogue [DGIWG 2000] to which the SIE shall also be compatible, and DGIWG recommends to use in the future the DFDD.

Note that the DFDD was used in the frame of the MGCP, the Multinational Geospatial Co-production Program, for which an overview is given in [Farkas 2009]. DFDD therefore has a high level of interoperability with potential allies.

DTED is standardized via [NIMA 2000] and [NATO2004]. State-ofthe- art maritime / nautical charts are nowadays provided in digital format based on standards from the International Hydrographic Organization (IHO) and its bureau, the International Hydrographic Bureau (IHB). Not only the contents and the visualization styles of nautical charts are standardized for both analogue [IHO 2012a] and digital data [IHO 2000 Appendix A, IHO 2010] but especially the digital formats of nautical charts [IHO 2000 Appendix B; IHO 2012b]. Electronic Nautical Charts (ENC) were developed in the frame of the development of Electronic Chart Display and Information Systems (ECDIS, cf. e.g. [Hecht et al. 2011]) and the carriage requirements for ships from the International Maritime Organization (IMO). ENC are the only officially authorized data sets allowed to be used for an ECDIS. As the Border Guard will also have communication with Search & Rescue (SAR) units and shall be interoperable with other KSA agencies which potentially will use the available ENC in ECDIS, a requirement refined from the general requirement to integrate maritime charts is to use was well ENC data in the SIE system to enable communication by use of equal data sets, even when SIE is not an ECDIS as specified by [IEC 2008]. Nevertheless it is for example stated by IHO as well [IHO 2011] that ENC data should be part of (national) spatial data infrastructures as they describe maritime and navigational aspects of the environment and thus are important for a comprehensive future COP for the Border Guard. Air Charts are described in general by [ICAO 2010] and it is currently under investigation which air charts will be integrated in the system, depending on commercial availability or availability as customer furnished item.

Besides the integration of geospatial data into the SIE system, it is clear that bounding environmental conditions have a strong impact on missions as well as on sensor coverage. Therefore environmental data has to be provided in the SIE system where current weather data is certainly one of the most important data to be mentioned as it provides bounding conditions of the situation in the field and also for the deployment of own forces to counter incidents. Environmental data to be included in the system comprises:

• Weather data: World Meteorological Organization (WMO) and International Civil Aviation Organization (ICAO) formats to be used such as but not limited to:
  • GRIB (GRIdded Binary for version 1 / General Regularlydistributed Information in Binary form for version 2);
  • BUFR (Binary Universal Form for the Representation of meteorological data);
  • TAF (Terminal Aerodrome Forecast);
  • METAR (Meteorological Aerodrome Report);
  • SIGMET (SIGnificant METeorological information for aviation);
  • synoptic and other meteorological data;
• Tide tables;
• Sunset/Sunrise/Sun Plot, Moonset/ Moonrise/Moon Plot. Additionally, prayers and a gazetteer with Arabic place names shall be provided within the system.
• Weather data is standardized in general by the World Meteorological Organization (WMO) [WMO 2011a/b] and the aviation related aspects by the International Civil Aviation Organization (ICAO), cf. [ICAO 2011].

Geospatial & environmental reference system element architecture

Bounding conditions for the system element architecture

Integration of several system elements and interfaces into an overall system has to consider a multitude of bounding conditions. For the G&ERSE the main architecture drivers are in particular:

• The use of different geographic information system (GIS) software families within the SIE system elements, i.e. the solutions used for the mobile forces and the surveillance system elements are based on products from the Luciad company, and the existing main BG GIS infrastructure as well as the Command & Control (C2) headquarter component is based on Esri technology. The G&ERSE has to serve and support both families of GIS software products.

• The Mobile C2 forces will not have online access to geospatial data; hence they have to store data locally but being able of updating its repository when connected again.

• The refined requirement to include ENC in the system, and these ENC have to be visualized in all system elements in the general spirit of a COP, i.e. common data from one source and similar visualization in all system element’s graphically enabled clients.

• The Esri GIS software family does not support the processing of commercial ENC data in its encrypted variant [cf. IHO 2012b], it only supports the un-encrypted data format of ENC [IHO 2000].

Interfaces of the geospatial system element

The Figure 1 depicts the internal interfaces the G&ERSE has within the SIE system. It has to be distinguished between interfaces where services will be provided for enabling functionality in other system elements, like C2, Intelligence and Surveillance, and interfaces where services from other system elements are consumed.

The latter are general IT services, e.g. provision of storage for geospatial data in terms of file systems and databases (e.g. Oracle) and middleware services to provide the opportunity to connect the G&ERSE with the outer world by secure means.

Services provided from G&ERSE comprise the access to geospatial & environmental data as needed by the individual other system elements. In order to provide the requested interoperability, there will not only be proprietary interfaces such as Esri internal interfaces between Esri servers from G&ERSE and clients from G&ERSE and other system elements (and similarly between Luciad servers and Luciad based clients), but also interfaces based on open standards such as the standards from the Open Geospatial Consortium (OGC).

The most important interface to be mentioned is obviously the Web Map Service (WMS) interface, as specified by the OGC [OGC 2006] but also standardized as ISO 19128:2005. This will also enable to serve thin clients in the system, i.e. browser based clients, with geospatial and environmental data. It also supports provision of data where clients cannot read specific formats natively, or where clients shall have a common style of visualization in the spirit of a COP as data provided by a WMS is already visualized data rather than data where still a styling has to be applied to.

Figure 2 depicts the way how external data sources may be accessed. The core requirement from a geospatial perspective is here to provide the opportunity to update the geospatial & environmental reference on a regular basis. The Information Middleware System Element provides therefore a gateway with a Demilitarized Zone (DMZ) to protect the SIE system from unauthorized access. Via this DMZ access is provided to external data providers. Whereas the update frequency for example for weather data is quite high ranging from 1 to 6 hours or even higher for weather satellite imagery, providers for ENC update their charts in accordance with the Notice To Mariner scheme (cf. International Convention for the Safety of Life at Sea, SOLAS, Chapter V – Safety of Navigation, Regulation 9 – Hydrographic Services). Typical update periods are two weeks, so that differential updates need to be received in a system using this data every fortnight, and after some update periods full new data sets are provided in order to avoid an administrative overhead with the updates.

For the provision of meteorological data the operational SIE system will have an online access to an external weather data provider to retrieve weather and meteorological data in accordance to the frequency in which this data is available. As the requested variety of weather data is typically not read by all GIS systems, it is planned in the architecture to have in parallel to the core geospatial database a meteorological database and application that pre-processes and stores the data and visualizes it so that it can be read easily in standard GIS clients via OGC interfaces. This is discussed below in more detail.

For oceanographic data which is necessary for example for Search & Rescue applications it is still under investigation which source could provide this data for the Arabian Gulf and the Red Sea to support respective missions.

Overview of the current geospatial & environmental reference system element architecture

The Figure 3 provides the current stage of planning how the geospatial & environmental architecture will look like on the level of the National Headquarter (NHQ). On the top level the various different types of geodata are listed, and on the left are the applications that use this data via the technical infrastructure. For the processing and provision of vector map data it is planned to have a central Esri ArcGIS for Server. The ArcGIS for Server will also be used for metadata management in general, and the metadata shall also be used by the Luciad Fusion Server. For redundancy and security reasons a similar architecture is currently planned for the HQs of the next subordinated level, and data is passed through via various replication mechanisms on a data need basis. On even lower organizational levels it is planned to have either local copies of geodata, e.g. a File Geodatabase, or to rely on the provision of geodata via respective services like OGC or REST services from the ArcGIS for Server. Web clients will have access to data via OGC services.

The C2 Mobile Clients (not depicted in the figure) have the peculiarity that they cannot update geodata when in the field due to bandwidth issues. They will update when they are directly connected to the network again. They will make use of the Luciad Tile Stream Service (LTS) which is basically a file cache, and the C2 Mobile will have an application to extract mission relevant parts of this geodata cache onto their harddrive when they are planning for their mission. DTED data is provided in visualized way via WMS, and a Web Coverage Service (WCS, e.g. [OGC 2010] or one of the predecessor versions) will provide access to elevation data files, for example for observation processing at the sensors or numerical terrain analysis like line of sight computations.

Besides these architecture parts related to core geospatial data, there will also be a weather data provision via WMS and a WCS for provision of GRIB data to applications in need of numerical rather than visualized weather data, like SAR applications. The weather data provision is discussed in more detail in the next section.

Prototypes to prepare for development

With the deployment of the Northern Border Security system the Border Guard already has an outmost sophisticated C4ISR system in place that is at the leading edge of technology in the world. It is currently in the process of installation, rollout and acceptance, and some parts are already in operation. The reason to develop prototypes for certain aspects in the SIE system were to investigate in more detail the issues that are new in SIE in comparison to the NBS system as SIE will even enhance the outstanding functionality of NBS due to SIE’s far more extended scope. For the G&ERSE there were in particular the new requirements concerning the provision of weather data as well as the new maritime sectors which have to be provided with appropriate maritime charts, i.e. ENC as described above. Another reason was to start to work on the realization of both national and international interfaces as from existing experience it was clear that this will take a considerable amount of time. It is also stated in literature (e.g. [Tomlinson 2011]) that prototypes or pilot projects as they are termed as well are useful in demonstrating planned capabilities to management and potential users, for evaluating performance and solving data problems.

GIS prototype weather

For the GIS Prototype Weather the most important requirements are:

• Be capable of reading and processing the required weather data formats, as listed in Sec. 2.2 on a 24/7 basis;
• Retrieval of this weather data in the frequency as updates are available at the weather data provider, e.g. the Presidency of Meteorology and Environment (PME) in Jeddah;
• Expose visualized weather data via the OGC WMS, including the GetFeatureInfo interface to query individual stations or point-based observables;
• Store the weather data for a certain period of time, where there shall be a configurable default storage time and as well an extended time period for which weather data that is of particular interest can be stored;
• Provide an OGC Web Coverage Service (WCS) for provision of weather data via GRIB files for system elements who not only need visualized data but also numerical weather data, for example to feed the SAR software with environmental parameters to predict the drift way of objects at sea.

After a tender procedure involving several companies a renown company was selected that is already present with its products in KSA as it provides for example parts of the technical infrastructure of the PME. The selected product is a highly flexible and configurable installation that supports in particular provision of weather information via OGC services in a sophisticated way. For the provision of weather data an online access from the prototype to a weather data provider was realized. Figure 4 shows a sample screenshot from the prototype’s Graphical User Interface (GUI) how access to meteorological data could be provided and here in particular how access to weather forecasts could look like. A particular feature is that a specific time slider was implemented that enables to visualize the weather forecast for different time slots using one WMS and involving the “TIME” parameter of the GetMap request (see Figure 4 upper right corner). Based on the GetFeatureInfo interface it is also possible to query the field of values to retrieve numerical values of phenomena (see Figure 4 lower left corner), or to query synoptic weather data from stations.

GIS Prototype Maritime

A broad overview on the relevant standards on ENC has already been given. In detail the main requirements for the GIS Prototype Maritime are:

• The GIS Prototype Maritime shall provide Electronic Navigational Chart (ENC) data via an OGC Web Map Service interface [ISO 2005; OGC 2006].
• The ENC WMS shall provide the WMS GetFeatureInfo interface operation [cf. ISO 2005; OGC 2006] for retrieval of textual attribute information of ENC objects. Note: the GetFeatureInfo interface is not a mandatory operation for a WMS; therefore this interface operation is requested explicitly for the mentioned purpose.
• The GIS Prototype Maritime shall be capable of handling both unencrypted and encrypted ENC data, i.e. S-57 [IHO 2000 Appendix B] and S-63 formats [IHO 2012b].
• The GIS Prototype Maritime shall be capable of handling updates for both un-encrypted and encrypted ENC data, i.e. S-57 [IHO 2000 Appendix B] and S-63 formats [IHO 2012b].
• The portrayal of ENC data shall be in the general spirit of S-52 [IHO 2010] with regard to symbolization of ENC content and the use of units on the display.
• The ENC WMS shall be configurable with regard to colour tables (daytime, night-time), display categories (Base, Standard, Additional), depth settings, display of chart cell boundaries, the indicators for availability of higher resolutions as well as indicators for overscale presentation, as described by S-52 [IHO 2010] and ECDIS Performance Specification [IEC 2008].

As there is the bounding constraint for the geospatial architecture to include a Luciad Fusion Server for the provision of geospatial data, it was decided for aspects of synergies that the Luciad Fusion Server shall also be used for the publication of the ENC WMS. Although this was at that time not a feature of the Fusion Server, a custom development based on the above mentioned requirements (and others more detailed ones) was conducted as a prototype. Figure 5 shows a sample screenshot from the maritime prototype’s GUI using the IHO Test Data Sets for ECDIS [IHO 2012c]. Additionally the screenshot shows the return of a GetFeatureInfo request. Please note that the service returns attributes not only for one feature but for all features that have been identified at the respective position. For the example a DEPth AREa (DEPARE) has been identified which has two Depth Range VALues (DRVAL1 and DRVAL2) indicating the depth ranges in this area, and a wreck (WRECKS) resides at this location, having attributes CATWRK (CATegory of WRecK) equal to 2 (dangerous wreck), QUASOU (QUAlity of SOUnding measurement) equal to 2 (depth unknown) as well as WATLEV (WATer LEVel effect) equal to 3 (always under water/submerged).

Discussion

From an architectural and technical perspective it is a challenge to built a system that shall support all the different domains, i.e. land operations, maritime operations and to a certain extent air operation by including land mapping and maritime and air charts, as the different GIS software families on the market have different strengths and advantages driven by the backgrounds where the different products come from. There is no all-embracing data model and format available. The use of open standards supports in particular the set-up of such an integrated and centralized geospatial data infrastructure. It is advantageous to use open standards therefore not only for external interfaces but also for internal interfaces. From an integrators perspective, this eases and de-risks the development of a large system considerably as open and/or international standards not only are commonly implemented but also provide the opportunity to exchange a subcontractor or a client software without too much impact on the architecture, in case a subcontractor is for various reasons not available anymore or a client software has to be replaced. Additionally, it is much easier to specify interfaces as it is possible to reference to existing and accepted standards.

Conclusions

With the introduction of a comprehensive
Geospatial & Environmental Reference infrastructure the KSA Border Guard geoinformation working group will be well prepared for its future challenge to support the geographically enabled applications in the future KSA Border Security system with up-to-date data in a consistent and reliable way. The geospatial architecture and data to be supplied inherently support a high level of interoperability as to an outmost extent open standards were adopted for the design of the architecture and the specification of data.

The GIS Prototypes that were run to derisk development for the Geospatial & environmental Reference were a successful step to show on the one hand current technical limitations in commercial software and to start to work on them, including sizing investigations, on the other hand the prototypes revealed again that it is a challenge to implement online interfaces with both national and international agencies. In that sense they supported both the technical and the organizational and administrative set-up of the geospatial system element. Additionally it is an opportunity for the end-user of a system to familiarize at an early stage of development with the future system and by doing so and providing feedback to improve end-user satisfaction. It is also a means to familiarize as well at an early stage with all the relevant standards stemming from the different (geospatial) standardization organisation, like DGIWG, ICAO, IEC, IHO, ISO, NATO, OGC, WMO, etc. Consequently it can only be highly recommended to conduct such prototypes or pilot projects to prepare for the success of a system in general or for the case at hand a geospatially enabled system in particular.

References

DGIWG, 2000: The Digital Geographic Information Exchange Standard (DIGEST) Part 4 Feature and Attribute Coding Catalogue (FACC). Edition 2.1 September 2000.

Farkas, I., 2009: Key points and the most significant documents in the production of the High Resolution Vector Data (HRVD) within the Multinational Geospatial Co-production Program (MGCP). Academic and Applied Research in Military Science (AARMS) Vol. 8, No. 1, 141–149.

Hecht, H., Berking B., Jonas M. & Alexander L. 2011: The Electronic Chart, Fundamentals, Functions, Data and other Essentials. Geomares Publishing; 3rd Edition (2011).

ICAO 2011: International Standards and Recommended Practices, Annex 3 to the Convention on International Civil Aviation – Meteorological Service for International Air Navigation.
17th Edition, ICAO, July 2010.

ICAO 2010: International Standards and Recommended Practices, Annex 4 to the Convention on International Civil Aviation – Aeronautical Charts. 11th Edition, ICAO, July 2009.

IEC 2008: Maritime navigation and radiocommunication equipment and systems – Electronic chart display and information system (ECDIS) – Operational and performance requirements, methods of testing and required test results (IEC 61174:2008).

IHO 2000: Publication S-57: IHO Transfer Standard for Digital Hydrographic Data. Edition 3.1 – IHB, November 2000.

IHO 2010: Publication S-52: IHO Specifications for Chart Content and Display Aspects of ECDIS.
Edition 6.0, IHB, March 2010.

IHO 2011: Publication C-17: Spatial Data Infrastructures “The Marine Dimension”. Edition
1.1.0, IHB, February 2011.

IHO 2012a: Publication S-4: Regulations of the IHO for International (INT) Charts and Chart Specifications of the IHO. Edition 4.3.0 – IHB, August 2012.

IHO 2012b: Publication S-63: IHO Data Protection Scheme. Edition 1.1.1 – IHB, April 2012.

IHO 2012c: Publication S-64: IHO Test Data Sets for ECDIS. Edition 2.0.0 – IHB, May 2012.

ISO 2005: Geoinformation – Web Map server interface (ISO 19128:2005).

KSA MOI 2007: General Directorate of Border Guard – Border Guard Development Program – System Integration Engineer (SIE) Request for Proposal (RfP). 15 July 2007.

NIMA 2000: Performance Specification Digital Terrain Elevation Data (DTED). NIMA (United States National Imagery and Mapping Agency, nowadays National Geospatial-Intelligence Agency NGA) MIL-PRF-89020B, 23 May 2000.

NATO 2004: STANAG 3809 IGEO (Edition 4) – Digital Terrain Elevation Data (DTED) Exchange Format.

OGC 2006: OpenGIS® Web Map Server Implementation Specification, v. 1.3, OGC Document
Number OGC® 06-042.

OGC 2010: OGC® WCS 2.0 Interface Standard – Core, v. 2.0.0, OGC Document Number OGC® 09-110r3.

Tomlinson, R. 2011: Thinking about GIS – Geographic Information System Planning for Managers. 4th Edition, Esri Press, Redlands, California, USA.

WMO 2011a: WMO-No. 306 Manual on Codes – International Codes Volume I.1 Part A – Alphanumeric Codes.

WMO 2011b: WMO-No. 306 Manual on Codes – International Codes Volume I.2 Part B – Binary Codes.

Internet Ressources

DFDD: DGIWG Feature Data Dictionary, URL: https://www.dgiwg.org/FAD/ overview.jsp (last visited 20.01.2013)

DGIWG: Defence Geospatial Information Working Group, URL: http://www. dgiwg.org/ (last visited 20.01.2013)

FACC: Feature and Attribute Coding Catalogue, URL: http://www.dgiwg. org/digest/ (last visited 20.01.2013)

ICAO: International Civil Aviation Organization, URL: http://www. icao.int/ (last visited 20.01.2013)

IHO: International Hydrographic Organization, URL: http://www. iho.int/ (last visited 20.01.2013)

IMO: International Maritime Organization, URL: http://www. imo.int/ (last visited 20.01.2013)

OGC: Open Geospatial Consortium, URL: http://www.opengeospatial. org/ (last visited 20.01.2013)

SOLAS: International Convention for the Safety of Life at Sea, URL: http:// www.imo.org/About/Conventions/ ListOfConventions/Pages/International- Convention-for-the-Safety-of-Lifeat- Sea-%28SOLAS%29,-1974. aspx (last visited 20.01.2013)

WMO: World Meterological Organization, URL: http://www. wmo.int/ (last visited 20.01.2013) The paper was presented at The Eighth National GIS Symposium in Saudi Arabia during 15-17 April 2013.