Closed bmeesters closed 1 year ago
From what I could tell after the discussions we had we want to solve it (in typical Dutch fashion, the 'polder model') by using a little bit of both. Some constraints are worth it to keep as is and others are too similar to keep. The new proposal is:
andConstraint
, orConstraint
and notConstraint
to compose different constraints.timeWindowConstraint
, since this is the only constraint that allows for time ranges.routeConstraint
, since this is the only constraint that need route values.genericConstraint
as a wild card.valueBoundConstraint
to model speed, temperature, weight, height, length min and max values.sizeConstraint
since it can be replaced by the valueBoundConstraint
.speedconstraint
since it can be replaced by the valueBoundConstraint
.weightConstraint
since it can be replaced by the valueBoundConstraint
.temperatureConstraint
since it can be replaced by the valueBoundConstraint
.Though I am unsure if there was any clear conclusion regarding:
propertyTypeConstraint
for currently unsupported requests like forklift, tailgate, ADR license.valueTypeConstraint
to model multiple similar constraints like emissionTypeConstraint
and unify constraints like vehicleType
& transportEquipmentType
(and thus deprecate those).We have talked about this many times now and came to the conclusion that we want to start with the simplest change as described in the conclusion above, which is replacing a few sub-constraints that are very similar with the valueBoundConstraint
. Others are currently not in scope.
This is now part of OTM5.5
Introduction
In the past few releases we see more and more requests for new constraint types. As a result, the list of constraint types gets quite big and can get overwhelming for parties just starting out with OTM5. We had a few discussions about this and came to the conclusion that there are two paths forward.
Example
To help decide what would be the best way forward we looked at a more advanced use case and see how both approaches would evolve with the following constraints.
Current approach with constraint for each sub type
This is the original Constraint as defined in https://otm5.opentripmodel.org/#tag/Constraint but extended with some new constraint types (ForkLift to indicate the unloading location needs one to unload the locations, DriverLicense ADR to indicate the driver needs to be in possession of this license to able to operate the vehicle, Tailgate to indicate the vehicle used needs a tailgate to load/unload the goods) to fit the example. The upside of this approach is that it is easier to clearly document each new constraint and the type of values that are allowed. The downside is that the amount of constraints grows rapidly and it becomes hard to see the 'forest' through the trees.
Combined constraints
This is a modified constraint type that supports:
Most notably this means a few new constraint types:
But it would also mean we can delete
sizeConstraint
weightConstraint
speedConstraint
sensorValueConstraint
temperatureConstraint
vehicleTypeConstraint
transportEquipmentConstraint
fuelTypeConstraint
And would support the earlier requested
emissionTypeConstraint
.