Thoughts on modeling station interiors and detailed walking instructions
Arno Eigenwillig
The discussion on pedestrian pathways in stations from February and
March inevitably brought up the question: Why don't we model a
station's interior and generate detailed, step-by-step walking
instructions? Obviously, this is highly desirable for trip planners,
because complex stations are hard to naviagte with simple end-to-end
instructions ("follow the signs labeled 'X' to exit 'Y'"), and already
not-so-complex stations are hard to navigate for visually impaired
passengers. In addition, drawing station diagrams was stated as a
useful application of such data.
Below, I would like to share some thoughts on how this could be done.
However, all of this is quite speculative, because data of this
quality seems to be mostly unavailable (nonwithstanding Kevin
Branigan's effort for myttc), and feed consumers will have to invest
quite a bit before they can fully utilize it. Therefore, I'll spend
most of my available time to iterate on my concrete proposal for
"entrances and simple pathways" (see other thread) and less time on
this. Anyway, having said that:
To match GTFS's emphasis on trip planning, walking in a station should
be represented as a graph, with nodes that stand for locations and
arcs that stand for walking from one location to another. Arcs should
be directed, because many things are naturally one-way (escalators,
fare gates), and even for two-way connections, traversal time
(upstairs vs downstairs) and descriptions ("follow signs saying 'X')
will often be different. Big geometric objects, such as floors or
platforms, should be an attribute shared by a group of nodes. Having
a single node for a platform hundred meters long is not an option,
because it precludes proper representation of walking distances from
stairs at one end to the elevator in the middle or to the stairs at
the other end. Therefore, stops should appear in this walking graph
only as source or sink nodes: walking into a stop means waiting to
board a vehicle.
We cannot rely on free-format English descriptions of walking arcs,
because concatenating them cleanly is hard. It is even harder to
generate spoken descriptions (for the visually impaired) or
translations (for feed consumers with an internationalized UI).
Instead, all the descriptive data has to be encoded in the data with
many descriptive types for arcs (maybe not so much nodes), such as
"walk across a station floor", "take an elevator/escalator/staircase
up/down", etc. Arcs should be able to designate a continuation arc to
encode that a sequence of arcs represents a tunnel that continues past
points where stairs branch off, likewise for elevators across multiple
floors, to avoid descriptions like "Walk the tunnel (15ft). Continue
straight on and walk the tunnel (12ft)" and so on.
This means that arcs will correspond closely to geometric structures
within a station (a flight of stairs, an escalator, etc.). This also
blends very well with extensions to model operating hours of
escalators and the like.
However, it has a subtle yet important consequence with regard to the
"upgrade path" from the simple pathways from the other thread to the
walking arcs described here: They don't mix well. At first sight, you
could think (certainly, I did think): end-to-end pathways from
entrances to stops are just the special case of one arc, or step, in a
multi-step pathway. This is not the case, because they are shortcuts
across what should have been several nodes and arcs in a proper model
of the station, hence feed consumers will have to treat them quite
differently, and should even avoid them when a step-by-step connection
is available instead. Therefore, it makes little sense to anticipate
one common table for the simple end-to-end pathways and the arcs of a
future multi-step walking model. It makes *some* sense to keep an eye
on these future directions and design end-to-end pathways in a way
that does not lead us into too much of a conceptual mismatch with
these future extensions, but since we cannot know their details for
sure right now, we should not block ourselves on that.
Arno Eigenwillig, Google Transit
--
Google Switzerland GmbH
Nicholas Albion
this concept. It's used primarily for turn-by-turn driving
instructions, but could be adapted for step-by-step walking
instructions. It uses re-usable legs - two nearby platforms may share
the same corridor to the main foyer, for example.
It's unlikely that anyone would use it this decade, but it might be
cool to have an optional link to a SketchUp/COLLADA model in stops.txt
tompw
> ...
> encode that a sequence of arcs represents a tunnel that continues past
> points where stairs branch off, likewise for elevators across multiple
> floors, to avoid descriptions like "Walk the tunnel (15ft). Continue
> straight on and walk the tunnel (12ft)" and so on.
>
> This means that arcs will correspond closely to geometric structures
> within a station (a flight of stairs, an escalator, etc.). This also
> blends very well with extensions to model operating hours of
> escalators and the like.
it would probably be better to use the standard term 'edges' rather
than 'arcs']
What I think will be needed is some way of grouping arcs/edges
together to reflect the fact they are part of larger stucture, in a
similar way to the parent_station concept that already exists. This
would mean having some sort of edge_group_id (while it would be nice
to just to use the first and last nodes to define the parent, the
parent 'edge' may not be a simple line of nodes and edges). This might
require a bit of a mind shift, because all of GTFS is done in terms of
nodes (and collections thereof).
Another point is that generating useful walking directions requires
moving beyond just providing topological descriptions into the realm
of providing geometric information. One cannot say "walk along
passageway 123 to the junction, then along passway 456" - some sort of
left/right/straight ahead guidance is needed. It would sometimes be
possible for the feed consumer to do this (if you know where the nodes
are, then it may be possible to work out left/right/etc.), but it easy
to draw up situations why it is impossible to do automatically.
Therefore, for each node with more than two edges, one would would
need to specify the turn direction for each pair of nodes connected to
it. (n edges => n(n-1) directions, or n^2 with u-turns included).
Finally, this doesn't have to be resticted to transit stations - any
pedestrianised area without labelled pathways would benefit from this.
Arno Eigenwillig
> [Fussy point: if we're giong to talk about things in terms of graphs,
> it would probably be better to use the standard term 'edges' rather
> than 'arcs']
If only there was a single standard... 'Arcs' certainly conveys that
I am talking about directed edges, but I do not insist.
> Another point is that generating useful walking directions requires
> moving beyond just providing topological descriptions into the realm
> of providing geometric information. One cannot say "walk along
> passageway 123 to the junction, then along passway 456" - some sort of
> left/right/straight ahead guidance is needed. It would sometimes be
> possible for the feed consumer to do this (if you know where the nodes
> are, then it may be possible to work out left/right/etc.), but it easy
> to draw up situations why it is impossible to do automatically.
> Therefore, for each node with more than two edges, one would would
> need to specify the turn direction for each pair of nodes connected to
> it. (n edges => n(n-1) directions, or n^2 with u-turns included).
If we equip each edge with its orientations (headings) at its
endpoints (not necessarily the same at both endpoints for curved
edges), we can do with n numbers per node.
On the other hand, a separate table to annotate each pair of incoming
and outgoing edge at some node would also be quite useful to represent
descriptions or costs of turns.
Arno
--
Google Switzerland GmbH