PTV Group - Logistics Forum

Hello,
i have a few questions about installing/keeping the (old) road editor database when updating
to a new map.

I use the RoadEditor of Map&Guide Desktop to block streets or change existing TruckAttributes.
With the export function of Map&Guide I have created a binary layer file which contains the common
TruckAttributes of the map and also my custom changes.
I replaced the standard TruckAttributes layer file in the map (e.g. TruckAttributes_EUR_2015_2H.bin) with the exported
one. Now the map shows my custom changes and the standard TruckAttributes.

Questions:

1. This process of importing custom changes into the map is not optimal.
When installing a new map, there is a new set of TruckAttributes. So I can´t simply copy and
override it with the old one, without loosing the updated TruckAttributes.
Is there a better way to import custom changes without loosing information?

2. Do you know any concerns or version conflicts using an old RoadEditor binary layer file and new maps?

3. Do you know any concerns or conflicts using an old Map & Guide version and new maps (for route editing) or do I need a new version on every map update?

I appreciate your help.

Thanks and best regards
Jan

The roadeditor binary layers are always dependent on a specific map release. If you would use a road editor layer on another map release the blockings will be assigned at random near the original blocking. Some will end up on the correct segment, some will not.

Map and guide does have an option to import blockings from a different map release. It will match most of the blockings automatically to the new map and will let you re-assign blockings it cannot match automatically. The later happens when the geography has a significant change (for example new road has been added to the map). For more information you can check the map and guide manual (menu Help -> User guide PDF) chapter 10.8 "Importing road statuses".

Thank you for your feedback.

I understand it as follows:
On every map update it is necessary to import the
roadeditor binary layer of the old map with Map and Guide, correct the blockings (automatically/manually)
and create a new one.

But in my case I export my custom blockings with the standard TruckAttributes of the map.
I think this is suboptimal because when importing and creating a new layer file
I don't want to have the old TruckAttributes in the new map.
I know that it is possible to export only my custom blockings into a new binary layer file.
But how to ensure that XServer finds and loads it automatically?

Could I ask you again about point three of my previous post?

Thanks
Jan

Map and guide stores the blockings in separate database for editing purposes. Usually this is the roadeditor.mdb file in the map directory. If you import blockings map and guide will read from this database, not your binary export. For the rest the process goes as you described.

You will only import the blockings you created. When exporting you can choose again to merge your blockings with the truck attributes that are available for that specific map.

To get back to point 3: map and guide prefers to work with maps from the same release year. Newer maps may require a new version of map and guide. Officially we only support map and guide in combination with maps from the same year since we can't guarantee that newer maps will work for map and guide.

Hello Joost,
thank you for explaining the processs. I think I've got it now.

Hello together,

just a few generic comments from my side:

• First o fall THANKS to Joost for describing those mechanisma!
• About the user data update: as Joost mentioned MAP&GUIDE stores the user specific data in a database (MS Access or MS SQL Server). With the 32bit version of the xRoute server it is possible to connect xRoute to the database so whenever the administrator applies his changes in MAP&GUIDE this will immediately affect the next routings (if they use the database layer.DB). Furthermore this approach enables you to consider time dependent attributes. If your environment is able to grant access to such an architecture: CONGRATS...
• The annual map update is more tricky because object IDs might change within the map. Within the map update MAP&GUIDE offers to match old attributes to new ones but this isn't a perfect solution.
• So the thread covers two topics (user data update versus map update) and in fact we know that the traditional RoadEditor has it's disadvantages we will resolve in the future based on the feature layer.

I think the RoadEditor is an interesting feature even with it's limitations. Do not hesitate to get back to us if you need more info.

Best regards,
Bernd

Hey there,

In case the the RoadEditor (of Map&Guide Desktop) is used to block streets or change existing TruckAttributes > will the "High-Performance Routing" be disabled?

Thanks in advance; I hope you all are doing well.

Best regards
Max

Hello Max,

the usage of TruckAttributes within a HPR-based routing is possible under certain circumstances:

• The truck attributes have to be applied during the pre-processing phase
• In my perception the searchgraph is reflecting a specific network snapshot
• Routing means to determine the costs of segments and find a sequence of segments which connect start and destination and minimizes the price.
• Without HPR the price of the segments is determined at routing execution time (which enables you to change options because they will be applied and then the costs are computed).
• With high performance routing the costs are determined at pre-processing time. This is consuming performance but the result cost data is then available without being computed at runtime. One reason why HPR is so fast.

As you can see there's no conflict between (static) TruckAttributes and HPR.

Best regards,
Bernd

PS: TruckAttributes based on RoadEditor are 100% xServer1.
xServer2 will not use Binary Files and Road Editor at all.
It will use FeatureLayer instead!

Hello Bernd,

thanks for your quick response.

That sounds good, seems like the RoadEditor is an interesting/useful tool!

Best regards
Max

as mentioned above: in xServer1 it is.
In xServer2 you will have to evaluate the succeeding architecture