National Addressing System

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Infrastructure Layer ======

//— A means to ensure availability of addressing data//

The database and applications must be run from some server infrastructure. It is assumed that the system at most may have some 120 concurrent users working in 63 different wilayat, municipalities, governorate offices as well as centrally at Ministry of Housing and Urban Planning.

On top of that, there may be 1000s of users accessing the data retrieval and query interfaces in the API. The following hardware and networking infrastructure requirements are based on the above assumptions.

===== 1. Technical requirements specification for database server =====

To create a robust cloud server capable of efficiently handling a system with the specified requirements, consider the following hardware infrastructure specifications. These details are curated to manage up to 120 concurrent users and substantial database interactions typical of web and desktop GIS applications.

=== Processor ===

  * CPU Type and Frequency: Select processors optimized for high performance, such as the Intel Xeon or AMD EPYC series. A fundamental frequency of at least 2.5 GHz or higher is recommended.
  * Number of CPU Cores: An 8-core configuration will provide adequate parallelism to manage concurrent processing demands and database operations effectively.

=== Memory ===

  * Amount of RAM: At least 32 GB of RAM is advisable. This capacity ensures sufficient memory for handling multiple simultaneous queries and operations over large datasets, enhancing performance.

=== Storage ===

  * Type of Storage Technology: Utilise Solid State Drives (SSD) due to their low latency and high-speed data retrieval capabilities, which are beneficial for handling extensive database queries.
  * Amount of File Storage: Allocate at least 1 TB of SSD storage to accommodate the datasets and any additional application-specific data.
  * Optimal File System and Partitioning: Employ the ext4 or XFS file system. These file systems are stable and perform well under high input/output operations. Partition the storage to separate data, index, and log files for better performance management.

=== System Configuration ===

  * Network Configuration: Ensure the server is connected via a high-bandwidth network to accommodate data-intensive operations common to GIS applications.
  * Database Configuration Tweaks: Utilise connection pooling and adjust memory settings within the RDBMS to optimise resource usage.
  * Security Considerations: Implement robust encryption protocols and access control policies to safeguard data integrity and confidentiality.

=== Example Cloud Server Types ===

If the applications will be served in the cloud, these are examples of standard configurations offered by the leading cloud service providers. If the solutions are to be hosted on premise, equivalent hardware/virtual machines may be used.

  * Amazon Web Services (AWS): Consider using the EC2 m5.xlarge instance, which provides 4 vCPUs and 16 GB RAM, or upgrading to m5.2xlarge for greater capacity.
  * Google Cloud Platform (GCP): The n1-standard-8 instance comes with 8 vCPUs and 30 GB RAM, aligning well with the requirements.
  * Microsoft Azure: Look at the Standard_D8s_v3 instance, offering 8 vCPUs and 32 GB RAM, suitable for the described workload.

===== 2. Technical requirements specification for application server =====

For a system accommodating 120 concurrent users and managing substantial datasets, a robust cloud server infrastructure is essential. Below are the recommended specifications based on the criteria provided:

=== Processor ===

  * CPU Type and Frequency: Utilise Intel Xeon or AMD EPYC processors with a minimum base frequency of 2.5 GHz.
  * Number of CPU Cores: Opt for a configuration with 16 to 32 CPU cores to ensure responsiveness under load.

=== Memory ===

  * Amount of RAM: A minimum of 64 GB RAM is advisable for efficient data handling and application performance.

=== Storage ===

  * Type of Storage: Implement NVMe SSD storage for fast data retrieval and enhanced system performance.
  * Amount of File Storage: Allocate approximately 4 TB of storage to accommodate the databases and additional file requirements.
  * File Storage Technology: Consider using SAN (Storage Area Network) if high scalability and data redundancy are priorities.
  * File System: Utilise ext4 or XFS file systems for optimal performance under Linux-based operations.
  * Partitioning: Ensure separate partitions for system files, application data, and logs to enhance security and manageability.

=== System Configuration ===

  * Network Configuration: Optimise NGINX for high concurrency by adjusting worker processes and connections.
  * Database Settings: For the relational database, configure connection pooling and indexing for efficient query handling.
  * Performance Monitoring: Implement continuous monitoring and scaling to adapt to workload variations.

