PTV Group - Logistics Forum

Hi,

with xRoute1 we use the hazardousGoodsType to define restrictions.
For xRoute2 I didn’t find a detailed documentent. I only found some of the needed properties here: PTV_TruckAttributes
Therefore I tried to map the enum value names from xRoute1 to the hazardousGoodsType of xRoute2.

I tested the following values:
- HAZARDOUS (seems to work)
- HAZARDOUS_TO_WATERS (seems to work)
- COMBUSTIBLES (exception)
- COMBUSTIBLES_HAZARDOUS_TO_WATERS (seems to work)
The routing with hazardousGoodsType = COMBUSTIBLES causes the following exception: The parameter value is invalid because of restrictions in the feature layer.

Which string is the right value to define a restriction of type „COMBUSTIBLES“ in xRoute2?

Regards
Christopher

Hello Christopher,

I guess the documentation of this feature is not complete yet.
Potential values of that property are:

- HAZARDOUS_TO_WATERS
- HAZARDOUS
- EXPLOSIVE
- FLAMMABLE

Best regards,
Bernd

PS: I asked DEV to improve this

Hi Bernd,

I also had this issue with using wrong property names.

I`m using xServer2 and there in the PTV_TruckAttributes properties list they`re named as 'combustibles', 'hazardousGoods', 'hazardousToWaters' and it`s only 3 of them as you can see.

But as seen in the post below 4 are noted: 'HAZARDOUS_TO_WATERS', 'HAZARDOUS', 'EXPLOSIVE', 'FLAMMABLE'.

Obviously the documentation is still not updated (seen by the names and number of properties), or maybe there is some other place there where they`re mentioned?

Regards,
Marko

Ijust spoke to some DEV buddy - he recommends to keep the four potential values in mind:

• HAZARDOUS_TO_WATERS
• HAZARDOUS
• EXPLOSIVE
• FLAMMABLE

There's some built in mechanism in xRuntime2 which is supposed to assist in the automatic gathering of such properties and potential values. Unfortunately the method is experimental and not really dedicated to be used in public:
Please geht back to me 1:1 for further discussion of what further info you need.

Bernd

Hi Bernd,

Thank you, that`s enough for my current needs.

However it is pretty valuable that the correct and full data is represented in the documentation, otherwise developers spend a lot of time struggling with these kind of issues.

It would be appreciated if this is done also for any other properties (if any), so we don`t get into the same situation in future.

Regards,
Marko Arsovski

Hi Marko,

I totally agree with you and forwarded your post to DEV. Unfortunately in this context this is all I can do at the moment.

Bernd