New Stop recognition_level To Abbreviate Without Confusion

[webm...@rideschedules.com]

The GTFS specification currently lacks a way for software systems to abbreviate data without causing confusion.  The recognition_level attribute in stops.txt resolves that problem.

I have developed a GTFS reader that is now in use at www.rideschedules.com.  On the whole the specification allows the public convenient access to schedule information.  The single important shortfall that remains unavailable to me and feed publishers is a way to determine which stops may be omitted for brevity without frustrating the public with a list of unfamiliar stops.  The alternative of not truncating data is a long list of stops, long download times, and a mobile device gone unresponsive due to a large data volume.

Currently, I have limited stops to 35 and overage is removed evenly along the route at the necessary increments while keeping stations, if specified, and the first and last stop.  Though I think this is the best possible compromise, the risk of a repulsive user experience remains unacceptably high.  Users will immediately look for familiar stops to judge nearby arrival and departure times.  Instead, they will see a list without the popular stops associated with the route and will have to locate their stop from a list not recognized by the public. The problem is not uncommon in metropolitan areas that frequenlty have routes with 50 to 150 stops.

The recognition_level attribute allows software systems to abbreviate data without causing confusion. The recognition_level identifies the familiarity of a stop along the route.  I propose the values:

0 - Minor stop along the route.
1 - Major stop familar to the general public.
2 - Major or minor stop that appears on published schedules.

The values makes it possible for software systems to accurately discern the familiarity of stops with the added benefit to software developers and GTFS publishers of making it possible to reproduce printed schedules from the data (albeit not under the requirements of the specification since this would be an optional attribute).  

Of course, I am open to alternatives but I am not seeing anything better.

[Stuart Heinrich]

Most stops correspond to street intersections, so you could match those streets to roads in OSM which allows you to get the road type (major, minor, pedestrian etc) and then only mention the stops at major street crossings.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/H5PM3HZ_GsQJ.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[Aaron Antrim]

I speculate that few agencies will have this level of definition for stops ready.  If this is wrong, somebody please correct me.

The GTFS already has a way of defining time points:

If this stop isn't a time point, use an empty string value for the arrival_time and departure_time fields. Stops without arrival times will be scheduled based on the nearest preceding timed stop. To ensure accurate routing, please provide arrival and departure times for all stops that are time points. Do not interpolate stops.

There has been a proposal to add a "timepoint" field to allow interpolated stop times.  This would identify stops where the vehicle will hold, or the most important stops.

More information here:

gtfs-changes: https://groups.google.com/group/gtfs-changes/browse_thread/thread/f13ab94fe78d29ec

ttpub user: https://groups.google.com/group/ttpub-user/browse_thread/thread/6c9a4b573e3569d3/d625353d9697000a?lnk=gst&q=timepoint#d625353d9697000a

[David Turner]

I would suggest removing stops that are not timepoints (i.e. have no
arrival_time/departure_time), to start.

Some systems will have arrival_time/departure_time at all stops (NYCT,
for instance). In these cases, I would choose stops that are not
transfer points. Of course, not all transfers will be listed in
transfers.txt, but it should be straightforward to cluster nearby
transit stops to build a better transfer table. You could also weight
stops by the number of trips that stop at them, to catch express stops.

I actually just implemented a version of this weighted clustering in OTP
-- it probably won't be useful to you, because I was solving a different
problem and my code is not designed to be efficient over a large number
of clusters. But it did solve my problem, which was to find finding the
transit-wise center of a region.

> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/gtfs-changes/-/H5PM3HZ_GsQJ.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes

> +unsub...@googlegroups.com.

[Nicholls, Gregory]

Maybe I'm missing something but surely the decision on whether a stop is of interest to the end consumer is up to the application provider not the feed publisher. Why would you not make these sorts of decisions within the application, or alternatively provide a configuration option to the end user ?

---

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of webm...@rideschedules.com
Sent: Wednesday, 16 May 2012 9:20 PM
To: gtfs-c...@googlegroups.com
Subject: [gtfs-changes] New Stop recognition_level To Abbreviate Without Confusion

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/H5PM3HZ_GsQJ.
To post to this group, send email to gtfs-c...@googlegroups.com.

To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

[Catala, Martin]

If you are looking to show the "most important" stops, would they be the stops that have the most activity at them?

If so, then a query based on the stops and stop_times tables should produce "most active" stops. You can then set your ranges to be a percent of the totals.



Martin Catala
813-974-9791
cat...@cutr.usf.edu

To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

[Jonathan Wilson]

> There has been a proposal to add a "timepoint" field to allow interpolated
> stop times. This would identify stops where the vehicle will hold, or the
> most important stops.

I think that the timepoint field makes sense. My local transit system has
the concept of "timing points" (i.e. stops where a vehicle must not leave
before a specific time) but also provides estimated times for other stops
(e.g. on timetable boards at stops or as part of their "sms the stop number
to get the next few services at that stop" feature)
So the "timepoint" field could indicate that its a timed stop or compulsory
stop.