zephyr-data-specs/GMNS

If a location is "on" a node, do we have to create a location entry?

e-lo opened this issue · 4 comments

e-lo commented

For example: If I have a gtfs_stop_id that is at an intersection. Do I have to create a location entry in addition to the node?

ssmith55 commented

Recommend, "yes", so that gtfs_stop_id always maps to a location. It is rare to have a transit stop that is actually in the middle of an intersection (although that might be a reasonable approximation for a low resolution network)

e-lo commented

It is rare to have a transit stop that is actually in the middle of an intersection (although that might be a reasonable approximation for a low resolution network)

In practice, this is how most GTFS networks AND model networks represent stops.

Requiring transit stops to be in a location table presents an added layer of complexity for simplified networks. I suggest we discuss various options here and their implications at our next meeting.

joshchea commented

A location association with a stop id should ideally only be used if it represents something greater - i.e. a transfer hub, a shelter polygon etc. Otherwise, it would only result in data duplication as e-lo points out.

A stop in GTFS = Node because there is no underlying road network in it. However, if we consider an underlying road network, these stop locations will seldom align with an intersection. In case of TDM networks, the mid-block stop is on a dummy/shape node.

If the motivation behind using location is to represent mid-block stops without using dummy nodes, then the stop table could be augmented as follows (last three attributes would be appended to the stop table):

STOPNO | NODENO | ISONLINK | FROMNODENO | LINKNO | RELPOS

ISONLINK = (bool) | FROMNODENO, LINKNO, RELPOS populated only populated if ISONLINK = 1)

X, Y is inherited from NODENO

e-lo commented

My (personal) suggested design goals are:

  1. Not require added complexity of location table when dealing with a macro network model (transit and roadway) and one wants to easily associate a transit network defined in GTFS.

  2. Allow more rigorous and detailed definitions of transit locations if they exist.

  3. Not require any augmentation of the GTFS network files in order to represent them.

@joshchea 's suggestion is efficient, but breaks 3 which I think is important (for now)