Handle GTFS Pathways

[abyrd]

We are seeing problems from feeds using the GTFS pathways extension. These contain stops with location_type > 1 for which coordinates are optional. This wreaks havoc with the stop spatial index used in generating GTFS vector tiles, but that's just one symptom of the underlying need to handle non-stop, non-station transit nodes that may have no coordinates.

We need to at least gracefully tolerate feeds with these extensions, and eventually fully reconstruct the pathways within the station even when they have no coordinates.

@ansoncfit mentioned MBTA use of pathways in #642 (comment)_

[derhuerst]

[…] stops with location_type > 1 for which coordinates are optional.

Nit-pick: For entrances/exits (location_type = 2), coordinates are required.

The challenge described persists of course.

[derhuerst]

I'm curious if and how this would affect other implementations, and therefore trying to understand the problem.

Why is it a problem for routing if generic nodes (location_type = 3) and boarding areas (location_type = 4) are missing in the spatial index?

[ansoncfit]

Fully reconstructing pathways would help address #330

[abyrd]

@derhuerst it's not a problem that these nodes are not in the spatial index. The problem was that the nodes without coordinates had coordinate values of NaN which broke the sort algorithm in the spatial index. This didn't just leave them out of the index, it caused a failure when opening the feed.

Indeed my initial comment was wrong with respect to location_type = 2 - the conditions in the PR should now exactly match the rules in the spec.