xS1 vs PTV Navigator

This forum deals with any kind of routing computation whether it is simple A:B-routing, calculation of isochrones, simple matrix computation or nearest search.
Post Reply
innomedio
Posts: 24
Joined: Thu Sep 03, 2020 2:26 pm

xS1 vs PTV Navigator

Post by innomedio »

Hi Bernd,

We've asked for route between:
Am Volkspark 9 50321 Brühl
->
Bergerstraße 50321 Bruhl


We've used the attached mg-truck-40t.xml profile.

On pic1.png you can see that there is a truck attribute on Königstrasse, called:
DIR_OPT_COND_MALUS5|0=75

According to this page: https://xtour-eu-n-test.cloud.ptvgroup. ... Format.htm
It means that:
"closed for vehicles heavier than a given weight except for residential vehicles"

It's on pic1:
pic1.png
If we generate a BCR from this route, and open it in PTV Navigator, it knows this attribute, and reroute trough another way:
pic2.jpg
I've two questions:
- why doesn't recognise the xServer xRoute, that Königstrasse is closed for a 40T truck?
- how does exactly BCR with PTV Navigator works? Can we force the navigator to use the exact road we've planned in xS?

Thank you,
Peter
Attachments
mg-truck-40t.xml
(3.38 KiB) Downloaded 259 times
User avatar
Bernd Welter
Site Admin
Posts: 2574
Joined: Mon Apr 14, 2014 10:28 am
Contact:

Re: xS1 vs PTV Navigator

Post by Bernd Welter »

Hello Peter,

I am sorry to bother you but: please provide the complete request, response and also the URL you used.
If you prefer me to handle this 1:1 send it via email.

Bernd
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
User avatar
Bernd Welter
Site Admin
Posts: 2574
Joined: Mon Apr 14, 2014 10:28 am
Contact:

Re: xS1 vs PTV Navigator

Post by Bernd Welter »

One thing I just saw in your profile:

You enabled AdditionalDataRules - you specified the PTV_TruckATtributes but you did not mention the binary truck attributes layer (the one that contains the DIR_OPT_COND_MALUS5|0=75)

Your profile: <AdditionalDataRules enabled="true">
Correct: <AdditionalDataRules enabled="true" layerName="TruckAttributes">

Please ensure to use the same set of layers in the mapping and the routing context.
Maybe this already explains the case.

About the Navigator question: is it possible to force a navigation to use the route created by xServer?
This topic is called "guided navigation" and requires you to create a BCR file. The process is desribed in https://xserver.ptvgroup.com/forum/view ... f=49&t=449 but we would need Sebastian to handle this. Afaik there's no guarantee that such a process does never leave the precomputed track. It simply makes the segments of that track cheaper but once the driver has left the "gravity" of the core route it can happen that the navigator recomputes the track.
Let's split the two topics.

Bernd
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
Joost
Posts: 307
Joined: Fri Apr 25, 2014 1:46 pm

Re: xS1 vs PTV Navigator

Post by Joost »

A quick warning though:

The truck attributes feature layer are loaded in your vehicle profile. So atm you are using "RoadEditor" technology in xMap and "FeatureLayer" technology in xRoute. Although both data layers are using the same source data and should represent the same use case, the way some specific blockings are handled is different in both technologies.

I would highly recommend you stick to a single technology choise in both xServers.
Joost Claessen
Senior Technical Consultant
PTV Benelux
SebastianSchlichting
Posts: 18
Joined: Tue May 28, 2019 10:45 am

Re: xS1 vs PTV Navigator

Post by SebastianSchlichting »

Hi Peter,

from Navigator side you have two options:

Enabling forgettweakloryrestricions and setting this tu true. This will ignore soft restrictions in the Navigator map and trying to follow the route the best way it is provided in the BCR. For more details please have a look in the attached PDF.

The second option is to provide a car profile in the BCR that only is considered for the BCR.

apart from that I've attached a document that gives more insights about GuidedNavigation.

BR
Sebastian Schlichting
Attachments
Userguide_GuidedNavigation_2021.pdf
(2.95 MiB) Downloaded 268 times
innomedio
Posts: 24
Joined: Thu Sep 03, 2020 2:26 pm

