Sean Barbeau comments

Results 1063 comments of


                                            Sean Barbeau

Tests fail on Apple Mac when building the project from command line

What stack trace are you seeing now? The one you previously saw in https://github.com/MobilityData/gtfs-realtime-validator/issues/102#issuecomment-1061228907, or the one Lionel saw in https://github.com/MobilityData/gtfs-realtime-validator/issues/102#issuecomment-1048207734?

Tests fail on Apple Mac when building the project from command line

Can you share the surefire-reports for the webapp project? The one you linked only has the test results for the `lib` project. From the above screenshot this should be in...

Support a production database for running as a hosted web server instance

As mentioned in https://github.com/MobilityData/gtfs-realtime-validator/issues/88, there has been some work in that issue and referenced PR towards compatibility with Microsoft SQL Server. Alternate production DBMS could also be investigated.

Check that there is at most one TripUpdate per scheduled trip_id

**Comment by [barbeau](https://github.com/barbeau)** _Thursday Jul 06, 2017 at 21:27 GMT_ ---- https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/trip-updates.md says: >There should be **at most** one trip update for each scheduled trip. In case there is no...

Check that there is at most one TripUpdate per scheduled trip_id

**Comment by [barbeau](https://github.com/barbeau)** _Thursday Sep 07, 2017 at 02:51 GMT_ ---- Implementation of this will likely be related to https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/255.

Check that there is at most one TripUpdate per scheduled trip_id

**Comment by [barbeau](https://github.com/barbeau)** _Monday Feb 17, 2020 at 14:28 GMT_ ---- Implementation of this rule can be very similar to detecting if vehicle_ids are unique in E052: https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/RULES.md#E052

Check that the delay field is consistent with difference between the scheduled and predicted times

**Comment by [nselikoff](https://github.com/nselikoff)** _Friday May 25, 2018 at 15:36 GMT_ ---- @barbeau FYI Google's QA will currently throw a warning if both `trip_update.delay` and `stop_time_update.arrival/departure.time`are provided, and `trip_update.delay` takes precedence:...

Check that the delay field is consistent with difference between the scheduled and predicted times

**Comment by [barbeau](https://github.com/barbeau)** _Friday May 25, 2018 at 15:55 GMT_ ---- @nselikoff Interesting, thanks for sharing. Looks like Google isn't following the spec on this one - [GTFS-realtime StopTimeEvent](https://developers.google.com/transit/gtfs-realtime/reference/#message_stoptimeevent) docs...

Check that the delay field is consistent with difference between the scheduled and predicted times

**Comment by [nselikoff](https://github.com/nselikoff)** _Friday May 25, 2018 at 16:22 GMT_ ---- @barbeau I agree, StopTimeEvent `time` is preferable to StopTimeEvent `delay`. In this case Google's warning is about TripUpdate `delay`,...

Check that the delay field is consistent with difference between the scheduled and predicted times

**Comment by [barbeau](https://github.com/barbeau)** _Friday May 25, 2018 at 17:38 GMT_ ---- >In this case Google's warning is about TripUpdate delay, which is still listed as experimental in the spec (GTFS-realtime...