Add currentFuelPercent and currentRangeMeters to RentalVehichle in the GTFS GraphQL API

[JustCris654]

Summary

Add currentFuelPercent and currentRangeMeters fields to RentalVehicle in the graphql GTFS API

Issue

issue

I added currentRangeMeters on top of the issue because it is related

Unit tests

Write a few words on how the new code is tested.

• Graphql integration test have been modified to test this fields
• I tested the query with the graphiql frontend
• Do all tests
  pass the continuous integration service
  ? Yes

Documentation

• I wrote the proper doc comments in the graphql schema

[codecov]

Codecov Report

Attention: Patch coverage is 66.01942% with 35 lines in your changes missing coverage. Please review.

Project coverage is 69.72%. Comparing base (5ab75af) to head (c00e615).

Files with missing lines	Patch %	Lines
.../opentripplanner/transit/model/basic/Distance.java	56.66%	10 Missing and 3 partials ⚠️
...org/opentripplanner/transit/model/basic/Ratio.java	55.00%	8 Missing and 1 partial ⚠️
...ental/datasources/GbfsFreeVehicleStatusMapper.java	63.63%	7 Missing and 1 partial ⚠️
...pentripplanner/gtfs/mapping/FareLegRuleMapper.java	63.63%	4 Missing ⚠️
.../apis/transmodel/model/stop/RentalVehicleType.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6272      +/-   ##
=============================================
- Coverage      69.73%   69.72%   -0.01%     
- Complexity     18023    18053      +30     
=============================================
  Files           2057     2060       +3     
  Lines          76978    77065      +87     
  Branches        7845     7849       +4     
=============================================
+ Hits           53678    53736      +58     
- Misses         20550    20577      +27     
- Partials        2750     2752       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[optionsome]

Does the library we use validate that the fuel percent is between 0 and 1 or should we do it?

[JustCris654]

Does the library we use validate that the fuel percent is between 0 and 1 or should we do it?

The library validate if the value is between 0 and 1 in output (when generating the graphql response).
It returns an error like this:

{
  "errors": [
    {
      "message": "Can't serialize value (/rentalVehicles[0]/currentFuelPercent) : Value is under 0 or greater than 1.",
      "path": [
        "rentalVehicles",
        0,
        "currentFuelPercent"
      ],
      "extensions": {
        "classification": "DataFetchingException"
      }
    }
  ],
  "data": {
    "rentalVehicles": [
      {
        "name": "Ninebot A200",
        "lat": 43.772581,
        "lon": 13.132542,
        "currentFuelPercent": null
      }
    ]
  }
}

The value is not checked when received in the gbfs mapper, do we need to check it also there? I saw that in the RatioScalarTest.java has this

    var ratio = (Double) GraphQLScalars.RATIO_SCALAR.getCoercing().parseValue(HALF);

to parse a value.

[optionsome]

The value is not checked when received in the gbfs mapper, do we need to check it also there?

I would prefer to log some warning and ignore the value in the mapper instead of letting it be cause issues in the APIs.

[optionsome]

@testower do you know if there is some general policy in the GBFS java library for validating values (such as not allowing over 100% fuel percent or negative range meters)?

[testower]

@testower do you know if there is some general policy in the GBFS java library for validating values (such as not allowing over 100% fuel percent or negative range meters)?

The java model used in otp does not have validation annotations, so anything that can be deserialized is accepted.

[optionsome]

The java model used in otp does not have validation annotations, so anything that can be deserialized is accepted.

Is there an option to use validation annotations? I'm just wondering should we discuss the possibility in tomorrow's dev meeting, for example?

[testower]

Not with the current library. It is left out with intention. I don't think validation should be handled in the deserialization step anyway. This is runtime code / hot code path, so I think OTP should validate the data it needs to in the business layer.

[testower]

I should probably add some reasoning: I don't think it's desirable to reject the deserialization of a whole file update, because some particular piece of data in that update doesn't validate according to the validation annotations. The data may still be perfectly usable by OTP.

[leonardehrenfried]

You need to resolve merge conflicts.

[JustCris654]

I added this check, can you double check if it's right?
I'm not sure but vehicle_type_id is REQUIRED if the vehicle_types.json file is defined, that file is REQUIRED for systems with free_bike_status.json and if this file is not included then all vehicles are non motorized bicycles.
Therefore if the vehicleTypeId is not present in the vehicleTypes map I can assume that the file vehicle_types.json is not present and all vehicles are not motorized, so the propulsion type is human and range is not needed.

[optionsome]

I think this is correct, but this is in an area where a lot of feeds get things wrong so this validation might cause issues but I'm not sure if I'm against this or not.

[leonardehrenfried]

I spoke to @hbruch about this and he said that there are a number of feeds that don't include it where they should but he is in favour of enforcing the spec anyway. If we are not strict with data producers, they will never learn.

[optionsome]

I think this is correct, but this is in an area where a lot of feeds get things wrong so this validation might cause issues but I'm not sure if I'm against this or not.

[t2gran]

I looked the Ratio implementation and how to provide a factory method witch handles validation errors. As mentioned in the dev-meeting today, my first attempt was to use a Result object - this was rather ugly and did not increase the readability or lowered the complexity(maintenance cost). So, after a bit of refactoring I went for a solution witch uses an error-handler and return an Optional - this was easy to implement and looks good on the caller side.

Please merge in these changes:

https://github.com/opentripplanner/OpenTripPlanner/tree/pr-6272

or cherry-pick commits:

• 62e671f
• f7d6b36

The the two commits in the branch above fixes ALL my suggestions below, but I wanted to leave the comments so you can understand why I changed the code.

[t2gran]

@testower do you know if there is some general policy in the GBFS java library for validating values (such as not allowing over 100% fuel percent or negative range meters)?

The java model used in otp does not have validation annotations, so anything that can be deserialized is accepted.

Just to be clear - We do not want "insane" values in OTP. The DTOs used to import can accept it, but not the core OTP model. In general there is two categories of data:

• pass-through data, witch we can be a bit loose on the validation and let the consumer take action (OTP API clients).
• data used by the business logic in OTP - where we do validate more strict to avoid complex logic in OTP. This category also include fields we currently does not use, but we are likely to use in a planning request in the future. This apply to fuelRatio.

[JustCris654]

Thank you very much @t2gran for your help, now the Ratio class is more clean and I like it.

[optionsome]

Since we are always rounding this to int, should we just do the rounding when reading in the value and store it as int in this class since it requires less space? Do we have a need for less than meter precision from this class later?

[JustCris654]

You're right, we don't need more precision than int. The reason I chose to use a Double was that the GBFS standard uses a float for it.

[optionsome]

@t2gran suggested we should store the distance as millimeter integer. You can then convert it to int meters in this method.

[JustCris654]

In this case aren't more suited centimeters or decimeters? I don't think we need a millimeter of precision.
With centimeter we could represent more kilometers (21.000 against 2.100) with integer and we would still have enough precision.