Add emissionStandardConstraint

[ptv-jcl]

Type of request

• [X] I'd like to add something to the OTM 5 spec
• [ ] I'd like to change something in the OTM 5 spec

Is your feature request related to a problem? For environmental zones emissionStandard are decisive for allowing acces. Currently there is no clear way of defining this and in practice I'm see the usage of fuelTypeContraint with free form text which is not future proof. For example for zero emission zones you now have to define every conceivable fuel type / emmisionStandard to block.

Describe the solution you'd like Addition of a emissionStandardConstraint. I would use the weight constraint as an blue print for this.

Describe alternatives you've considered

Additional context

[bmeesters]

Seems like a logical addition. I do not see any reason to not include. I will discuss it with SUTC to see whether they have any feedback.

[bmeesters]

After discussion with SUTC we agree this is a useful addition. However we would like to get more information on how you would actually provide this information in the constraint? Maybe a pseudo json example could help, as well as the options you would like to see.

Another thing we discussed whether it makes sense to use a more generic 'vehicleConstraint' with different fields. Instead of having 5 constraints for vehicle size, type, fuel, and also emissionZones it might make it easier to have one constraints with multiple optional fields. Any thoughts on this @ptv-jcl?

[bmeesters]

@ptv-jcl could you give a little more insight in how you exactly envision this? And what your thoughts are about a more generic constraint with multiple fields.

[ptv-jcl]

I gave it some thought and i would suggest keep to keep it simpel to a minimum standard constraint. I don't see use cases for having a maximum constraint. So a single class with a type property and a emission standard would do IMO.

A full example how i would use this to model an environmental zone that forbid struct that run on diesel and have a emmision norm of 5 or lower:

{
  "or": [
    {
      "not":
      {
        "fuelTypes": ["DIESEL"],
        "type": "fuelTypeConstraint"
      },
      "type": "notConstraint"
    },
    {
      "type": "minimumEmmissionConstraint",
      "emissionStandard": "euro6"
    },
    {
      "maximum":
      {
        "unit": "kg",
        "value": 3500.0
      },
      "minimum": null,
      "type": "weightConstraint",
      "weightConstraintType": "maximum"
    }
  ],
  "type": "orConstraint"
}

As for the single vehicle constraint: I don't like it since the model itself will not make it clear if those attributes are AND-ed or OR-ed so to speak. This would only become clear from documentation. I think this will be a easy pitfall for developers who start working with the model to make mistakes in.

[bmeesters]

Thanks for the elaborate response. My original reasoning for using a combined constraint is because it is likely easier for parties to use. Using AND and OR is very powerful, but the feedback has been that not all parties know how to deal with it. For example, I doubt many parties would be able to automatically process the message you just described. That said, it is already OTM and currently the only way to make such constraints, so lets leave it at that for now. Whether or not combined constraints should be added is another discussion. In any case, thanks for your opinion regarding this.

I think the minimumEmmissionConstraint seems like a valuable addition. Though I suppose we probably want to enumerate the possibilities to avoid parties using differnt names for the same thing.

[ptv-jcl]

There is already an Enum for emissions standard in OTM. The vehicle entity is using that. My idea was to stick to that enum.

[bmeesters]

You are completely right, I forgot that.

[bmeesters]

So I spoke with @woutvandenheuvel and @menno@lambooylogistiek.nl and we see the need for such a constraint, though we are not fond of adding too many constraint types. And as said, the various combinator (and, or not) constraints are generally perceived as complex.

That said, we do not know yet what would be the best course of action. Less constraints (like a more generic vehicle constraint) would be preferable, but they lack modeling power. @woutvandenheuvel indicated that he is going to organize a meeting with people using OTM5 and how they see further improvements to constraints. It would be great if you could join @ptv-jcl.

[bmeesters]

This can make it in if the proposal of https://github.com/opentripmodel/otm5-change-requests/issues/61 is accepted.

[bmeesters]

After the discussion in 61 we trim down on constraints, but have no proper way to communicate this type. So it makes sense to add it. I will add it to the 5.5 candidates.

[bmeesters]

This is now part of OTM5.5