stops.txt: stop_type proposal

[T Sobota]

Based on an internal use case, and possibly addressing other use issues - I would like to propose an added [optional] field to stops.txt:  stop_type (or similar name).

Values would include:

0 (or empty) - indicates this stop is "normal" type

1 - indicates this stop is not "typical"

The underlying goal of this proposal would go towards flagging what stop_id points should, or should best not, be drawn by feed consumers in mapping or other applications.

Not "typical" in this sense might cover stops that are served regularly or exclusively by trips with stop_times.txt entries where pickup_type equals 1 (No Pick Up available); stops where an agency does not maintain any fixed asset designating it as a stop (sign pole, etc. - or where pickup_type and/or drop_off_type equal 2 or 3, must coordinate with agency or driver); and possibly to establish typical deviation stop locations (that get used during unforeseen detour events) in stops.txt - not certain if google realtime spec already allows a specific lat/lon coordinate pair to be sent with an alert in such cases.

As noted, the internal use case is that I would hope that the Google map tiles might eventually drop a subset of bus stop icons from the base map (where there is no sign pole installed, and passengers need to coordinate with driver).  Having that type of stop shown on the map can cause confusion to users - thinking they can generally walk to that bus stop location and wait to catch the next passing bus.

The other use issue might encompass the difficulty in coding flexible route structures.  While this still might require "establishing" bus stop locations every given amount of distance along a route corridor, at least those arbitrary locations could be flagged to prevent them as displaying as actual bus stop location in mapped versions of the data.

Thanks

Tim Sobota

Metro Transit, City of Madison (WI), USA

[StuartJReynolds]

In the UK, we have lots of "demand responsive" transport where whole communities are flexible zones and the bus will pick up anywhere - but you have to book it. We have representations of these stops in data, as "FLX" (flexible) types where there is a nominal centroid point (to give something to hang pseudo-timetables on), and a polygon defining the area to which that point applies. A colleague and I recently had a long discussion with Brian about this, and I know that the folks there are looking at how best to represent these types of services in GTFS so I don't want to cut across any outputs from that work, but I would certainly support something which allowed a stop to be marked as "flexible" or "by arrangement" or whatever the description was.

Regards,

Stuart

traveline south east & anglia, UK

On Thursday, February 21, 2013 1:43:13 PM UTC, Tristram Gräbener wrote:

Hello,

We also encountered a similar problem.

We were thinking to extend the location type and have a value "2" that would represent a unspecified location(you must call to be picked-up, but the pickup can be anywhere).

We don't have a strong opinion on what approach would be the best.

Tristram Gräbener, Canal TP, Paris, France

[谷小丰]

Hi, 

We also have similar situation in China, but maybe a bit different.

1. the lines have some fixed stops to pick up people.

2. at some of other stops, you have to wave your hand to the driver to stop and pick up you(we don't contact the driver in advance, the bus companies usually have no such services).

3. for some lines, you can even be pick up anywhere one the way when you wave your hand to the driver.

=======================================
谷小丰 Frank Gu

Mobile: 13501352804
MSN: fran...@hotmail.com
QQ:932301
Google Talk: fran...@gmail.com

On Thu, Feb 21, 2013 at 9:43 PM, Tristram Gräbener <tris...@gmail.com> wrote:

Hello,

We also encountered a similar problem.

We were thinking to extend the location type and have a value "2" that would represent a unspecified location(you must call to be picked-up, but the pickup can be anywhere).

We don't have a strong opinion on what approach would be the best.

Tristram Gräbener, Canal TP, Paris, France

Le vendredi 16 novembre 2012 20:17:23 UTC+1, T Sobota a écrit :

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
To post to this group, send email to gtfs-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/gtfs-changes?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Ferris]

Sorry for not responding sooner.  It's true that the subject of demand-response / ad-hoc / para-transit service has been coming up a lot lately and I've been talking to a number of people about their needs / what we could do in the spec.  It's also come up a couple times on the list before:

https://groups.google.com/d/topic/gtfs-changes/zBhhIXked7g/discussion
https://groups.google.com/d/topic/gtfs-changes/xI7MfzPQVUs/discussion

You guys have already hit on most of the features that people are looking for.  I'm summarizing a lot of complexity here, but there seem to be three aspects that come up:

1) When do riders board the bus?  Is there a fixed schedule?  A flexible schedule?  A completely ad-hoc on-demand schedule?

2) Where do riders board the vehicle?  It could be a fixed stop, a flexible service area (defined by a centroid or a polygon), or any point along a fixed route.
3) How do riders coordinate with the agency?  Is it a matter of flagging the operator?  Calling ahead?

Working backwards, we already have a mechanism for tackling #3 of sorts in stop_times.txt pickup_type and drop_off_type that allow you to specify that a stop must be coordinate with the driver or perhaps with the agency in advance.  There's probably an argument for specifying these flags in trips.txt or routes.txt, especially in cases where a route or trip doesn't have stops in the traditional sense.

