Implement stop vs. origin verification (GTFS rule)

[maximearmstrong]

Is your feature request related to a problem? Please describe.
A stop should not be to close to origin (latitude and longitude). This is a GTFS rule implemented in Google Python validator and featured in Google Type Error as TYPE_POINT_NEAR_ORIGIN.

Describe the solution you'd like
Actual Google GTFS validator behaviour : verifies if stop latitude and longitude are too close to origin by comparing them.

Describe alternatives you've considered

Additional context
Line 73 in Error support priorities https://docs.google.com/spreadsheets/d/1vqe6wq7ctqk1EhYkgtZ0_TbcQ91vccfs2daSjn20BLE/edit#gid=0

[barbeau]

@maximearmstrong What is "too close" in this case, according to the Python validator?

This is a rule that certainly makes sense to be an error IMHO, although neither the spec nor best practice say anything about this:

• https://gtfs.org/reference/static#stopstxt
• http://gtfs.org/best-practices/#stopstxt

[maximearmstrong]

@barbeau At the moment, the Python validator verifies Latitude and Longitude are not lesser than 1 degree apart from the origin : (abs(x),abs(y)) > (1,1).

The origin is located in water, so this makes sense, but maybe an implementation considering oceans in general would make more sense? If the goal is to avoid Latitude, Longitude to be out of range or pointing invalid places.

[barbeau]

@maximearmstrong That's certainly possible - yes, the overall goal is to detect bus stops that aren't in feasible locations. There might be some ferry stops somewhere off coast, but I would think we could flag large chunks of open ocean. Although all geographic bounds tests definitely have some overhead, so we'd need to take that into account.

I just checked the RT validator, and we have a rule E026 to check for valid vehicle locations, but we only validate the lat and lon data types being in the valid -90 to 90 and -180 to 180 ranges, but don't check for (0,0). I've opened this issue to expand checks on the RT validator too - CUTR-at-USF/gtfs-realtime-validator#379.

[ghost]

Ok. I guess we will start by implementing the equivalent (no less than 1 degree) and see from there. @barbeau do yout hink that means we should start looking at a library for geographic checks? I'm not very familiar with geographic data maybe a lot can be done with "simple" math but I remember using useful utils library in Android development to checks for thing like a lat/lng being inside/outside a rectangle (2 others lat,lng couple) and the like

[barbeau]

We're using spatial4j in the GTFS-RT validator, and I'd recommend that rather than rolling our own:

        <!-- Spatial operations -->
        <dependency>
            <groupId>org.locationtech.spatial4j</groupId>
            <artifactId>spatial4j</artifactId>
            <version>0.6</version>
        </dependency>
        <dependency>
            <groupId>com.vividsolutions</groupId>
            <artifactId>jts</artifactId>
            <version>1.13</version>
        </dependency>

Here are some example utility classes for checking if a vehicle position is within a shape:
https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/gtfs-realtime-validator-lib/src/main/java/edu/usf/cutr/gtfsrtvalidator/lib/util/GtfsUtils.java#L162

We're using this mainly for more complex bounds checking - is the vehicle position within the outer bounds formed by all stop locations (E028), or within a buffer surrounding a trip shape (E029).

We don't directly calculate distance in the RT validator, but it looks like that is trivial:
https://locationtech.github.io/spatial4j/apidocs/org/locationtech/spatial4j/context/SpatialContext.html#calcDistance-org.locationtech.spatial4j.shape.Point-org.locationtech.spatial4j.shape.Point-

[isabelle-dr]

Closing, covered by point_near_origin