=== Example Cloud Server Types ===

If the applications will be served in the cloud, these are examples of standard configurations offered by the leading cloud service providers. If the solutions are to be hosted on premise, equivalent hardware/virtual machines may be used.

  * Amazon Web Services (AWS): Consider c6i.2xlarge or r6i.2xlarge instances. They provide ideal balance and cost-effectiveness for handling applications of this scale.
  * Google Cloud Platform (GCP): The n2-standard-32 configuration offers ample resources, combining high compute performance with significant memory.
  * Microsoft Azure: The D16s v5 size can accommodate demanding workloads with considerable CPU power and substantial memory.

These configurations are recommended to ensure that the system is scalable, responsive, and reliable for both web and desktop GIS applications.

===== 3. Network infrastructure =====

Network infrastructure plays a crucial role in supporting the National Addressing System. When considering the specifications for such an environment, it is essential to focus on parameters such as bandwidth, uptime, and latency to ensure optimal performance. Below are recommendations suited for the outlined requirements:

=== Bandwidth requirements ===

  * For handling a variety of operations, including a database server, file server, and web application server with Docker containers, a robust bandwidth is essential.
  * A dedicated internet connection with a minimum of 1 Gbps is advisable. This should accommodate data-intensive tasks, concurrent user access, and data retrieval from large relational tables effectively.
  * Ensure scalable bandwidth options to accommodate future growth in user number or data volume without degradation in service quality.

=== Uptime requirements ===

  * The system should aim for an uptime of at least 99.9%. This reflects high availability, ensuring minimal downtime throughout the year.
  * Implement redundant network paths and failover strategies to maintain continuity. Using high-availability network infrastructure components such as clustered firewalls and redundant power supplies is also beneficial.

=== Latency requirements ===

  * Low latency is critical for user interactions, particularly when serving web and GIS applications with real-time data processing needs.
  * Target a network latency of less than 100 milliseconds for end-to-end communication within Oman.
  * Utilise modern routing protocols and optimisation techniques to ensure that data packets traverse the most efficient pathways, reducing potential delays.

Always consider potential future growth and adjust server capacities as necessary to maintain system performance.

===== 4. Client requirements =====

The requirements only apply for users who are going to have roles in creating or maintaining addresses or who wish to establish integrations where they interact with the addressing API.

The address search application as well as any third-party address data access mechanisms are exempt from these recommendations.

When building a business-oriented React web application that relies heavily on web maps (both PBF vector tiles and PNG raster tiles), it’s important to establish baseline client-side requirements to ensure acceptable performance and user experience. Rendering vector tiles in the browser involves client-side decoding (often via WebGL) and styling, while raster tiles require frequent image loading. Below are starting-point recommendations for CPU, RAM, screen resolution, browsers, and network bandwidth on client machines.

=== CPU (Processor) ===

  * Requirement: A modern multi-core CPU with good single-thread performance (e.g., recent Intel Core i5/i7 or AMD Ryzen 5/7 equivalents or better).
  * Rationale: Vector tile rendering is performed client-side via WebGL or Canvas, which benefits from both GPU acceleration and CPU tasks such as tile parsing and layout updates. Lower-end or very old CPUs may exhibit sluggish pan/zoom and style updates. Raster tile handling (downloading and compositing PNGs) also uses CPU for decoding image data and updating the DOM/canvas. Modern multi-core chips help when multiple browser tabs or other applications run concurrently.

=== Recommendations: ===

  - Minimum: Dual-core CPU at ~2.0–2.5 GHz (e.g., older Intel Core i3 or equivalent), but expect limited performance when many layers/features are shown or on complex style changes.
  - Recommended: Quad-core or better at ~3.0 GHz or higher. This ensures smoother interactions, especially when the map has many vector layers, dynamic styling, or frequent updates (e.g., real-time data overlays).

