transfers.txt stop pairs must be unique
Aaron Antrim
this week. This feedback indicated that stop pairs in transfers.txt
must be unique. In other words, the following transfers.txt would be
invalid:
from_stop_id,to_stop_id,transfer_type,min_transfer_time
STOPA,STOPB,0,
STOPA,STOPB,1,
Earlier, I had assumed that preferred and guaranteed timed transfers
could be set separately. However, it does not seem this is the case.
Setting preferred and guaranteed timed transfers wouldn't seem to be
very useful anyway.
I suggest that the GTFS should include an additional sentence to
specify this: "Only one transfer type can be specified for a stop pair."
Joe Hughes
of existing systems. Are there spec users that object to this
proposal?
Joe
Frank
from_stop_id,to_stop_id,transfer_type,min_transfer_time
S6,S7,2,300
S7,S6,3,
...maybe slightly rewording Aaron's suggestion to, "Only one transfer
type can be specified for an ordered stop pair." (eg: hoping to
communicate that the order of the stop pair has its own uniqueness).
Aaron Antrim
Tom Brown
David Hodge
Tom Brown
backwards compatibility with the constraint "Only one transfer type
can be specified for an ordered stop pair" will be difficult. For
example, if the proposals to add from_route_id and to_route_id are
accepted it should be okay to list the same ordered stop pair multiple
times with different route_id constraints and transfer types. I'm
extending this proposal to say:
Only one transfer type can be specified for an ordered stop pair. When
reading transfers.txt ignore rows that contain values for unknown
columns because they may limit the applicability of a transfer.
Joe Hughes
I'm not sure that it's a good idea to say "ignore rows for which
unknown columns have values", since it would seem to break
extendability. In general, you want to be able to add annotations for
existing rows, but this would make it possible to make your
transfers.txt unreadable to an old parser via any future extension,
because you'd get in a situation where you'd ignore all the rows.
Joe Hughes
Google
> You received this message because you are subscribed to the Google Groups "Google Transit Feed Spec Changes" group.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.
>
>
>
Tom Brown
On Wed, Dec 30, 2009 at 9:35 AM, Tom Brown <tom.bro...@gmail.com> wrote:I'm not sure that it's a good idea to say "ignore rows for which
> While it is good to document current practice in this case maintaining
> backwards compatibility with the constraint "Only one transfer type
> can be specified for an ordered stop pair" will be difficult. For
> example, if the proposals to add from_route_id and to_route_id are
> accepted it should be okay to list the same ordered stop pair multiple
> times with different route_id constraints and transfer types. I'm
> extending this proposal to say:
>
> Only one transfer type can be specified for an ordered stop pair. When
> reading transfers.txt ignore rows that contain values for unknown
> columns because they may limit the applicability of a transfer.
unknown columns have values", since it would seem to break
extendability. In general, you want to be able to add annotations for
existing rows, but this would make it possible to make your
transfers.txt unreadable to an old parser via any future extension,
because you'd get in a situation where you'd ignore all the rows.
Arno Eigenwillig
Here is another thought on the issue (which we will probably meet
again in pathways.txt).
How about we give each row a chance to declare how much a
GTFS-consumer needs to understand of its key columns so that it can be
used safely?
One way to to this is to add a column min_required_key_column_names,
which contains a whitespace-separated list of column names. For each
row, the GTFS-consumer checks if it knows all the columns. If no, it
ignores this row. If yes, it processes this row. Among the processed
rows, each key value must be unique.
This is different from just looking at which columns are used in each row:
- There is no longer a problem with a new attribute column (like
wheelchair_accessible, which is not involved in deciding if a row
applies to a certain transfer): it's just never included in
min_required_key_column_names.
- Requiring less columns than used allows graceful fallback.
Imagine a hypothetical extension of transfers.txt by start_time and
end_time that declare a min_transfer_time record to be applicable only
during certain hours of the day, possibly to require longer transfer
durations during crowded rush hours. The usual min_transfer_time that
holds for most of the day can have min_required_key_column_names =
"from_stop_id to_stop_id" so that older consumers use just this row;
the other rows get min_required_key_column_names = "from_stop_id
to_stop_id start_time end_time" so that they are only processed by
consumers that can handle start and end times.
A disadvantage of this idea is its verbosity. Therefore I like the
following variant better: Have a column min_required_key_columns for
the *number* of key columns a GTFS-consumer must know before
processing a row. The consumer, written for GTFS as it was at one
time, must enumerate the columns specified by GTFS at that time and
count how many of them appear in the table header. If the consumer
finds less than min_required_key_columns, it does not process the row.
For making columns optional, this is less flexible than
min_required_key_column_names described above, because a feed using
new columns from two successive extensions of GTFS cannot make the
first set of new columns optional but the second set required. But
counting the number of columns present in the table is still more
flexible than a "version number", because it works in our setting of a
base spec with proposed extensions on top, each of which may be
incorporated into the base spec at an unpredictable time after feed
producers and consumers have started to use it.
What do you think?
Arno Eigenwillig, Google
--
Google Switzerland GmbH
David Turner
> Hi
>
> Here is another thought on the issue (which we will probably meet
> again in pathways.txt).
>
> How about we give each row a chance to declare how much a
> GTFS-consumer needs to understand of its key columns so that it can be
> used safely?
This seems likely to work well for feed consumers, but to be quite
confusing for feed producers. Not for any fundamental reason -- it's
just that the new column requires a lot of thought to use correctly.
I don't immediately see a better option other than telling feed
consumers that they had better keep up with the spec.
Tom Brown
I don't immediately see a better option other than telling feed
consumers that they had better keep up with the spec.
David Turner
> On Thu, Apr 1, 2010 at 5:26 PM, David Turner <nov...@novalis.org>
> wrote:
> I don't immediately see a better option other than telling
> feed
> consumers that they had better keep up with the spec.
>
> This isn't just about consumers that fell behind the latest version of
> the spec. Feed producers have no way to include data with an
> experimental key column in an existing feed.
>
> How about the following, it isn't pretty: A key column either is one
> of the existing key columns or has a column name starting with key_.
> If a consumer parses a row with a value in an unknown key column the
> row is skipped.
So, as an example, for transfers.txt, a new column might be
key_wheelchair_accesssible. Then a value of empty would indicate that
this row should be applied by consumers that don't understand
key_wheelchair_accessible, while any other value would only be used by
feeds that do understand the column.
Is this correct?
Tom Brown
Arno Eigenwillig
On 2 April 2010 02:26, David Turner <nov...@novalis.org> wrote:
>> How about we give each row a chance to declare how much a
>> GTFS-consumer needs to understand of its key columns so that it can be
>> used safely?
>
> This seems likely to work well for feed consumers, but to be quite
> confusing for feed producers. Not for any fundamental reason -- it's
> just that the new column requires a lot of thought to use correctly.
Yes and no... It is probably tricky to write code for filling
min_required_key_columns with values that use its full power to
specify intelligent fallbacks. But the proposal also supports less
tricky uses:
- min_required_key_columns refers to the number of key columns in the
table that the consumer knows. A feed producer can just set it to the
same value in each row, namely the number of key columns it has put in
the table. That's easy to determine statically, but already more
flexible than fixed version numbers.
- The new column is optional, even in the presence of more key columns
than we have today. A feed producer can just omit it to do what you
proposed:
> telling feed consumers that
> they had better keep up with the spec.
Likewise, feed consumers can ignore the column if they know their feed
providers well enough.
In this way, we do not put a burden on producers/consumers who feel
they do not need it, but provides a common language for those who do.
Arno Eigenwillig
>> > How about the following, it isn't pretty: A key column either is one
>> > of the existing key columns or has a column name starting with key_.
>> > If a consumer parses a row with a value in an unknown key column the
>> > row is skipped.
>>
>> So, as an example, for transfers.txt, a new column might be
>> key_wheelchair_accesssible. Then a value of empty would indicate that
>> this row should be applied by consumers that don't understand
>> key_wheelchair_accessible, while any other value would only be used by
>> feeds that do understand the column.
>>
>> Is this correct?
>
> Yes, for consumers that don't understand key_wheelchair_accessible.
> How consumers that do understand key_wheelchair_accessible interpret a row
> with an empty key_wheelchair_accessible value depends on the extension. The
> extension could specify that key_wheelchair_accessible must have a value
> (other than rows present for backwards compatibility) or the extension could
> specify that an empty value is equivalent to accessibility-unknown. You
> suggest the former, which is reasonable.
wheelchair_accessible is an easy case, because feed consumers ignorant
about it always want the "default"/"no wheelchair" case.
I don't see clear yet how this would work out for extensions that do
not allow such a simple fallback rule, and how it works out for
combinations of such extensions. My gutfeel says: the complexity that
becomes explicit in my attempt to define min_required_key_columns will
arise here as well, but through the backdoor of how the various
extensions interact with their policies on default and fallback
values.
Venjense
the stop location (station, platform, street) is ADA accessible
(Partial, Fully, Vehicle provides lift, etc) then the transfer would
be viable to that level of ADA compliance i.e. fully wheelchair
accessible, partially on a platform with ramps, or not at all.
If I needed to travel via a stop where the transfer exist only at that
stop location, I would have an option to look for ADA capable trips
based on data about the stop locations.
Granted, more things would have to be added to the stops.txt
specification but it seems as though the transfers.txt speaks more to
the point that if a route can make a transfer to another route.
/2cents
On Apr 14, 5:14 am, Arno Eigenwillig <arnoegw.c...@gmail.com> wrote:
>
>
>
>
>
> >> > How about the following, it isn't pretty: A key column either is one
> >> > of the existing key columns or has a column name starting with key_.
> >> > If a consumer parses a row with a value in an unknown key column the
> >> > row is skipped.
>
> >> this row should be applied by consumers that don't understand
> >> key_wheelchair_accessible, while any other value would only be used by
> >> feeds that do understand the column.
>
> >> Is this correct?
>
> > Yes, for consumers that don't understand key_wheelchair_accessible.
> > How consumers that do understand key_wheelchair_accessible interpret a row
> > with an empty key_wheelchair_accessible value depends on the extension. The
> > extension could specify that key_wheelchair_accessible must have a value
> > (other than rows present for backwards compatibility) or the extension could
> > specify that an empty value is equivalent to accessibility-unknown. You
> > suggest the former, which is reasonable.
>
> wheelchair_accessible is an easy case, because feed consumers ignorant
> about it always want the "default"/"no wheelchair" case.
>
> I don't see clear yet how this would work out for extensions that do
> not allow such a simple fallback rule, and how it works out for
> combinations of such extensions. My gutfeel says: the complexity that
> becomes explicit in my attempt to define min_required_key_columns will
> arise here as well, but through the backdoor of how the various
> extensions interact with their policies on default and fallback
> values.
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.