Vehicle positions - conscutive trips

[Pavel Pavlov]

Hi everyone,
We are facing an issue posting vehicle position updates for upcoming trips.
What this means is that if a vehicle is currently operating a trip, and has an upcoming trip, it would be great if we could post its position for both of these trips. The implications of this are that customers are unable to see realtime updates in case they are offered a journey that has not yet began, but the vehicle that is to be operating it is currently on another one. 

We are getting validation issues - duplicate vehicle ids when trying to post vehicle data for both trips, which was to be expected. However, we are hoping that there is some sort of a workaround for this as it would be great to not have these realtime 'gaps' in the feed.

Apologies if this has already been discussed and I haven't found it.

Kind regards,
Pavel Pavlov @ Theoremus.

[Stefan de Konink]

On Friday, May 26, 2023 1:39:40 PM CEST, Pavel Pavlov wrote:
> Apologies if this has already been discussed and I haven't found it.

The best way to facilitate this would be block_ids.

--
Stefan

[Tim Millet]

You may also allow real-time propagation to successive trips by defining trip transfers in transfers.txt with transfer_type=4 or 5. 
More details: https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#linked-tripshttps://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#linked-trips

Best,

Tim Millet

Transit Data Analyst, Lead

Transit

--
You received this message because you are subscribed to the Google Groups "GTFS Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/b069bf64-270a-466b-9bc5-8a175c9c3a5e%40konink.de.

[Pavel Pavlov]

@Stefan
Blocks ids would work, but are slightly different from our use case as you cannot stay on board between sequential trips.
@Tim
This is perfectly covered by transfer type 5, with re-boarding. However, the last I checked, transfer types 4 and 5 are currently not supported by google.
https://developers.google.com/transit/gtfs/reference#transferstxt

It might be that this is outdated?

[Stefan de Konink]

On Monday, May 29, 2023 2:40:03 PM CEST, Pavel Pavlov wrote:
> @Tim
> This is perfectly covered by transfer type 5, with re-boarding. However,
> the last I checked, transfer types 4 and 5 are currently not supported by
> google.
> https://developers.google.com/transit/gtfs/reference#transferstxt
>
> It might be that this is outdated?

Could we maybe agree on that "something is not supported Google" is not the
baseline for the correct use of this standard?

--
Stefan

[Pavel Pavlov]

@Stefan
In theory, you are right.

However, for our business case particularly, google maps is the baseline as the majority of clients in our local realm use this.

[Stefan de Konink]

On Monday, May 29, 2023 7:26:37 PM CEST, Pavel Pavlov wrote:
> @Stefan
> In theory, you are right.
>
> However, for our business case particularly, google maps is the baseline as
> the majority of clients in our local realm use this.

So will Google block your data if you use features they do not support?

--
Stefan

[Bodo Minea]

No, they won't block the data, they just ignore the fields/features they do not support if my experience is anything to go by (and that's the case for transfer types 4 and 5).

Unfortunately I don't think there's any way to correctly represent what @Pavel is attempting with Google's current limitations. I have also ran into this exact issue. The new transfer types are not supported and the block_id definition implies not only an internal link between trips but also the "remain on board" message when transferring. Therefore, I believe the correct way to put this into your feed going forward is defining transfer_type=5 in the eventuality that they'll support it in the future and just represent future trips of a vehicle with trip updates in advance (eg. showing the known schedule adherence by keeping internal track of what would be the "block"). Of course, this will not show the vehicle for the following trips but at least seeing the "green" indication will reassure the users.

This is not the only spec defined feature that Google omits from their system that I believe detracts from the user experience. The fact that there is no support for specifying a dynamic wheelchair_accessible through GTFS realtime, no way to define the shape (eg. through the spec defined encoded_polyline) for real time added trips (very useful in case of a detour).

It's unfortunate that the most popular GTFS consuming app has to maintain a list of differences from the spec (https://developers.google.com/transit/gtfs-realtime/reference/difference-gtfs-transit-implement and https://developers.google.com/transit/gtfs/reference/difference-gtfs-transit-implement) but we kinda have to deal with it.

Have a nice day everyone :)

Best regards,

Bogdan.

--
You received this message because you are subscribed to the Google Groups "GTFS Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/ad973032-f07e-4fa6-9506-7d9cdee8b785%40konink.de.