Sean Barbeau

@evansiroky I agree that the logic of of the cross-message validation needs to be reviewed in context of the batch processor. From what I recall, when you're using the webapp...

This one is interesting. With the current design of the validator, we could only generate this for the webapp but not the batch validator, because the batch validator doesn't know...

Thinking more, we could add another optional parameter to the batch validator that's the source URL of the feed that would allow us to generate this error in batch validation...

See also the discussion in https://github.com/MobilityData/gtfs-realtime-validator/issues/29#issuecomment-1071757182 for a command-line monitoring service that might fetch multiple times over a longer period of time.

@AntoineAugusti I looked at the logging implementation in the project and it seems like the log statements are sent to the appropriate channel. For example, looking at [Main.java](https://github.com/MobilityData/gtfs-realtime-validator/blob/master/gtfs-realtime-validator-lib/src/main/java/edu/usf/cutr/gtfsrtvalidator/lib/Main.java#L61-L73) for the...

@AntoineAugusti Actually, I think I see what you're saying now. Here's the output from IntelliJ:  It looks like even though we're specifying the different logging levels within the application...

Right now we have two errors that are only applied to v2.0 feeds, E048 and E049: * https://github.com/MobilityData/gtfs-realtime-validator/blob/master/RULES.md#e048---header-timestamp-not-populated-gtfs-rt-v20-and-higher * https://github.com/MobilityData/gtfs-realtime-validator/blob/master/RULES.md#e049---header-incrementality-not-populated-gtfs-rt-v20-and-higher ...but we don't have any rules that target < v2.0...

I believe this is covered in: https://github.com/MobilityData/gtfs-realtime-validator/blob/master/RULES.md#e022---sequential-stop_time_update-times-are-not-increasing

@e-lo I think this best practice text was created as improved language we wanted to incorporate directly into the spec, but that step just hasn't happened yet. I'd certainly like...

Also, note that after a conversion to RFC2119, the above "should" should become a "must": >delay *must* be used when the prediction is given relative to some existing schedule in...