Allow multiple feed entity types in a single feed

[egorich239]

It has been discussed several times in the mailing list [1][2] that the limitation on single feed entity type per feed is artificial and can be removed.

I propose to reflect this in the GTFS RT Specification.

[1] https://groups.google.com/d/msg/gtfs-realtime/_HtNTGp5LxM/VvDLkV4wTnAJ
[2] https://groups.google.com/forum/#!topic/gtfs-realtime/VCKRVEWZbUE

[magdalar]

This whole paragraph/list reads strangely; perhaps it should just be removed?

[egorich239]

I agree, we should probably drop this paragraph.

[skinkie]

Should we add a tool for this change that can convert merged into unmerged and back?

[egorich239]

@skinkie I don't think it belongs to the specification. On top of that, such a tool is on one side trivial, but on the other side, implementation in every language supported by, say, gtfs-realtime-bindings takes a significant effort.
Having said that, if you choose to publish such a tool in a language of your choice somewhere (say, at github.com/skinkie), I will happily refer to it somewhere in the related documentation chapters.

[skinkie]

The more I think about such too the more problems I have with the wording of the proposal. I want to know exactly: would it be allowed to have one single entity containing all three messages within that same entity? That is going be a nightmare. This is exactly why I think a proposal should contain an implementation.

Question: should a single entity contain just one type? Where a feed may contain multiple entities of different types.

[egorich239]

@skinkie It is currently disallowed to have more than one kind of sub-message in single entity. This proposal does not change that restriction: https://github.com/google/transit/blob/egorich239-multifeeds/gtfs-realtime/proto/gtfs-realtime.proto#L95-96

[egorich239]

@skinkie It is also possible with recent proto2 to express such oneof restriction in the proto language itself (https://developers.google.com/protocol-buffers/docs/proto#oneof-features) however this may lack proto-compilers support for some languages, and be not compile-backward-compatible for the others. Thus while I'd personally love to see syntactic oneof happen, I haven't explored whether it implies non-zero migration cost for consumers, and would for now stay with https://github.com/google/transit/blob/egorich239-multifeeds/gtfs-realtime/proto/gtfs-realtime.proto#L95-96

[skinkie]

I guess that would make a nice second pull request.

[egorich239]

@skinkie Probably. Really depends, on proto-compilers support for https://github.com/google/gtfs-realtime-bindings#supported-languages

[skinkie]

This is our backwards compatibility?

https://github.com/bliksemlabs/gtfsrt-examples/blob/master/split_by_entitytype.py

[egorich239]

@skinkie For non-incremental, yes.

For incremental (oh god, let's not deep dive into this topic in this PR), deleted should probably go into all split feeds, because we don't know what kind of entity it had been before that.

[barbeau]

+1

[skinkie]

@egorich239 fixed that for you.

[egorich239]

@magdalar Removed the paragraphs about external configuration.
@skinkie Added link to your script to feed-entities.md

[abyrd]

I am in favor of the pull request as currently worded. I do find the requirement to create a separate feed per entity type to be somewhat artificial, and agree that it should be removed.

[magdalar]

LGTM

[egorich239]

I want to call a vote. I think I've addressed the above mentioned concerns, and the last week should be enough for the discussions on the topic. The vote will end on 13.08.2015 23:59:59 UTC.

Quick reminder on the voting rules (from https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md)

• During voting period only editorial changes to the proposal are allowed (typos, wording may change as long as it does not change the meaning).
• Anyone is allowed to vote yes/no in a form of comment to the pull request, and votes can be changed until the end of the voting period. If a voter changes her vote, it is recommended to do it by updating the original vote comment by striking through the vote and writing the new vote.
  Votes before the start of the voting period are not considered.

[skinkie]

Yes.

[magdalar]

Yes

[abyrd]

Yes.

[barbeau]

Yes