Introduction

This project is used for calculating road accessibility given certain traffic sign restrictions based on vehicle characteristics. Its main functional modules are a rest api service called backend and a jobs module subdivided into multiple more specialised submodules.

Techincal details

Module setup :

• Specification (API YAML definition)
• Backend REST API
• accessibility shared core module
• Job module for various jobs that need to be in the background.

GitHub vs Azure DevOps

This project is maintained by Nationaal Dataportaal Wegverkeer (NDW)

• It is primarily maintained within Azure Devops and mirrored to https://github.com/ndwnu/nls-accessibility-map
• It works within NDW infrastructure, with some of its constraints;
• This repository contains functionality only, data is gathered from APIs/database, but not included;
• Pipelines are not designed to be used within GitHub;
• GitHub wiki and issues aren't enabled.

Structure

The specification module only versions the API YAML and this JAR is used by the openapi-generator-maven-plugin to generate controllers for the backend application.

Development

Execute make start-infra Run the backend and the jobs through IntelliJ. Make sure you use at least the profiles acceptance-test,dev Run any component test.

Running with representative data locally

A common pitfall is to connect your dev environment to the staging database, but this should not be done, as this will also update the active cache versions in the staging database, which will then break the staging environment. It's better to copy the staging disk caches to your local caches and then point to it in your local database:

1. copy data to local disk kubectl cp nls-accessibility-map-api-5<some-pod-id>:cache
2. copy staging active_versions table to local and make sure your application runs with the same cache_version
3. in src/main/resources/data copy the municipalities.yml to municipalities-<your-profile>.yml
4. in src/main/resources/data copy the road-operators.yml to road-operators-<your-profile>.ymlFirst run make start-infra. Then run the job initializeCache with profiles acceptance-test,dev,job-initialize-cache,local-<your_name>-staging. Put the staging credentials in local-<your_name>-staging profile. Example:

spring:
  datasource:
    url: jdbc:postgresql://nls-postgres-staging.postgres.database.azure.com:5432/nls-maps?ApplicationName=nls-accessibility-map-job&stringtype=unspecified
    username: nls
    password: <redacted>

Window Times

In the traffic sign API, traffic signs have text signs and some text signs are of type 'TIJD' and they have a field called 'openingHours'. This field will be using the OSM standard for opening hours: https://wiki.openstreetmap.org/wiki/Key:opening_hours

Pretty printing geojson

jq . c6WindowTimeSegments.geojson | sponge c6WindowTimeSegments.geojson

Resetting the nwb updates tracking key

For receiving nwb network updates there is an event stream configured. By renaming stream-tracking-name in the application yaml, all events will be received again. Example:

nu:
  ndw:
    nls:
      accessibilitymap:
        messaging:
          stream-queues:
            updateRoadSection:
              stream-tracking-name: nls-accessibility-map-api-listener-20260528

Also the 'MessagingBeansRegistrarTest' class MESSAGE_LISTENER_NAME property needs to be updated

Caches

The backend application and the analysis jobs require the following caches to be available:

• network
• speedLimits
• trafficSigns

Without them, the backend application will start, but will not become healthy until the caches become available. The jobs module contains jobs that keep the caches up to date, InitializeCacheCommand should always run after deployment as it will verify that the required caches are available and will rebuild any missing caches. Caches are stored on a shared persistent volume claim and database table active_version points to the active version on disk.

Incompatible cache versions

When using rolling updates, there will be a brief moment where the old and new application will run alongside of each other. By incrementing the cache-version, you isolate the caches and prevent that the old and new deployment use each others caches. If the cache format changes, the cache-version should be incremented in the application.yaml configuration of the jobs and backend applications. A new PersistentVolumeClaim should be used for the deployment to separate the old caches from the new caches. After deployment, the InitializeCacheCommand should automatically run and initialize the new caches after which the backend should become healthy. With rolling updates, this should cause zero downtime. Don't forget to delete the old persistent storage.