Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocks and service days - Clarify relationship of block_id & service_id #44

Merged

Conversation

antrim
Copy link
Contributor

@antrim antrim commented Jan 22, 2017

It was previously unclear how a block can be defined across service days.

New/added text: "A block consists of a single trip or or many sequential trips made using the same vehicle, defined by shared service day and block_id."

Removed: "The block_id must be referenced by two or more trips in trips.txt."

Note: This proposed change introduces the term of "service day" (see #43 for discussion).

@barbeau
Copy link
Collaborator

barbeau commented Jan 26, 2017

I think this definition works. Small typo - of a single trip or or many should be of a single trip or many (there is an extra or).

@antrim
Copy link
Contributor Author

antrim commented Jan 27, 2017

Thanks @barbeau! Fixed in f64f770

@antrim
Copy link
Contributor Author

antrim commented Jan 27, 2017

It looks as though there is support for this change. Let's start the 7 day voting period for this change, unless anyone has other comments. So that there are 7 full calendar days, then the vote would end on Friday, February 3 @ 23:59:59 UTC.

I’m not in love with the formatted example, but I don’t know how better to do this in markdown and in the current document structure. Therefore, I propose that we get block_id definition written into the Spec reference, and leave the door open for reformat/restructure later.

@barbeau
Copy link
Collaborator

barbeau commented Jan 27, 2017

+1

2 similar comments
@LeoFrachet
Copy link
Contributor

+1

@abyrd
Copy link

abyrd commented Jan 30, 2017

+1

@antrim
Copy link
Contributor Author

antrim commented Feb 4, 2017

The voting period has ended. It looks as though there is support for this change. @zhsh: Can you please merge and close? We may want to do a little formatting rearrangement (for the example table) down the line.

@dbabramov dbabramov merged commit 97e8920 into google:master Feb 7, 2017
@barbeau
Copy link
Collaborator

barbeau commented Feb 7, 2017

@dbabramov Thanks for merging! Friendly request - in the future, could you please squash commits before merging? Github web UI let's you easily do this. I think it's useful to keep a multiple-commit history in a pull request so we can track changes based on comments, but personally I'd prefer to keep the history of the master branch clean with one commit per proposal. Makes it easier to track proposals and changes over time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GTFS Schedule Issues and Pull Requests that focus on GTFS Schedule
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants