You cannot post messages because only members can post, and you are not currently a member.
Description:
This group is the official venue for discussing upcoming changes to the General Transit Feed Specification (GTFS). Discussion is open to current users of the feed specification.
|
|
|
GTFS Flexible Transit Working Group (DRT, flex-route, etc.)
|
| |
(Cross-posted to gtfs-changes and transit-developers. Apologies in advance for any duplicate emails.)
Hi all,
This is a message to announce a forum for discussing the GTFS and transit services that do not fall into the fixed-route category. See below for more background and links. Please join the group and participate if this is a topic that interests you.... more »
|
|
|
Integrating Trip Planning functionality into Schedule Viewer
|
| |
Hello I have created a test feed and verified its validity with the Feed Validator and Schedule Viewer tools. [link] I want to test the trips generated by the feed prior to uploading the data. That is to run test "trip plans." The data is relatively small, so it does not make sense to submit it to Google Maps as a Transit Partner as per the instructions:... more »
|
|
|
Fwd: feed_info.txt date format specification
|
| |
Someone just pointed out what looks like a bug in the GTFS spec. For
feed_info.txt feed_start_date and feed_end_date, the spec states:
"Both days are given as dates in YYYYDDMM format as for
calendar.txt<[link]>
"
Notice the day-before-month format. But in fact, the date format used in... more »
|
|
|
Negative Stop-Times / Trips Before Midnight
|
| |
tl;dr - New tool to help agencies with trips before midnight. Also, how
would you interpret "-3:25" in stop_times.txt?
I know there have been some recent discussions from agencies and GTFS
producers asking to extend stop_times.txt to support arrival and departure
times that start "before" midnight. I'm still hesitant to add this to the... more »
|
|
|
On shape_dist_traveled...
|
| |
I was looking at a few edge-cases in some stop-to-shape matching code this
week and I realized that I had made some assumptions about the
"shape_dist_traveled" fields of stop_times.txt and shapes.txt that maybe
weren't valid. Most of the assumptions had to do with "partial"
specification of shape_dist_traveled values. Thoughts on the following?... more »
|
|
|
State of paratransit, DRT, flexible routes, etc for GTFS?
|
| |
We're starting a project to provide trip-planning capabilities that requires integration of fixed-route, paratransit services, demand-response, possibly flexible routes, the like. I've reviewed this mailing list and attempted to collect all the related proposals and discussions, which I've summarized here:... more »
|
|
|
A GTFS offset for intercity [long-distance] services?
|
| |
*
Hello All,
I’m relatively new here, bear with me and let me know if I’m totally off on this.
In summary: intercity [long-distance] use of GTFS is growing, and there don’t seem to be many alternative standards. There are a lot of things that long-distance travellers care about that the current GTFS isn’t able to... more »
|
|
|
stops.txt: add city, state/province, postal code as optional fields
|
| |
As a consumer of this data, i have to either force one value for each when i import this data or do a reverse-geocode based on the coordinates. The entity that creates the stops.txt file likely knows this information and could populate it if it was sanctioned. The usage for me is to import the stops into a schema that doesn't allow... more »
|
|
|