=== GPU / Graphics (indirectly via browser) ===

  * Requirement: Hardware-accelerated WebGL support in the GPU/driver, available in all modern integrated GPUs (Intel HD/UHD Graphics of recent generations) and discrete GPUs.
  * Rationale: Libraries like ArcGIS, OpenLayers, Mapbox GL JS, MapLibre, and similar rely on WebGL to render vector tiles efficiently on the GPU. Without hardware acceleration, performance may degrade significantly, and some browsers may fall back to software rendering (which can be slow).
  * Recommendations: Use client machines whose browsers report “Hardware accelerated” for WebGL contexts. Encourage users to keep GPU drivers up to date. Test on representative hardware to ensure the map renders smoothly.

=== RAM (Memory) ===

  * Requirement: Sufficient system RAM to accommodate the browser, OS, and the mapping app’s memory footprint. Vector tile rendering can consume memory for tile caches, style data, and map state.
  * Rationale: Browsers cache tiles and resources in memory; having insufficient RAM can cause swapping, leading to lagging interactions, especially when multiple tabs or heavy pages are open. Complex React applications (with state management, large data arrays, and map libraries) benefit from more headroom.
  * Recommendations:
      * Minimum: 4 GB of RAM free for the browser process (e.g., on a system with at least 8 GB total RAM, leaving room for OS and background tasks). With only 4 GB total RAM on the machine, mapping performance will suffer if the user runs other demanding apps simultaneously.
      * Recommended: 8 GB to 16 GB total system RAM, providing at least 6 GB free for the browser when the mapping app is active. This supports multiple open tabs, larger tile caches, and additional data overlays without excessive garbage collection or swapping.

=== Screen resolution and display ===

  * Requirement: A responsive layout that adapts to various screen sizes, with testing on the effective minimum resolution expected in your user base.
  * Rationale: Business users may work on laptops, desktops, or even high-resolution monitors; the mapping interface should leverage available screen real estate but remain usable at lower resolutions.
  * Recommendations:
      * Minimum supported viewport: 1366 × 768 CSS pixels (common baseline for many business web apps)
      * Recommended viewport: 1920 × 1080 (typical desktop/laptop higher end)

=== Client browsers (Software) ===

  * Requirement: Modern, standards-compliant browsers with up-to-date WebGL and JavaScript performance.
  * Rationale: Vector tile libraries rely on ES6+ JavaScript features, WebGL 1.0 (at least), and often Web Workers. Older browsers (e.g., IE11) may lack support or require polyfills, reducing performance and sometimes preventing core features. Frequent browser updates include performance and security patches important for business applications.
  * Recommendations:
      * Supported Browsers: Latest two major versions of Google Chrome, Mozilla Firefox, Microsoft Edge (Chromium-based), and Apple Safari (on macOS)
      * Enterprise Constraints: If corporate policies mandate specific browser versions, ensure the minimum supported versions still have required WebGL/ES6 support. If not, consider polyfills or limiting features (e.g., use raster tiles fallback if vector rendering is unavailable).

=== Client network bandwidth and latency ===

  * Requirement: Broadband-speed connectivity with reasonable latency to tile servers (self-hosted or third-party).
  * Rationale: Vector tiles (PBF) are typically well-compressed (often ~10–50 KB per tile depending on zoom level and data complexity), but many tiles load as users pan/zoom, plus style and font resources. Raster PNG tiles can be larger (~20–100 KB each). Slow networks will cause delayed tile loads, leading to blank or low-detail map areas during navigation. Latency affects perceived responsiveness: high round-trip times delay tile requests.
  * Recommendations:
      * Minimum: Sustained download speeds of at least 5 Mbps, with latency under ~100 ms to the tile server endpoint. On slower links (e.g., 3G/4G intermittent, VPNs), consider (a) lowering initial zoom or extent to prefetch fewer tiles, (b) using vector tiles with simplified style to reduce tile count or size and © implementing tile caching (browser cache, service workers) and using HTTP/2 for concurrent requests.
      * Recommended: 10 Mbps or higher with latency under ~50 ms for good user experience, particularly if the app loads many overlays or high-zoom-level detail.
      * Offline or Low-bandwidth Strategies: If clients occasionally have poor connectivity, provide fallback UI: e.g., show a message, allow offline cached tiles (via service workers), or reduce map detail (fewer tile layers) when bandwidth is constrained.