Re: xS1 vs PTV Navigator

Post by innomedio »

Hi Everyone!

Thank you for all the answers.

@Bernd:
Your profile: <AdditionalDataRules enabled="true">
Correct: <AdditionalDataRules enabled="true" layerName="TruckAttributes">
This solved the problem!
I'd like to learn more about the layers. We've always thought that enabling a the AdditionalDataRules and including the <Theme id="PTV_TruckAttributes" enabled="true"/> is enough.
Is there a detailed documentation somewhere about using the layers/datarules?

@Joost:
I'm not sure I fully understand what you wrote. But I'm guessing it's connected to the one I just wrote to Bernd.
It's connected to Themes vs DataRules?

@Sebatian:
Thank you for the bcr documentation. We'll go through it again with my collegues!
We'll also try out the forgettweakloryrestricions the setting.
I'll get back to you with the results!

Best regards,
Peter
innomedio
Posts: 24
Joined: Thu Sep 03, 2020 2:26 pm

Re: xS1 vs PTV Navigator

Post by innomedio »

Hi Sebastian,

I've read in the 6. point of the documentation, that there is a free tool for visualizing BCR, called Tilerouting.
Could you send me a link, where I can find it?

Thank you,
Peter
Joost
Posts: 307
Joined: Fri Apr 25, 2014 1:46 pm

Re: xS1 vs PTV Navigator

Post by Joost »

@Joost:
I'm not sure I fully understand what you wrote. But I'm guessing it's connected to the one I just wrote to Bernd.
It's connected to Themes vs DataRules?
When we started with our software we just took the cor map data from our provider and made our maps from it. As time passed our map providers collect more and different forms of data and they introduce a separate data set we are now calling Truck attributes. So we needed a technology to add this separate dataset to the map and the Road editor technology was created.

As time passed by more and more data became available and our RoadEditor technology was no longer good enough to deal with all of that so we created a new technology for adding data to a core map: FeatureLayer. It has several advantages of RoadEditor. To name some:
* It scale better so we can deal with larger data sets
* It is more flexible under the hood so it is easier for PTV to intro duce different kind of data
* it has support for time dependency on data
* multiple layers can be loaded in

A good example of this is our speed patterns layer for calculating realistic travel time based on historic traffic information. The data set is way to big for RoadEditor, we are not using blocking but speed and delay properties and data is time dependent.

To come back to the set this topic started with: Truck Attributes. For this particular use case Roadeditor mostly holds up as a good technology. Although it misses time dependency the data set is not so big that is doesn't fit and we have mostly all the properties we need. Since we had many customers use Roadeditor we kept making these layers since it was already part of our process chain and it save customers from extra work on switching while there is for them not that much of a benefit. So currently we see the road editor data as technically deprecated but we do still support customers using this. For our newer technology stacks like xServer 2 RoadEditor is not included. So right now our xServer 1 customers can make use of both technology, although we recommend using the feature layer technology.

Like i wrote before, the data is not exactly the same. For "simpel" blockings like for example "Max Heigth" it does work exactly the same. But for more complex blockings like "Max weight with exception for local acces" there is a difference. In Roadeditor there was not a good property for this but we did have some extra reserved properties for future use so we took one of those. That why the name is road editor (DIR_OPT_COND_MALUS5) is not self explanatory and you have to check the documentation to know exactly what this is. For feature layer this is different so we can simply make it a blocking with a max weigth and a delivery exception.

With this all there is also a difference in configuration of the vehicle profile. Feature layers are loaded via the Profile
/FeatureLayer / Themes[] , road editor is load via the Profile / Routing / Course / AdditionalDataRules / @layerName . The finer details of the blocking in question is configured via a Profile / Routing / Course / AdditionalDataRules / Legacy / KeyValue setting, where the feature layer just looks at the more general settings. Note: normally you do not need to configure the finer settings, that is only needed in exceptional cases.

