The PTV Content Update Service (CUS) enables additional data content to be automatically downloaded and provided. A separate PTV Layer Delivery Server (LDS) provides current data such as toll updates and Traffic Incidents Feature Layer, which is automatically downloaded via the CUS and can be used from a PTV xServer.
The PTV Content Update Service is implemented as a plug-in for the PTV xServer. In versions 1.16.1.0 to 1.18.1.X it comes automatically as standard with the PTV xRoute server, but is deactivated by default. From version 1.20.0 the PTV Content Update Service is deployed as a separate artifact.
From version 1.26.0 on we recommend to use the new PTV Content Update Service 2. For this you need the corresponding PTV Content Update Service Adapter for xServer 1. Please regard the additional documentation in the adapter artifact.
The following PTV xServer are supported with the following data content.
| PTV xServer | Toll updates | PTV_TrafficIncidents Feature Layer |
|---|---|---|
| PTV xMap | - | From version 1.20.0.0 |
| PTV xRoute | From version 1.16.1.0 | From version 1.20.0.0 |
The PTV Content Update Service 1 is installed as a web app on the PTV xServer. The update service communicates with one or several PTV Layer Delivery Servers (LDS) to receive new relevant data. If new data is available, this will be downloaded in the background. After successful download, the behaviour of the toll updates and Feature Layer is different and is described in the corresponding chapter.
Specific data from the LDS can be extracted via a filter selected in the CUS, in order to only download data that is relevant to the corresponding PTV xServer or set map version. Filter selection is found in the respective chapters: Toll Updates and Feature Layer.
Two mechanisms are available for downloading data: a Polling Mechanism (available from PTV xServer Version 1.16.1) and a Subscription Mechanism (available from PTV xServer Version 1.18.1). With the Polling Mechanism the CUS contacts the LDS at configurable intervals and asks if new data is available. With the Subscription Mechanism on the other hand, the CUS is automatically notified when new data is available. If the CUS is configured for Subscription Mode, this mechanism will be used automatically. For this purpose, a broker URL must be specified in the configuration file. You will find the configuration options for both approaches in the "Basic Configuration" chapter.
In addition, the CUS regularly checks which files are still in use and regularly deletes data that is no longer used after an update.
The current version of the PTV Content Update Service 1 can be downloaded in the Customer Area. A customer login is required.
After downloading the CUS, the zip file must be unpacked and both "conf" and "webapps" folders copied to the PTV xMap or PTV xRoute server root directory. A content-update.properties file will now be in the "conf" folder, in which you can configure the CUS, as described in the "Basic Configuration" chapter.
The PTV Content Update Service must have access to the directory in which the map is stored, as data such as toll updates is stored in the map directory at installation.
Via the PTV xServer Management Console, you can check whether the Update Service is running and is correctly configured. In the "Plugins" field a new entry, "Content Update Service", now appears. Here the status of respective data content can be queried, as well as viewing log files and documentation.
Here you can see where the PTV Content Update Service is located within the PTV xServer Management Console:
The following image shows you the PTV Content Update Service administration via the PTV xServer Management Console:
There are two configuration files available for configuring the PTV Content Update Service 1:
The parameters of the general CUS configuration, which can be applied in the content-update.properties files, will be explained below.
The first section of the file contains general settings. The Update Service can be activated or deactivated as a whole, and updates for dynamic Feature Layers and toll can be switched on or off separately.
The appname and user parameters serve statistical purposes. They are sent to the LDS with every request.
All PTV xServer, whose modules should be notified at update, must be configured as notifyServers.<server name>.rootUrl at this point. The server names can be freely selected but must be unique.
Currently the PTV Content Update Service is only available for PTV xMap and PTV xRoute.
All other applications (like monitoring applications) that should be notified at update, must be configured as notifyClients.<client name>.url. The client names can be freely selected but must be unique. (Versions 1.20.0.4 and higher)
Folders can be adapted to store the update files and status information. The other general settings do not usually need to be changed.
content-update.properties (Extract 1: General Configurations)
#------------------------------------------------------- # Content update configuration #------------------------------------------------------- # # Switch to enable/disable content update functionality globally # (Polling and download will be executed only if enabled=true) # # enabled = false # # Switch to enable polling and downloading of dynamic feature layer # featureLayer.enabled = false # # Switch to enable polling and downloading of toll updates # tollUpdate.enabled = false # xServers that should be notified of content updates. # at least one xserver has to be specified # Repeat the following structure (tags in <> have to be replaced with concrete values) # notifyServers.<name1>.rootUrl=<url1> # notifyServers.<name2>.rootUrl=<url2> notifyServers.xroute.rootUrl=http://localhost:50030/xroute # Web clients that should be notified of content updates. # The type of content change is added as parameter layerType to the url. # Possible layerType values are PTV_FeatureLayer, PTV_TollUpdate. # Repeat the following structure (tags in <> have to be replaced with concrete values) # notifyClients.<name1>.url=<url1> # notifyClients.<name2>.url=<url2> #notifyClients.client1.url=http://localhost/clientapp # # The number of old dynamic folders that should be kept. # That means the n last folders will not be deleted by the clean up job, even if they are not used anymore. # This parameter is useful if servers to notify may not be able to update immediately. # #numberOfOldDynamicFoldersToKeep = 0 # # Application name used for statistical purposes in LDS requests # Default value: xServer # #appname=xServer # # User name used for statistical purposes in LDS requests # Default value: unknown # Please provide your company/department name # #user=unknown # # (Absolute or relative) Path to folder for download working directory # (default value = <SERVER_HOME>/work/content-update/tmp) # #downloadFolder = work/content-update/tmp # (Absolute or relative) Path to folder for persistent update status information # (default value = <SERVER_HOME>/data/content-update/status-db) #statusDbFolder = data/content-update/status-db # (Absolute or relative) Path to folder for storing downloaded content # (default value = <SERVER_HOME>/data/content-update/content) #contentFolder = data/content-update/content # Number of parallel threads used for polling and download jobs # (default value = 3) # #processorCorePoolSize=3 # # Watch dog interval for checking restart of xServers # (default value = 2 minutes) # #watchDogInterval=2 minutes
Provided that access to the LDS server(s) is via a HTTP proxy, you can set the corresponding parameters in the proxy section. Basic authentication and NTLM authentication (Windows) is currently supported as proxy authentication.
content-update.properties (Extract 2: Proxy Configuration)
####################################### # # Proxy configuration # ####################################### # # Proxy host and port # #proxy.host = <host> # # Proxy port # #proxy.port = <port> # # User name for proxy authentication # #proxy.user = <user> # # Password name for proxy authentication # #proxy.password = <password> # # Windows domain for proxy authentication with NTLM # #proxy.domain = <domain> # # Local name of the server that is running PTV Content Update Service (only for NTLM authentication) # - the servlet will try to retrieve the name automatically if it is possible #proxy.workstation = <workstation name>
Connection data must be defined for at least one PTV Layer Delivery Server (LDS) using the configuration parameter lds.lds1.serverUrl. This configuration is referenced in the filter definitions for Feature Layer and/or toll updates using the name (which is lds1 in the example configuration).
User and password for authentication on the LDS are specified in the code and preset with a value, i.e. as a rule the lds.<ldsname>.basicauth.user and lds.<ldsname>.basicauth.encryptedPassword do not need to be set. If necessary, the lds.<ldsname>.basicauth.encryptedPassword can be generated with com.ptvag.xserver.plugins.contentupdate.EncryptHelper, which takes the password as sole entry parameter.
If the PTV ContentUpdateService should use the Subscription Mechanism to receive updates, the address of a JMS broker has to be specified with the optional brokerUrl parameter. To do so, it instantiates a JMS MessageListener for every filter, which is notified of changes directly. All protocols that are supported by the deployed ActiveMQ client, and for which a connector to the broker is configured, can be used in principle. If an HTTP proxy has been configured and HTTP is used as protocol for the broker URL, it is also applied for this purpose.
It is recommended to use the Subscription Mechanism only for layers with a low update frequency, such as toll updates. Otherwise the ContentUpdateService generates too much overhead providing the updated data to the xServers.
content-update.properties (Extract 3: Layer Delivery Server Configuration)
####################################### # # LDS server configurations # ####################################### # # Layer Delivery Server (LDS) connection configurations # at least one LDS connection needs to be defined # Repeat following structure (tags in <> have to be replaced with concrete values) ## MANDATORY: url to LDS server #lds.<ldsname>.serverUrl = <name of lds configuration to use> ## OPTIONAL: basic authentication user name (default value is xserver) #lds.<ldsname>.basicauth.user = <user> ## OPTIONAL: encrypted basic authentication password for LDS (default value is provided internally) #lds.<ldsname>.basicauth.encryptedPassword= <encrypted-password> ## OPTIONAL: if proxy configuration should be ignored for this configuration ## default = false #lds.<ldsname>.ignoreProxy= true | false ## OPTIONAL: URL of JMS broker (enables subscription based updates) #lds.<ldsname>.brokerUrl=<proto>://<host>:<port> ## example lds1 #lds.lds1.serverUrl=http://my-lds-server/lds/rest ## example lds2 #lds.lds2.serverUrl=http://another-lds-server/lds/rest #lds.lds2.basicauth.user=ldsclient #lds.lds2.basicauth.encryptedPassword=secret
The PTV xRoute server can obtain toll updates via the CUS. The updated toll data is downloaded and installed in the background. The toll updates installation can be triggered either via the REST method restartAndInstallTollUpdate or configured as an automatic process at regular intervals.
After a toll update, the module must be restarted. It could be that the toll update cannot be installed because a process is accessing the map. In this case the installation will be aborted, rolled back and repeated when appropriate.
Toll updates are always complete, i.e. you only need to import the newest update in order to be up-to-date. In addition it must be ensured that the CUS has access to the map folder.
The following parameters are required to automatically download toll updates:
Other parameters are optional:
content-update.properties (Extract 4: Toll Update Configuration)
####################################### # # Toll update configuration # ####################################### # # LDS server used to receive toll updates # MANDATORY # tollUpdate.lds= # # The product for which the toll updates must have been release. # It is important to set this parameter properly to restrict updates # to quality checked releases! # tollUpdate.publishedForProduct=PTV_xServer # # Map directory # If not set explicitly, the map directory is read from conf/xroute.properties (property maps.path) # #tollUpdate.maps.path= # # Map name used for retrieving toll updates. # MANDATORY # Example: tollUpdate.mapName=PTV_Europe_City_Map_Premium_2013_1aN tollUpdate.mapName= # # Polling interval for toll updates # If not specified, polling interval provided by LDS (meta data value of nextUpdateSuggested) will be used # <number> <timeunit> looks like "20 seconds", "10 minutes", "3 hours" etc. # #tollUpdate.pollingInterval = <numbergt; <timeunit> # # Set schedule for automatic toll update installation # If not set, toll updates must be installed manually via CUS status page or calling the REST interface directly (/restartAndInstallTollUpdate) # #tollUpdate.installationSchedule=0 0 23 * * ? # # Set the number of retries in case of failure to install toll update. # This setting is used together with the initialWaitingPeriodBeforeRetry. # If not set or set to 0 (zero), the failed installation will not be retried. # #tollUpdate.numberOfRetriesOnFailure = 2 # # Set the initial waiting period before the installation of a toll update is tried again in case of failure. # This setting is used together with the numberOfRetriesOnFailure. # If not set, the default value of 30 seconds will be used. # <number> <timeunit> looks like "20 seconds", "10 minutes", "3 hours" etc. # #tollUpdate.initialWaitingPeriodBeforeRetry = <number> <timeunit>
As the installation of the toll updates require a restart of the PTV xRoute Server, the triggering has to be done manually. Therefore you can use the possibilities provided in the PTV xServer Management Console.
On the CUS status page (e.g. http://localhost:50030/zContentUpdateService/pages/contentUpdateStatus.html) is information available about new toll updates ready for installation, the current status, a history and a lot of more. With the buttons on the page you can trigger the polling for toll updates or the installation of toll updates manually.
Alternatively you can directly use the provided REST API (e.g. http://localhost:50030/zContentUpdateService/pages/docu.html). The most important functions are:
Dynamic Feature Layer data such as the Feature Layer theme PTV_TrafficIncidents (available from PTV xServer 1.20.0) can also be delivered via the PTV Content Update Service. Updates are automatically imported while PTV xServer is running and are then immediately active.
When making notifications of Feature Layer updates, the CUS does not currently check if the PTV xServer to be notified is accessible. This must be done separately. After the PTV xServer has been restarted, the latest data will not be used until the next update.
Static Feature Layers, such as Truck Restriction Zones and Truck Attributes, are not currently offered via the CUS. They are available for download in the Customer Area and have to be copied manually into the map.
Traffic Incidents data is not incremental, i.e. updates do not only include new or changed data, but also the complete data record.
In order to receive Feature Layer data via the CUS, the following settings in content-update.properties are required:
featureLayer.enabledAll layer metadata can be applied optionally for defining the query filter. All FeatureLayer filters have an implicit restriction on <layerType>PTV_FeatureLayer</layerType>. The LDS configuration name and the mapCategory must be set. If the pollingInterval is not explicitly set, the value is calculated via the suggestedNextUpdate value from the LDS layer metadata.
The filter parameters mapName, mapVersion and profiles are deprecated and will be ignored.
content-update.properties (Extract 5: Feature Layer Update Configuration)
#######################################
#
# Feature layer update configuration
#
#######################################
#
# (Absolute or relative) Path to folders with dynamic feature layer data (will be updated periodically)
# (default value = <SERVER_HOME>/work/content-update/dyn-flr)
#
#featureLayer.dynamicRootFolder=work/content-update/dyn-flr
#
# filters to use for polling
#
# Repeat following structure (tags in <> have to be replaced with concrete values)
## MANDATORY: reference to lds configuration referenced by <ldsname>
#featureLayer.filters.<filtername>.lds = <ldsname>
## MANDATORY: Consider only feature layers for updates that were created for this map category.
## Valid values are:
## TomTom
## PTV_Africa_City_Map_T
## PTV_Arabia_City_Map_T
## PTV_Asia_City_Map_T
## PTV_Australia_City_Map_T
## PTV_Europe_City_Map_Premium_T
## PTV_North_America_City_Map_T
## HERE
## PTV_Arabia_City_Map_H
## PTV_Australia_City_Map_H
## PTV_Europe_City_Map_Premium_H
## PTV_North_America_City_Map_H
#featureLayer.filters.<filtername>.mapCategory = <mapCategor>
##
## OPTIONAL: Comma separated list of feature layer IDs that should be considered for updates.
## A layer ID has the following format: '<vendor>_<themeId>_<countryCode>_<providerDataVersion>',
for example 'tomtom_ptv_trafficincidents_de_2016.q4'.
## Setting layerIDs only makes sense for very specific use cases or debugging purpose.
#featureLayer.filters.<filtername>.layerIds = <id1>,<id2>,...
## OPTIONAL: Comma separated list of integration units that should be considered for updates.
## This will be used download the data for specific integrationUnits like Germany (deu), Italy (ita),...
#featureLayer.filters.<filtername>.integrationUnits = <iu1>,<iu2>,...
## OPTIONAL: Comma separated list of vendor IDs that should be considered for updates.
## Example: For PTV_TrafficIncidents the vendor is always "tomtom". TomTom data will be used for the maps from TomTom and HERE!
#featureLayer.filters.<filtername>.vendors = <vendor1>,<vendor2>,...
## OPTIONAL: Comma separated list of themes that should be considered for updates.
#featureLayer.filters.<filtername>.themes = <theme1>,<theme2>,...
## OPTIONAL: Comma separated list of profile IDs that should be considered for updates.
#featureLayer.filters.<filtername>.profiles = <profile1>,<profile2>,...
## OPTIONAL: polling interval.
## If not specified, the polling interval will be determined automatically based on data provided
by the LDS (meta data value of nextUpdateSuggested).
## If a brokerUrl is set for LDS the polling interval is not considered
## <number> <timeunit> looks like "20 seconds", "10 minutes", "3 hours" etc.
#featureLayer.filters.<filtername>.pollingInterval = <number> <timeunit>
Copyright © 2024 PTV Logistics GmbH All rights reserved. | Imprint