Regarding stops, I think Tim's proposal and Aaron's original proposal are the most obvious ways to tackle some of the key representations.  To handle flexible zones, we add a new "location_type" value in stops.txt to indicate that this stop represents the center of a service area instead of a fixed stop.  I'd actually argue against using "2" because this is already in use by a number of agencies for modeling entrances in GTFS (whether that ultimately makes it into the spec is still an open question).  Maybe "3" instead?

In addition, I'd riff on Aaron's original proposal and add a "areas.txt" file that would allow an agency to define the actual area covered by a flex zone.  Something like:

stop_id,area_pt_lat,area_pt_lon,area_pt_sequence

Similar to shapes.txt, except keyed by stop_id and defining a polygonal area instead of a shape.  Not every agency would want to or even be able to define such flex areas, but I know a number of the UK agencies already have this info and it'd be nice to show to riders / integrate into routing algorithms potentially.

Regarding routes where you can board or alight at any point. this seems like a good candidate for a new field in routes.txt or trips.txt.  Something like "flexible_pickup" and "flexible_drop_off", where 0 is the current default behavior of pickup / drop off only at stops, while 1 could indicate anywhere along the route.  Some agencies have been working around this current limitation of the spec by just injecting extra stops, but that definitely seems like a hack ;)

Finally, there is the schedule aspect.  You can probably due a lot with a combination of frequencies.txt and some rough timing estimates in stop_times.txt but maybe we need more?  I don't have any concrete proposals here.

Either way, lots of different ideas to consider.  For agencies, if you've got a particular nasty edge-case in your demand-responsive / flex / para-transit system, I'd love to hear about it.  For developers, what would you actually like to build in practice?

Brian

[T Sobota]

Brian-

  Can you confirm if the default base map tiles drawn by the Google Map service do use a different (or no) icon for instances where agencies have begun using location_type=2 for an entrance feature?  Or does the standard bus icon plot at every coordinate pair listed in stops.txt - regardless of location_type (o=stop, 1=station, 2=entrance)?

  Again, my ultimate goal was to not have informal "flag" stops plotted on the Google Map service (or treated by other feed consumers) in a manner equal to a standard stop with sign pole, etc.

  I would be happy to attribute any such flag stops in the stops.txt file with a location_type of 3 (or other value) - if that would be a method to flag those stop coordinates as not to be plotted (like location_types 0 or 1).

[Brian Ferris]

We have different rendering rules for stops, stations, and entrances, with specific logic for particular agencies, countries, etc as localization requires.

In terms of generally controlling the rendering of stops on Google Maps tiles (or other consumers of GTFS), I'm not a big fan of adding those kind of fields to the spec.  I'd rather we describe the specific properties of the stop that a developer might use as a signal to decide if a stop should or should not be shown and then let the developer decide.  For example, I believe Google Maps already remove stops from the map if they aren't referenced by any trips (or if only referenced with no pickup or dropoff rules).  Regarding flag / coordinate-with-agency stops, I think Google Maps could do a better job of making it clear that those stops are different than a typical transit stop.  I'd rather go that route than adding a general "hide this stop on maps" flag.

Brian

[Denis Haskin]

I'm going to try and give this discussion a bump: I've tried to summarize what's been discussed on this list in re: DRT/paratransit/flex needs in a new post: https://groups.google.com/d/msg/gtfs-changes/F3sbanLXeMk/mmp41LdxM8AJ

I'd certainly be interested in knowing where things stand with this discussion, and what people know about other work in this space in re: GTFS.

Thanks,

Denis

[Stuart Reynolds]

Denis,

 

Yes - in the UK national stop model, NaPTAN. They are heavily used in some of the more rural parts of the country where DRT services feed into scheduled trunk routes.

 

In the model, we have a single stop point representing a nominal pickup point in a zone, which we give the code FLX because it is a flexible stop.  Then, to show the area that this nominal point serves, we define a polygon of 3 to n points using the coordinates of the vertices and referencing the stop point.

 

If you wanted to model this exactly the same way in GTFS, the FLX stop is just another stop, but with a new stop type code, and the polygon should probably be defined in a new file called e.g. “flexible zones” or something like that.

 

Cheers

Stuart

 

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Denis Haskin
Sent: 15 April 2013 7:17 PM
To: gtfs-c...@googlegroups.com
Subject: [gtfs-changes] Re: stops.txt: stop_type proposal

 

Stuart -- when you say you "have representations of these stops in data", you mean in your own internal representation, yes?  Not in GTFS?

 

Thanks,

 

Denis

 

(apologies for reviving an old thread; doing some DRT/paratransit research in preparation for implementation an application)

--

[Denis Haskin]

Stuart -- thanks for the clarification.

--

Denis Haskin

cell: 781-258-7414