Configuring custom pricing plans should be documented

[hbruch]

Lamassu supports the cofiguration of custom pricing plans.

How to do this (an example is provided in this PR), and when this would be useful, should be documented.

I.e. it is unclear to me, if it is used to overwrite/redefine existing pricing information, e.g. because they are outdated, should be better described etc., or if it is also possible to augment feeds which don't provide pricing plans at all. In this case: are vehicle_types augmented by default pricing plans (which one then) or should the be redefined in the config also? Do these defined vehicle types overwrite the original vehicle_types info or are they merged in some way?

[testower]

I added support for providing vehicle types and pricing plans via the configuration as an escape hatch to deal with low quality data feeds at the early beginning of this project. I actually never intended for it to be a permanent feature, so perhaps hence the lack of clarity / documentation on it. I agree that if we intend to keep it, it should be documented properly.

As you'll see in the feed mappers:

https://github.com/entur/lamassu/blob/master/src/main/java/org/entur/lamassu/mapper/feedmapper/VehicleTypesFeedMapper.java#L44

and

https://github.com/entur/lamassu/blob/master/src/main/java/org/entur/lamassu/mapper/feedmapper/SystemPricingPlansFeedMapper.java#L47

if these are provided in the configuration for that system, any existing feed data will be completely replaced, both in the gbfs endpoints and in the aggregated graphql api. So there is no attempt to merge with existing data.

In this case: are vehicle_types augmented by default pricing plans (which one then) or should the be redefined in the config also?

Not automatically, no. But you can of course define it yourself. So to use your own example (trimmed down a bit):

lamassu:
  providers:
    - systemId: lime_zu
      operatorId: LME:Operator:lime
      operatorName: Lime
      codespace: DKY
      url: "https://data.lime.bike/api/partners/v2/gbfs/zug/gbfs.json"
      language: en
      vehicleTypes:
        - vehicleTypeId: TestVehicleType
           defaultPricingPlanId: TestPlan
           ....
      pricingPlans:
        - planId: TestPlan
          name: TestPlan
          ...

[hbruch]

Ok, and in case vehicle types are defined in config, free bikes are assigned the first vehicle type so this would work for single vehicle type systems, right?

Would be interesting to know, how many feeds in systems.csv have no vehicle types defined. Depending on that, we could decide about documentation/removal. It could be versatile in some use cases, as it's a very light weight way to fix incomplete feeds.

[testower]

Ok, and in case vehicle types are defined in config, free bikes are assigned the first vehicle type so this would work for single vehicle type systems, right?

Correct!

The problem for me is that it is manual work. Especially for pricing, which tends to be very dynamic at least around here, it very quickly becomes outdated. But I won't object to making it an "official" feature if you need it :)