Summary client requirements table (baseline vs. recommended)

^ \\ Component^ \\ Minimum^ \\ Recommended|
^ \\ CPU| \\ Dual-core ~2.0–2.5 GHz| \\ Quad-core ~3.0 GHz+|
^ \\ GPU/WebGL| \\ Basic WebGL support| \\ Up-to-date GPU drivers with hardware accel.|
^ \\ RAM| \\ ~4 GB available for browser| \\ 8–16 GB total system RAM|
^ \\ Screen Resolution| \\ 1366 × 768 CSS pixels viewport| \\ 1920 × 1080 pixels viewport|
^ \\ Browsers| \\ Modern: Chrome/Firefox/Edge/Safari| \\ Latest 2 major versions; ensure WebGL enabled|
^ \\ Network Bandwidth| \\ ≥5 Mbps download, <100 ms latency| \\ ≥10 Mbps download, <50 ms latency|

===== 5. Data governance and security measures =====

In developing the National Addressing System in Oman, maintaining data governance and implementing robust security measures are critical considerations. While it is important not to restrict access to addressing data, prioritising data integrity remains essential. Ensuring that data is accurate, reliable, and trustworthy requires specific strategies.

A particular challenge arises from multi-point editing, which can compromise the consistency and accuracy of data. To address this, implementing audit logs and rollback functionalities is necessary. Audit logs will help track changes and modifications, providing a transparent record of data amendments. Rollback features will allow reversal of undesirable changes, ensuring the data's consistency and reliability over time.

Facilitating easy access to data while safeguarding against unfair utilisation is vital. The system should not function as a “free” or subsidised back-end provider for commercial applications. At the same time, enabling easy data access to data for both government and private sector actors is important to support value creation based on the system.

To maintain the integrity of addressing data, especially in distributed systems, ensuring data concurrency across any distributed copies or caches is crucial. Data concurrency will ensure that different versions of the data remain consistent with each other, preventing discrepancies and potential data conflicts.

===== 6. Service Level Requirements for Infrastructure =====

To ensure continuous availability, data integrity, and resilience of the National Addressing System (NAS), the underlying infrastructure must meet clearly defined service level requirements. These requirements are particularly critical given the national importance of address data and the need to support both operational continuity and rapid recovery in the event of an incident.

=== Disaster Recovery ===

A comprehensive disaster recovery plan will be established to protect the NAS against events such as hardware failures, data corruption, natural disasters, and cyber incidents. The plan will include regular, automated backups of all critical data and system configurations, secure offsite storage, and well-documented procedures for restoring service.

=== Recovery Time Objective (RTO) ===

The Recovery Time Objective defines the maximum acceptable duration for restoring full service following a disruption. For the NAS, the RTO shall not exceed 4 hours for core database and API services, ensuring that essential address data and integrations remain available to users and stakeholders with minimal downtime. Routine tests of recovery procedures will be conducted to validate adherence to the RTO.

=== Recovery Point Objective (RPO) ===

The Recovery Point Objective specifies the maximum age of data that may be lost in the event of a failure. For the NAS, the RPO is set at 15 minutes, meaning that backup and replication strategies must ensure that, at most, only the last 15 minutes of transactions could be lost under worst-case scenarios. Incremental backups and near-real-time data replication will be employed to achieve this goal.

=== Optional Multi-Region Deployment (Middle East/Europe) ===

For public facing applications that might be used by global audiences, it may be possible to further strengthen resilience by supporting geographic redundancy, such parts of the NAS infrastructure as is relevant may optionally be deployed in a multi-region configuration spanning the Middle East and Europe.

Multi-region deployment ensures service continuity in the event of regional outages, enables compliance with local data residency regulations, and provides improved latency for users across different geographies. Data synchronization and failover mechanisms will be implemented to keep regional deployments consistent and ready for seamless switchover if required. This is NOT likely to be the case for address creation and maintenance applications that is expected to rely on national data centres.