Stop clusters based on parent stations

[barslett]

Hi,

here in Greater Oslo, our stop hierarchy is 100% based on parent/child stops, for all transport modes. The parent stations are the ones that are exposed in our stop/place/address lookup module, while itineraries are presented on the "child stop"/stop point level. To achieve this, we have until now been using a mapping table in our integration platform. To mitigate the dependency on modules outside OTP, we have recently started looking at stop clusters, which seem to have been aimed at serving the purpose of mapping between child and parent.

However, it seems to me that today's implementation is only halfway there. The clustering is based on proximity instead of parent/child relation, and the cluster indexing is done during the generation. From the code comments, I understand that this is done because of insufficient parent station data in some cities, and the proximity-based clustering is done as a best effort (?)

What is the current view about this? I have rewritten the clusterStops() method to do the clustering based on parent/child, which seems to pretty much solve our requirements. Would it be possible to have both options available in the code base?

[barslett]

While working with the stop clusters, we have also bumped into the same problem with lazy initialization as was fixed for Index API in #2178. Have fixed it and will submit it in a PR.

[barslett]

The lazy initialization has been added to the PR #2376.

@abyrd - Do you have any recommendations of how to handle the two different approaches to stop clusterings? I could add a build parameter to choose between proximity or parent/child relation?

[barslett]

The PR contains a route-config parameter stopClusterMode which allows for any number of different ways of clustering, including the implementation for clustering by parent station.

Closing the issue as the PR has been merged.