General Question on Shapes.txt

[christen...@gmail.com]

Brand new the Transit feed process. Hoping someone can get me sqaured away on a few items.

1. Is Shapes.txt what Google Transit needs to draw the route lines?
2. Shouldn't shape_id be the route ID?
3. shape_pt_sequence is the # of each node, starting from start to end, so Google can draw the route properly?

Thank you, Chris

[Steven Judd]

Short answers:
1. Yes
2. See below
3. Yes

Long Answer:
The shapes.txt is based off of each unique path that a bus route takes. So for every direction, deviation, short turn, etc, there needs to be an identifying shape associated with a trip in stop_times.txt if you include a shapes.txt file, although the file is optional. Shapes in GTFS are specific to the trip since buses that have the same Route ID may not necessarily follow the same path for each trip (by direction) like school trips, commuter trips, or short turns.

So not only is the shape_pt_sequence needed to determine the direction the path is taking, the optional shape_dist_traveled will allow google and others to draw the path in transit directions.

Hope this helps,
Steven

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Ferris]

I would add that in most cases, I encourage feed providers to NOT specify shape_dist_traveled since (a) it's tricky to get the value right and (b) most GTFS consumers can match stops to shapes without it.

[christen...@gmail.com]

Does Google use shape_dist_traveled to estimate travel time from one station to an address? Its easy to calculate distance from one node along a route to another.

On Saturday, March 21, 2015 at 3:04:53 PM UTC-7, Brian Ferris wrote:

I would add that in most cases, I encourage feed providers to NOT specify shape_dist_traveled since (a) it's tricky to get the value right and (b) most GTFS consumers can match stops to shapes without it.

On Sat, Mar 21, 2015 at 11:00 PM Steven Judd <stevenwe...@gmail.com> wrote:

Short answers:
1. Yes
2. See below
3. Yes

Long Answer:
The shapes.txt is based off of each unique path that a bus route takes. So for every direction, deviation, short turn, etc, there needs to be an identifying shape associated with a trip in stop_times.txt if you include a shapes.txt file, although the file is optional. Shapes in GTFS are specific to the trip since buses that have the same Route ID may not necessarily follow the same path for each trip (by direction) like school trips, commuter trips, or short turns.

So not only is the shape_pt_sequence needed to determine the direction the path is taking, the optional shape_dist_traveled will allow google and others to draw the path in transit directions.

Hope this helps,
Steven

On Mar 21, 2015 2:06 PM, <christen...@gmail.com> wrote:

Brand new the Transit feed process. Hoping someone can get me sqaured away on a few items.

1. Is Shapes.txt what Google Transit needs to draw the route lines?
2. Shouldn't shape_id be the route ID?
3. shape_pt_sequence is the # of each node, starting from start to end, so Google can draw the route properly?

Thank you, Chris

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.

[Brian Ferris]

No.  The shape_dist_traveled field is dimensionless so it can't be used for reliably measuring distances.

To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.

[Aaron Antrim]

On Sat, Mar 21, 2015 at 3:04 PM, 'Brian Ferris' via Transit Developers <transit-d...@googlegroups.com> wrote:

I would add that in most cases, I encourage feed providers to NOT specify shape_dist_traveled since (a) it's tricky to get the value right and (b) most GTFS consumers can match stops to shapes without it.

This brings up a question about shape_dist_traveled for me. 

Presumably, if shape_dist_traveled is not provided in the shapes.txt file trip planners match the nearest point on a shape to a stop location in order to determine what portion of the shape to draw between two points. However, cases in which a route alignment intersects itself are ambiguous.

The screenshot below (attached) is several years old and provides example of what Google Maps did (or still does?) when it encounters this ambiguity. After the loop between HWY 101 and 299 where the alignment intersects itself, the travel line stops following the road network until it the next stop (Calville). I later added shape_dist_traveled to humboldtcounty-ca-us and all other Trillium feeds, and the problem was remedied (current result in Google Maps: https://goo.gl/maps/CIi5y)

Today, if I were to remove shape_dist_traveled would this cause the same display issue in Google Maps? What about other transit trip planners like OpenTripPlanner and Bing Maps?

 

[Brian Ferris]

I think at least on the Google side, the stop-to-shape matching code got a complete re-write a while back that made it much more reliable in the face of complex or looped geometries.  That said, we will still try to use shape_dist_traveled values first if they are specified.  I just know know I've seen problems where data exported from a common scheduling system has systemic errors with shape_dist_traveled values that caused visual artifacts in the routing results when used as-is.

[christen...@gmail.com]

I still do not understand. In trips.txt I have route_id and trip_id. Which do I associate with the shape_id in shapes.txt?

I converted the route lines for each bus trip into more simplified sequence of nodes. So each route equals ~200 points, Each point has lat/long and sequence (starting at 1 where route begins). I was assuming I would attribute each route in shapes.txt with the route_id, but the feed validator program states "The shapes with the following shape_ids aren't used by any trips".

[Harshath JR]

Each individual trip is associated with shapes. trips.txt can have another field called shape_id, which will be referring to shapes defined in shapes.txt.

On Wed, Apr 15, 2015 at 1:34 AM <christen...@gmail.com> wrote:

I still do not understand. In trips.txt I have route_id and trip_id. Which do I associate with the shape_id in shapes.txt?

I converted the route lines for each bus trip into more simplified sequence of nodes. So each route equals ~200 points, Each point has lat/long and sequence (starting at 1 where route begins). I was assuming I would attribute each route in shapes.txt with the route_id, but the feed validator program states "The shapes with the following shape_ids aren't used by any trips".

[christen...@gmail.com]

great - the feedvalidator likes it now :)

