\nE-Navigation, as defined by the IMO, is the harmonised collection, integration,\nexchange, presentation and analysis of maritime information on-board and ashore\nby electronic means to enhance berth-to-berth navigation and related services,\nfor safety and security at sea and protection of the marine environment.\n

\n\nIn response, the International Association of Lighthouse Authorities \n([IALA](https://www.iala-aism.org/)) published a number of guidelines such as \n[G1113](https://www.iala-aism.org/product/g1113/) and\n[G1114](https://www.iala-aism.org/product/g1114/), which establish the relevant\nprinciples for the design and implementation of harmonised shore-based technical\nsystem architectures and propose a set of best practices to be followed. In\nthese, the terms Common Shore‐Based System (CSS) and Common Shore‐based System\nArchitecture (CSSA) were introduced to describe the shore‐based technical system\nof the IMO’s overarching architecture.\n\nTo ensure the secure communication between ship and CSSA, the International\nElectrotechnical Commission (IEC), in coordination with IALA, compiled a set of\nsystem architecture and operational requirements for e-Navigation into a\nstandard better known as [SECOM](https://webstore.iec.ch/publication/64543).\nThis provides mechanisms for secure data exchange, as well as a TS interface\ndesign that is in accordance with the service guidelines and templates defined\nby IALA. Although SECOM is just a conceptual standard, the Maritime Connectivity\nPlatform ([MCP](https://maritimeconnectivity.net/)) provides an actual\nimplementation of a decentralised framework that supports SECOM.\n\n## What is the GRAD e-Navigation Service Architecture\n\nThe GLA follow the developments on e-Navigation closely, contributing through\ntheir role as an IALA member whenever possible. As part of their efforts, a\nprototype GLA e-Navigation Service Architecture is being developed by the GLA\nResearch and Development Directorate (GRAD), to be used as the basis for the\nprovision of the future GLA e-Navigation services.\n\nAs a concept, the CSSA is based on the Service Oriented Architecture (SOA). A\npure-SOA approach however was found to be a bit cumbersome for the GLA\noperations, as it usually requires the entire IT landscape being compatible,\nresulting in high investment costs. In the context of e-Navigation, this could\nbecome a serious problem, since different components of the system are designed\nby independent teams/manufacturers. Instead, a more flexible microservice\narchitecture was opted for. This is based on a break-down of the larger\nfunctional blocks into small independent services, each responsible for\nperforming its own orchestration, maintaining its own data and communicating\nthrough lightweight mechanisms such as HTTP/HTTPS. It should be pointed out that\nSOA and the microservice architecture are not necessarily that different.\nSometimes, microservices are even considered as an extension or a more\nfine-grained version of SOA.\n\n## The Niord UK Angular Front-End\n\nAs per the G-1114, there is a need for a UIA service. In the current\nimplementation, this is provided by the Nautical Information Directory (Niord),\na system able to produce and publish Navigational Warnings (NW) and Notices to\nMariners T&P (NM). It was originally developed as part of the\n[EfficienSea2](https://efficiensea2.org/) EU project and subsequently\nimplemented as a production system for the Danish Maritime Authority (DMA).\nFor the needs of the current project however, the original code was ported onto\nthe latest Red-Hat [Quarkus](https://quarkus.io/) and\n[Angular](https://angular.io/) frameworks. In addition, the capability was added\nto generate AtoN information, which can then be encoded into the IHO S-125 data\nformat. Any update on the AtoN information is communicated to the\n“Message Broker” microservice, so that all other microservices that have\nsubscribed to receive updates will be notified. It has to be noted here that\nalthough Niord is a very useful component of the demonstrator test-bed, it is a\nnot a core component of the architecture and any other NW/NM/AtoN management\nsystem could be used instead, at least as long as it is able to generate S-100 \ncompliant data.\n\n## How to use this image\n\nThis image contains the Angular front-end of Niord, served by an \n[nginx](https://nginx.org/en/) web-server. The image itself can be used in just\nlike a normal Docker container, but providing the necessary environment\nvariables while running it. The available environment variables for configuring\nthe application are presented in the following table.\n\n| Variable | Description |\n|---------------------------|---------------------------------------------------------------|\n| NIORD_URL | The URL for the front-end to contact the Niord server |\n| ATON_PUBLICATION_URL | The URL for the front-end to publish AtoN information |\n| KEYCLOAK_URL | The URL for the Keycloak OpenID-Connect authentication seever |\n| KEYCLOAK_REALM | The realm for the Keycloak OpenID-Connect authentication |\n| KEYCLOAK_CLIENT_ID | The client ID for the Keycloak OpenID-Connect authentication |\n\n### Environment Variables Configuration\n\nIn order to run the image you just need to provide the values of the environment\nvariables presented previously. If the default values are sufficient then they\ncan be omitted.\n\nThis can be done in the following way:\n\n docker run -t -i --rm \\\n -p 8080:80 \\\n -e NIORD_URL='niord.server.com' \\\n -e ATON_PUBLICATION_URL='msg.publication.service' \\\n -e KEYCLOAK_URL='keycloak.server.com' \\\n -e KEYCLOAK_REALM='niord' \\\n -e KEYCLOAK_CLIENT_ID='niord-web' \\\n \n\n## Operation\n\nThe original Niord system has extensive documentation already available online\nand you are advised to read this carefully before proceeding. It can found in\n[this](https://docs.niord.org/) online location.\n\nThe current *Angular-based* implementation of the front-end, is pretty similar\nto the original version that was embedded in the Niord Wildfly deployment. \nHowever do not that this is still work in progress and not all the functionality\nof the old interface is still available. Notable things missing are the \nadministration menu and the emailling functionality.\n\n## Contributing\nFor contributing in this project, please have a look at the Github repository\n[Niord-UK](https://github.com/gla-rad/niord-uk). Pull requests are welcome. For\nmajor changes, please open an issue first to discuss what you would like to\nchange.\n\nPlease make sure to update tests as appropriate.\n\n## License\nDistributed under the Apache License, Version 2.0.\n\n## Contact\nNikolaos Vastardis - \n[Nikolaos.Vastardis@gla-rad.org](mailto:Nikolaos.Vastardis@gla-rad.org)\n","has_starred","hub_user","immutable_tags_settings",{"_184":11,"_185":186},"enabled","rules",[187],".*","is_automated","permissions",{"_191":17,"_192":11,"_193":11},"read","write","admin","user","storage_size",1618825519,"isOrg","reponame","tag","sha256:14c190922fb8f3705a34e8e382536d4b6de40b18d9a5aef74005b8c01da71ab3","canDeleteTags","isHubSbxKitsEnabled","currentTab","tagAttestations","displaySecurityMetadata","routes/_layout.layers.$namespace.$reponame.$tag.(images).($imageUrlDigest)._index",{"_22":23,"_143":-7,"_141":-7,"_142":-7,"_24":208,"_30":200,"_211":-7,"_212":11},{"_26":27,"_28":29,"_30":31,"_32":33,"_34":35,"_36":209,"_55":56,"_57":29,"_58":59,"_60":61,"_62":63,"_64":65,"_66":44,"_67":56,"_68":53,"_69":17},[210],{"_39":40,"_30":31,"_41":42,"_43":44,"_45":46,"_47":48,"_49":42,"_50":-5,"_51":33,"_52":53,"_54":-5},"imageWithLayers","hasPermissionToViewRepoSettings","actionData","errors"]

glarad/niord-uk-ng:latest