| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| reference:system-architecture [2025/08/27 06:43] – [2. The Purpose of Integrating Addresses] runarbe | reference:system-architecture [2025/09/09 22:03] (current) – [7. API layer] runarbe |
|---|
| This document provides an overview of all the elements that are required to operate the addressing system data infrastructure. | This document provides an overview of all the elements that are required to operate the addressing system data infrastructure. |
| |
| ===== 1. Scope of the System Architecture Specification ===== | ===== 1. Scope of the Specification ===== |
| |
| The scope of this document encompasses the essential requirements for the creation, maintenance, and dissemination of addresses within the National Addressing System project in Oman. It provides a detailed exploration of the necessary components and methodologies for effective addressing. | The scope of this document encompasses the essential requirements for the creation, maintenance, and dissemination of addresses within the National Addressing System project in Oman. It provides a detailed exploration of the necessary components and methodologies for effective addressing. |
| |
| ===== ===== | ===== ===== |
| |
| |
| ===== 3. Systems Needed to Manage and Use NAS Data ===== | ===== 3. Systems Needed to Manage and Use NAS Data ===== |
| The business of street addressing is a complex set of interrelated managerial, planning, technical and engineering/civil works tasks that involves a broad range of distinctive end-users. The diagram below provides an overview of all the components that are required for the efficient operation and flow of data in the addressing system. | The business of street addressing is a complex set of interrelated managerial, planning, technical and engineering/civil works tasks that involves a broad range of distinctive end-users. The diagram below provides an overview of all the components that are required for the efficient operation and flow of data in the addressing system. |
| |
| {{ :wiki:reference:system:addressing-system-integration-architecture.png?direct&800 |Click on image to view or download in full resolution}} | {{ :wiki:reference:system:addressing-system-integration-architecturev003_1.png?direct&800x444 }} |
| |
| The diagram can be read both bottom up and top down. From the point of view of technical resources, the preferred reading direction is bottom up, for people who find themselves in end-user roles, it is more easily read from top to bottom. | The diagram can be read both bottom up and top down. From the point of view of technical resources, the preferred reading direction is bottom up, for people who find themselves in end-user roles, it is more easily read from top to bottom. |
| * Documentation for the [[:reference:system-architecture:signage-data-model|sign management data model]] (to be supplied by future appointed vendor) | * Documentation for the [[:reference:system-architecture:signage-data-model|sign management data model]] (to be supplied by future appointed vendor) |
| |
| ==== 5.3 Naming data model ==== | ==== 5.3 Name collection data model ==== |
| | |
| | * Documentation for the [[:reference:system-architecture:name-collection-data-model|naming data model]] (to be supplied by existing vendor) |
| | |
| | ==== 5.4 Name allocation data model ==== |
| | |
| | * Documentation for the [[:reference:system-architecture:naming-allocation-data-model|naming data model]] (to be supplied by existing vendor) |
| | |
| | ==== 5.5 Field verification application data model ==== |
| | |
| | * Documentation for the [[:reference:system-architecture:field-verification-data-model|naming data model]] (to be supplied by existing vendor) |
| |
| * Documentation for the [[:reference:system-architecture:naming-data-model|naming data model]] (to be supplied by existing vendor) | |
| |
| ===== 6. Data Layer ===== | ===== 6. Data Layer ===== |
| |
| * [[:reference:system-architecture:authentication-api|Authentication API]] | * [[:reference:system-architecture:authentication-api|Authentication API]] |
| * [[:reference:system-architecture:address-editing-and-query-api|Address Editing and Query API]] | * [[:reference:system-architecture:address-editing-and-query-api|Address editing API]] |
| | * [[:reference:system-architecture:address-integration-api|Address Integration API]] (vendor to be appointed by by competitive tender) |
| * [[:reference:system-architecture:naming-api|Naming API]] (to be supplied by existing vendor) | * [[:reference:system-architecture:naming-api|Naming API]] (to be supplied by existing vendor) |
| * [[:reference:system-architecture:signage-api|Signage API]] (implemenation to be determined through competitive tender) | * [[:reference:system-architecture:signage-api|Signage API]] (vendor to be appointed by by competitive tender) |
| |
| |
| Below, you will find technical and functional requirements for the following applications | Below, you will find technical and functional requirements for the following applications |
| |
| * [[:reference:system-architecture:address-editing-application|Web based data creation and editing client]] | * [[:reference:system-architecture:address-editing-application|Address editing application]] |
| * [[:reference:system-architecture:street-naming-application|Street naming application]] | * [[:reference:system-architecture:street-naming-application|Street naming application]] |
| * [[:reference:system-architecture:mobile-field-verification-application|Mobile field verification application]] | * [[:reference:system-architecture:mobile-field-verification-application|Mobile field verification application]] |
| * [[:reference:system-architecture:addressing-viewer-and-search-application|Addressing viewer and search application]] | * [[:reference:system-architecture:addressing-viewer-and-search-application|Addressing viewer and search application]] |
| * [[:reference:system-architecture:addressing-wiki|Addressing WIKI]] | * [[:reference:system-architecture:addressing-wiki|Addressing WIKI]] |
| | |
| |
| ===== 9. Infrastructure layer ===== | ===== 9. Infrastructure layer ===== |
| |
| * [[:reference:system-architecture:infrastructure|Technical infrastructure specification]] | * [[:reference:system-architecture:infrastructure|Technical infrastructure specification]] |
| |
| |
| ===== 10. Emerging technologies and future proofing ===== | ===== 10. Emerging technologies and future proofing ===== |
| |
| Integration refers to the incorporation of addressing systems into various operational, security, and convenience-oriented applications for both residents and visitors in the Sultanate of Oman. It involves embedding addressing as an element within a database table or an object model in business applications. This enables effective indexing and geocoding of records and subsequent location of assets and/or delivery locations for goods services and people. | Integration refers to the incorporation of addressing systems into various operational, security, and convenience-oriented applications for both residents and visitors in the Sultanate of Oman. It involves embedding addressing as an element within a database table or an object model in business applications. This enables effective indexing and geocoding of records and subsequent location of assets and/or delivery locations for goods services and people. |
| | |
| | ==== 13.1 The Purpose of Integrating Addressing into other systems ==== |
| | |
| | The integration of addresses into other systems serves several essential purposes, primarily aimed at creating value for individuals, businesses, organisations and government bodies. Address systems become meaningful only when they actively contribute to achieving specific objectives, thereby justifying the considerable effort and expense involved in their implementation. |
| | |
| | The concept of "value" within the context of address integration encompasses several aspects. Firstly, it provides ease in locating items or places, making navigation and discovery more straightforward. It also contributes to speed by enabling the faster delivery of people, goods, and services. Moreover, it can reduce costs associated with tasks such as locating customers – or even absconding taxpayers. An integrated address system enhances safety by minimising risks during emergency situations, such as reducing the likelihood of injury due to timely assistance. |
| | |
| | In addition to tangible measures, the notion of an improved addressing system further extends to being just, fair, and equitable, providing benefits across various sectors. The system should also be accessible, facilitating easier operations, and its visual presentation should be designed for aesthetic appeal, or at the very least not to scare off users. |
| | |
| | To illustrate the value added by integrated address systems, consider several examples. They allow for precise specification of delivery locations, ensuring parcels reach their intended destinations efficiently. The system also aids in identifying the location of individuals or entities, such as querying the whereabouts of "Krookie XYZ". Furthermore, during urgent scenarios, such as calling for an ambulance, verbal communication of locations becomes clearer and more reliable. |
| | |
| | Additionally, integrated address systems enable users to conveniently identify and associate multiple personal assets with specific locations. This includes one's land, house, telecom subscriptions, electricity meters, vehicles, and other property. An address acts as an efficient key that links and organises various belongings, simplifying management and oversight. For a person wishing to access a public service, it is necessary to identify him or herself by some means known to both parties. Successful and widespread adoption of addresses will often make it possible to identify the objects or assets under discussion out of hand. |
| | |
| | ==== 13.2 How integrations will be done ==== |
| |
| Integration processes will be executed by business owners, not by the Ministry of Housing, Urban Planning. MoHUP will support by providing data access, adapting services, and facilitating systems. While MoHUP may promote integration and encourage business owners to recognise its benefits, ultimate responsibility rests on the business owners. Given the sensitivity of critical systems, business owners must perceive the value of integration for it to proceed independently. | Integration processes will be executed by business owners, not by the Ministry of Housing, Urban Planning. MoHUP will support by providing data access, adapting services, and facilitating systems. While MoHUP may promote integration and encourage business owners to recognise its benefits, ultimate responsibility rests on the business owners. Given the sensitivity of critical systems, business owners must perceive the value of integration for it to proceed independently. |
| |
| Many business systems are already structured to accommodate addressing, particularly the newly implemented international formats. MoHUP's primary responsibility will be to ensure stakeholders are informed about, and have access to, necessary data and systems, thereby enabling seamless integration. | Many business systems are already structured to accommodate addressing, particularly the newly implemented international formats. MoHUP's primary responsibility will be to ensure stakeholders are informed about, and have access to, necessary data and systems, thereby enabling seamless integration. |
| | |
| | ==== 13.3 Proposed integrations ==== |
| |
| * [[:reference:system-architecture:integrations|Categorised list of value-added integrations of addressing data]] | * [[:reference:system-architecture:integrations|Categorised list of value-added integrations of addressing data]] |
| |
| |
| ===== 14. Data Quality Framework ===== | ===== 14. Data Quality Framework ===== |
| |
| * [[:reference:system-architecture:data-quality|Data quality]] | * [[:reference:system-architecture:data-quality|Data quality]] |
| |
| |
| ===== 15. Transitional Arrangements ===== | ===== 15. Transitional Arrangements ===== |
