Closed isabelle-dr closed 2 years ago
Also, there seems to be a false positive for:
(919) 485-RIDE
After discussion with @isabelle-dr we agreed on downgrading InvalidPhoneNumberNotice
to WARNING
as part of v3.0.0
release and then investigating how to avoid these false positives. This will likely involve work in collaboration with @MobilityData/transit-specs to clarify the definition of phone numbers.
Thank you for your reporting a bug. The issue has been placed in triage, the MobilityData team will follow-up on it.
Are the correct country codes being used when running the validator on the above GTFS datasets? Could you provide the country codes that are being used?
Are the correct country codes being used when running the validator on the above GTFS datasets? Could you provide the country codes that are being used?
No country code was provided to run the validator on the above GTFS datasets.
Also here is the exhaustive list of datasets that were valid in v2.0.0
but are invalidated by v3.0.0-beta
because of this notice, and the related phone numbers:
You will find here the same but for datasets invalidated by v2.0.0
and v3.0.0-beta
@barbeau
The country code is an optional parameter, no valid dataset should have to use it to not be flagged invalid. That's why we think it would be preferable to downgrade it first thing, and then reassess how we do phone number validation.
So it seems like the bug here is that the validator is validating phone numbers and outputting InvalidPhoneNumberNotice
when it shouldn't be validating phone numbers at all (e.g., when a country code isn't provided)?
I tested HART Tampa, FL data (phone number 813-254-4278
):
...with and without the country code. When I provide --country_code us
I don't get InvalidPhoneNumberNotice
, but when I don't provide that command-line option then I get InvalidPhoneNumberNotice
.
Maybe there was a regression after making country code optional in PR https://github.com/MobilityData/gtfs-validator/pull/851?
Yes, I think this was broken in the PR that changed dependency injection - https://github.com/MobilityData/gtfs-validator/pull/862. EDIT - Or maybe not - see PR https://github.com/MobilityData/gtfs-validator/pull/1062.
I think I have a quick fix for this - I'll open a PR shortly.
The validator behaviour seems to be more strict than the specification. With the current implementation, this notice is emitted by more than 50% of the datasets available on the Mobility Database.
The GTFS Specification in
agency.agency_phone
says:The validator flags the following phone numbers as invalid, although they are valid with regards to the specification.