search

google / transitfeed

A Python library for reading, validating, and writing transit schedule information in the GTFS format.
https://github.com/google/transitfeed/wiki
Apache License 2.0
680 stars 253 forks source link

Validation - More convincing reasoning for removing duplicate stops. #62

Open bdferris opened 10 years ago

bdferris commented 10 years ago

From fredf...@gmail.com on July 16, 2008 17:03:02

Validation output needs to more convincingly explain why duplicate stops are bad.

Original issue: http://code.google.com/p/googletransitdatafeed/issues/detail?id=62

bdferris commented 10 years ago

From THix...@juno.com on September 02, 2008 16:30:56

Multiple agencies can each have a sign (and, therefore, stop) on the same pole. These so-called 'shared stops' will have the same lat/lon, meaning a 'perfect' transfer.  Perhaps including an agency_id column (or generating one) to detect these acceptable 'duplicate' stops.

bdferris commented 10 years ago

From tom.brow...@gmail.com on November 05, 2008 12:33:18

The current release gives the distance between stops and only warns about stops within 2m of each other.

I think it is nice to have only one stop_id per place that passengers think of a stop, independent of if they are waiting for service from the same or different agencies.

Imagine a tool on a phone (or get http://headwayblog.com/wiki/index.php?title=Tranzit ) that looks at your current location, lets you pick a nearby stop and then shows next departure times. Often several routes stop at the same location and go roughly the same direction. In this case it probably makes more sense to list all these routes at the same stop instead of making the user pick "SE Corner of Masonic/#71" then go back and pick "SE Corner of Masonic/#6". The nextbus signs at stops like this typically scroll through the departures of each route.

While making it easy to publish data is very important, making it easy to produce meaningful applications using the data with minimal processing and heuristics is also important. Perhaps this should be a thread on gtfs-changes regarding stop merging.

Is it a short version of this argument that you want in the validator output?

Labels: Language-Python App-FeedValidator

bdferris commented 10 years ago

From fredf...@gmail.com on November 05, 2008 12:49:07

I've been able to convince agencies why they need to merge the stops, but I was hoping the validation output could make a more convincing argument so that I don't have to intervene so we can scale.

bdferris commented 10 years ago

From joe.hugh...@gmail.com on November 05, 2008 14:08:15

Maybe we could put up a wiki page giving an in-depth explanation and give the URL in the validator output?

bdferris commented 10 years ago

From fredf...@gmail.com on November 05, 2008 14:23:04

Maybe the validation output writes a link to where they can find more information which goes to a wiki page?

bdferris commented 10 years ago

From tom.brow...@gmail.com on September 21, 2009 11:15:32

How about the stops-too-close warning suggest using a stop station hierarchy? This would be a simple change.

Labels: Difficulty-Easy

bdferris commented 10 years ago

From fredf...@gmail.com on September 21, 2009 11:17:22

Yes thats a good idea.