Skip to content

Trip search API with include overlapping trips finds an extra record #130

@joakimnordling

Description

@joakimnordling

Note: This might be either a problem in this python library or a problem in the Geotab API. I've not conducted deep enough investigation of the internals of this library or tested raw queries to the API to be sure which one it is. I do however suspect it might be a problem with the API and not just this library.

It looks like when you set the includeOverlappedTrips to True, and use a device search it for some reason also finds a trip that has an ID that matched the ID of the device, although the start and end time of that Trip is far outside the requested ones.

This has been tested against a demo database that I got created when I signed up to Geotab.

Let's examine this simple python script, using the library:

from datetime import datetime

import mygeotab


def main():
    client = mygeotab.API(
        username=...,
        password=...,
        database=...,
    )
    client.authenticate()

    trips = client.get(
        "Trip",
        search={
            "deviceSearch": {"id": "b1"},
            "fromDate": datetime.fromisoformat("2025-07-21T00:00:00Z"),
            "toDate": datetime.fromisoformat("2025-07-21T00:35:00Z"),
            "includeOverlappedTrips": True,
        },
    )
    for t in trips:
        print(
            f"Trip ID: {t['id']}, start: {t['start'].isoformat()}, stop: {t['stop'].isoformat()}, nextTripStart: {t['nextTripStart'].isoformat()}"
        )


if __name__ == "__main__":
    main()

With includeOverlappedTrips set to True it prints this:

Trip ID: b1, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:08:40.328000+00:00
Trip ID: bD8, start: 2025-07-20T23:55:02+00:00, stop: 2025-07-21T00:03:21+00:00, nextTripStart: 2025-07-21T00:03:22+00:00
Trip ID: bD9, start: 2025-07-21T00:03:22+00:00, stop: 2025-07-21T00:20:36+00:00, nextTripStart: 2025-07-21T00:31:39+00:00
Trip ID: bDA, start: 2025-07-21T00:31:39+00:00, stop: 2025-07-21T00:54:03+00:00, nextTripStart: 2025-07-21T01:04:32+00:00

As you can see it for some reason believes the trip with id b1 (first row) should be included in the returned data, although the start/stop/nextTripStart date are all less than the fromDate I've specified. It looks like the id from the deviceSearch somehow ends up as an extra ID for a trip to include in the response.

Actually, if I change the id in the deviceSearch to b2, b3 or b4 I instead get a trip with that ID as the first one in the response:

# b2
Trip ID: b2, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:12:05.910000+00:00
Trip ID: b43A, start: 2025-07-20T23:36:28+00:00, stop: 2025-07-21T00:01:50+00:00, nextTripStart: 2025-07-21T00:12:00+00:00
Trip ID: b43B, start: 2025-07-21T00:12:00+00:00, stop: 2025-07-21T00:20:19+00:00, nextTripStart: 2025-07-21T00:20:20+00:00
Trip ID: b43C, start: 2025-07-21T00:20:20+00:00, stop: 2025-07-21T00:37:34+00:00, nextTripStart: 2025-07-21T00:48:37+00:00
# b3
Trip ID: b3, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:15:02.719000+00:00
Trip ID: b14E6, start: 2025-07-20T23:53:26+00:00, stop: 2025-07-21T00:18:48+00:00, nextTripStart: 2025-07-21T00:28:58+00:00
Trip ID: b14E7, start: 2025-07-21T00:28:58+00:00, stop: 2025-07-21T00:37:17+00:00, nextTripStart: 2025-07-21T00:37:18+00:00
# b4
Trip ID: b4, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:15:25.334000+00:00
Trip ID: b10B8, start: 2025-07-20T23:43:47+00:00, stop: 2025-07-21T00:04:06+00:00, nextTripStart: 2025-07-21T00:10:24+00:00
Trip ID: b10B9, start: 2025-07-21T00:10:24+00:00, stop: 2025-07-21T00:35:46+00:00, nextTripStart: 2025-07-21T00:45:56+00:00

If I change the includeOverlappedTrips to False, then there is no Trip with an ID matching the ID of the requested device. So the problem seems to occur only when the includeOverlappedTrips is enabled.

It is of course easy to filter out the extra item in our own code, but a bit sad the client is returning stuff that needs extra filtering out of unwanted data.

If anyone from Geotab side wants to check the database it's my demo databse demo_jockes_longdistance_passenger that has been used and it was generated automatically when I signed up. I think it will be deleted automatically by your system in something like 60 days minus 1-2 weeks from now.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions