@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.