In your original question you uses a screen where xMap is using RoadEditor technology and you referred to the documentation that deals with RoadEditor technology in xRoute. So Bernd answer "load in the RoadEditor technology layer" makes sense. My point is that in that case you should disable the feature layer (remove the truck attributes them from your profile) . Using to technologies for the same can can sometime lead to unforeseen issues when configurations contradict.

There is one thing remaining: your original question "why doesn't recognise the xServer xRoute, that Königstrasse is closed for a 40T truck?" , after spending a bit more time then I car to admit i found the answer: The blocking is directional, as in only valid for one direction. So xRoute simply take the the road in the the direction the blocking is not valid for.
Joost Claessen
Senior Technical Consultant
PTV Benelux
User avatar
Bernd Welter
Site Admin
Posts: 2574
Joined: Mon Apr 14, 2014 10:28 am
Contact:

Re: xS1 vs PTV Navigator

Post by Bernd Welter »

Hi Joost,

thanks for the detailed response! Let me add some small remarks - just to round up the picture:
  • Legacy versus FeatureLayer: the FeatureLayer concept was defined to replace different old approaches:
    • Historical information aka "Ganglinien" was replaced by FL PTV_SpeedPatterns and PTV_TruckSpeedPatterns
    • Live Traffic aka "Traffic Info Loader" was replaced by PTV_TrafficIncidents (in combination with Content Update Service)
    • Legal restrictions aka "TruckAttributes" (binary Road Editor Layers) have been replaced by PTV_TruckAttributes
    We did this to get rid of the old technologies which have sometimes caused troubles / interferences when users tried to combine them in single requests.
  • Time dependency: One big benefit of FL technology is the availability of time dependent information. This enables us to define blockings such as the traffic incidents. And this also comes into usage for time dependent truck attributes such as "blocked for trucks during the night". An old school binary truck attribute just stored the attribute but not the validity period. So for some segments which have time dependency in real life our data team was forced to decide between YES (but then it appeared in the binary data as a static blocking) and NO (then it didn't appear in the binary data). So with this time dependency properties in the feature layers we closed an important gap.
  • Direction dependency: As Joost mentioned: some blockings could have a restriction which applies in a single direction. For that we need a closer look at the attribute: DIR_OPT_COND_MALUS5|2=75 means that the weight restriction refers to a specific direction
    • 0 - in reverse storage direction (aka opposite direction)
    • 1 - in storage direction (aka deposite direction)
    • 2 - there is no information about the direction
    Important: in the context of "visualizing the built in attributes" there's no driving direction - therefore the statement refers to "how the data is stored in the database (storage direction)". As users usually don't have information about the storage direction I guess the relevance of the attribute turns to "both directions" versus "single direction" without knowing which one.
Best regards,
Bernd
Attachments
Oldschool binary TruckAttributes on current TOMTOM map (XSI)
Oldschool binary TruckAttributes on current TOMTOM map (XSI)
FeatureLayer PTV_TruckAttributes on current TOMTOM map (XSI)
FeatureLayer PTV_TruckAttributes on current TOMTOM map (XSI)
Oldschool binary TruckAttributes on current HERE map (XSI)
Oldschool binary TruckAttributes on current HERE map (XSI)
FeatureLayer PTV_TruckAttributes on current HERE map (XSI)
FeatureLayer PTV_TruckAttributes on current HERE map (XSI)
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
SebastianSchlichting
Posts: 18
Joined: Tue May 28, 2019 10:45 am

Re: xS1 vs PTV Navigator

Post by SebastianSchlichting »

The tool Tilerouting can be found here:
https://ptv2box.ptvgroup.com/index.php/ ... McdX66TSsX
(the PW is your mail address)

In the first step, please set the path for the map in the ini file.

The map data you can obtain from the android device. Please copy all map data that you find on the mobile device in the app folder /files/downloads/ that start with map_* into one folder on your computer. you need to extract all single files into one folder!


Tilerouting is an internal tool, so we can not provide support for that.

How to open a bcr file: right click "load bcr file". select the stations to visualize and tap z to zoom to the opened bcr file. you will see them as a red x with ---- that shows the heading of the mvps.
tilerouting.png
tilerouting2.png
Post Reply