stops: add checks point_near_origin and point_near_pole

[AntoineAugusti]

Consider adding 2 new rules validating latitude/longitude for stops. These 2 checks are part of the canonical GTFS Validator.

Rules

• point_near_origin
  • Original Rule
  • Original Implementation
• point_near_pole
  • Original Rule
  • Original Implementation

ℹ️ 🙏 The rules are coming from Google's and MobilityData validators.

[thbar]

Implemented in #201, we're going to do a bit of live testing I think!

[AntoineAugusti]

@thbar #201 only outputs an error for (0, 0), this issue is about adding other checks

[thbar]

Sorry, I was a bit too fast !

Updating the doc for clarity.

[thbar]

I have updated the issue text (created separated tasks) to make it clearer for reviewers (since the issue title mentioned 2 checks, but the body did not).

Also @AntoineAugusti, I recommend an explicit attribution of the original implementation at the very top of the issues and PR, something like: "this is a backport of rules xyz from the MobilityData validator".

While not strictly required from a license point of view if I understand correctly, and while we already link there, a more explicit credit would be fair game in my opinion!

[AntoineAugusti]

Updated the description to reflect that point_near_origin has not been implemented.

We have been disallowing (latitude=0, longitude=0) for several years but we should consider updating the rule to follow what Google and then MobilityData are doing with the point_near_origin rule.

I recommend an explicit attribution of the original implementation

Sure, done ✅ 🎩

[ttezer]

I reviewed the current implementation and the discussion around PR #201.

MobilityData is used here only as a behavioral reference for the thresholds and rule definitions, because this issue links to that implementation. The proposed code is not a Java port: it is a native implementation using this project's existing Issue, Severity and validator architecture.

The current code in src/validators/stops.rs still has two gaps:

• has_coord() treats (0, 0) as missing coordinates;
• valid_coord() only checks the latitude and longitude ranges;
• there is no check for points close to the origin or to either pole.

The existing 0, 0 handling from PR #201 is therefore not equivalent to the point_near_origin rule.

I suggest implementing this as a small, self-contained change.

src/issues.rs

Add two issue types:

PointNearOrigin,
PointNearPole,

Both should use Severity::Error, matching the MobilityData validator implementation.

src/validators/stops.rs

Add the thresholds used by the MobilityData implementation:

const POINT_NEAR_ORIGIN_THRESHOLD: f64 = 1.0;
const POINT_NEAR_POLE_THRESHOLD: f64 = 89.0;

Add the two checks:

fn check_point_near_origin(stop: &gtfs_structures::Stop) -> Option<Issue> {
    match (stop.latitude, stop.longitude) {
        (Some(lat), Some(lon))
            if valid_coord(stop)
                && lat.abs() <= POINT_NEAR_ORIGIN_THRESHOLD
                && lon.abs() <= POINT_NEAR_ORIGIN_THRESHOLD =>
        {
            Some(
                Issue::new_with_obj(Severity::Error, IssueType::PointNearOrigin, stop)
                    .details(&format!(
                        "point is near origin: latitude={lat}, longitude={lon}"
                    )),
            )
        }
        _ => None,
    }
}

fn check_point_near_pole(stop: &gtfs_structures::Stop) -> Option<Issue> {
    match (stop.latitude, stop.longitude) {
        (Some(lat), Some(_lon))
            if valid_coord(stop) && lat.abs() >= POINT_NEAR_POLE_THRESHOLD =>
        {
            Some(
                Issue::new_with_obj(Severity::Error, IssueType::PointNearPole, stop).details(
                    &format!("point is near a pole: latitude={lat}"),
                ),
            )
        }
        _ => None,
    }
}

The coordinate validation should call both checks, while keeping invalid coordinates separate:

let near_origin = stops_as_ref.clone().filter_map(check_point_near_origin);
let near_pole = stops_as_ref.clone().filter_map(check_point_near_pole);

let invalid = stops_as_ref
    .filter(|stop| !valid_coord(stop))
    .map(make_invalid_coord_issue);

missing_coord
    .chain(invalid)
    .chain(near_origin)
    .chain(near_pole)
    .collect()

To avoid reporting 0, 0 as MissingCoordinates and PointNearOrigin at the same time, has_coord() should consider two present coordinate values as coordinates, even when both values are zero:

fn has_coord(stop: &gtfs_structures::Stop) -> bool {
    matches!((stop.latitude, stop.longitude), (Some(_), Some(_)))
}

This makes (0, 0) produce a single PointNearOrigin error instead of the current MissingCoordinates warning.

The regression tests should cover:

• (0, 0) => PointNearOrigin;
• a valid point inside the 1° origin threshold;
• latitude 89.0 and -89.0 => PointNearPole;
• normal coordinates => no new issue;
• out-of-range coordinates such as latitude 92.0 => only InvalidCoordinates, without an additional pole issue.

This would be a focused implementation of the two rules requested in this issue, with explicit attribution to the MobilityData validator:

https://github.com/MobilityData/gtfs-validator/blob/ada0b25fe3144d941769e39a51c78ec30ac8bce4/processor/src/main/java/org/mobilitydata/gtfsvalidator/processor/LatLonValidatorGenerator.java

The thresholds are abs(latitude) <= 1.0 and abs(latitude) >= 89.0, with the origin rule also requiring abs(longitude) <= 1.0.