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 65.00000% with 35 lines in your changes missing coverage. Please review.

Project coverage is 69.77%. Comparing base (5ab75af) to head (0185022).
Report is 115 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
.../opentripplanner/transit/model/basic/Distance.java	58.06%	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.77%   +0.03%     
- Complexity     18023    18081      +58     
=============================================
  Files           2057     2063       +6     
  Lines          76978    77206     +228     
  Branches        7845     7860      +15     
=============================================
+ Hits           53678    53867     +189     
- Misses         20550    20584      +34     
- Partials        2750     2755       +5     

☔ 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.

[JustCris654]

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

[leonardehrenfried]

Just a few naming conventions and visibility. This is very close to being merged.

[leonardehrenfried]

@optionsome @t2gran Did we decide that we will live with the consequences of GBFS feeds ignoring the spec by not setting ranged_meters?

[JustCris654]

@optionsome @t2gran Did we decide that we will live with the consequences of GBFS feeds ignoring the spec by not setting ranged_meters?

Are you talking about current_range_meters? I left the check there, so now if a vehicle is not compliant by not having the range set when it's required it will be ignored. I understood that we want to enforce this from this message.

[leonardehrenfried]

I would like to enforce it but @t2gran said he wants to find out if that is ok for Entur.