[Eric Goodman]

This is a related question. How are you getting the distance between individual points? I know how to calculate it from the x,y's and can write a script to do that for a list, but is there an easier way to find it? I have shape_distance_traveled in stop_times.txt for the distance between stops, It sounds like I really don't need it in shapes.txt for every individual point along the line. Is that right?

[Chris Erichsen]

I created line segments in GIS then calculated the length and used this, in the correct units. I had to experiment with simplifying the path to get smallest collection of nodes while maintaining good representation of route. I used Arcmap to do this. Then assign order of nodes.

--
You received this message because you are subscribed to a topic in the Google Groups "Transit Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/transit-developers/KH8Ug66A7fk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to transit-develop...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

[Steven Judd]

I highly recommend NOT to use this method to calculate route distance, as your actual route distance will vary greatly from the calculated distance in GIS because of terrain, lane changes, etc. Ideally this data would come from your AVL (Automatic Vehicle Locator), as these systems need this data to calculate accurate positions, but if the agency doesn't have such data, I defer to the community for best alternatives.

--

You received this message because you are subscribed to the Google Groups "Transit Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.

[Tony Laidig]

On Monday, May 11, 2015 at 10:44:58 PM UTC-4, Steven Judd wrote:

I highly recommend NOT to use this method to calculate route distance, as your actual route distance will vary greatly from the calculated distance in GIS because of terrain, lane changes, etc. Ideally this data would come from your AVL (Automatic Vehicle Locator), as these systems need this data to calculate accurate positions, but if the agency doesn't have such data, I defer to the community for best alternatives.

The most common behavior from an AVL system for deriving distances is to map-match positions to a known location on the route. All of the AVL systems that I have dealt with do not factor in terrain. Some may include odometer data in what is sent over the wire, but this lacks accuracy as well.

In the end, neither the odometer nor GIS method will provide incredibly accurate data, but in most cases the accuracy is good enough.

[Steven Judd]

The terrain is factored in (partially) through the odometer, as the same segment of road can have different distances from the GIS if there are changes in elevation that aren't factored in without a vertical datum. But as you mentioned, the odometer is not a perfect data collection tool.

[Chris Erichsen]

The transit I am working with now is flat terrain, absolutely flat. I have accurate route data (my routes trace the most updated street info). So am fine with the GIS calculated distances. The margin of error (I am guessing <5') is acceptable. I didn't know about the AVL system etc.- thanks for that. Always learning more and more of GTFS.

--
You received this message because you are subscribed to a topic in the Google Groups "Transit Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/transit-developers/KH8Ug66A7fk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to transit-develop...@googlegroups.com.

[off...@energie-umwelt.at]

For optimising operation though it would be great having STOP IDs and correct distances ...

Am Dienstag, 12. Mai 2015 04:44:58 UTC+2 schrieb Steven Judd:

I highly recommend NOT to use this method to calculate route distance, as your actual route distance will vary greatly from the calculated distance in GIS because of terrain, lane changes, etc. Ideally this data would come from your AVL (Automatic Vehicle Locator), as these systems need this data to calculate accurate positions, but if the agency doesn't have such data, I defer to the community for best alternatives.

On Mon, May 11, 2015 at 7:17 PM, Chris Erichsen <christen...@gmail.com> wrote:

I created line segments in GIS then calculated the length and used this, in the correct units. I had to experiment with simplifying the path to get smallest collection of nodes while maintaining good representation of route. I used Arcmap to do this. Then assign order of nodes.

On Wednesday, May 6, 2015, Eric Goodman <ejoseph...@gmail.com> wrote:

This is a related question. How are you getting the distance between individual points? I know how to calculate it from the x,y's and can write a script to do that for a list, but is there an easier way to find it? I have shape_distance_traveled in stop_times.txt for the distance between stops, It sounds like I really don't need it in shapes.txt for every individual point along the line. Is that right?

On Wednesday, April 15, 2015 at 8:47:22 AM UTC-7, Juventus Ventuno wrote:

great - the feedvalidator likes it now :)

--
You received this message because you are subscribed to a topic in the Google Groups "Transit Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/transit-developers/KH8Ug66A7fk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to transit-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.