Data structure and description of Trip_Id, Service_Id, vehicle_id


#1

I real technical specs but I couldn’t find any document how these ids have been encoded for all transport modes along with all constant values ( there are some descriptions for serviceId and tripId but the descriptions are not consistent with actual feed data for all transport modes)
Could you please let me know how can I find exact business meaning of each part of these IDs.


#2

Hi @mkhezrian, have you reviewed each of the technical docs for each real-time feed at https://opendata.transport.nsw.gov.au/documentation for Sydney Trains, Buses, Ferries etc?
Each feed is produced by the relevant operator, and each may use different systems to mange their data, so there will not be consistency across all modes.
Let me know if there is something in particular you are looking for.


#3

Thanks for your response. Yes I did. By consistency I meant, consistency of specs titles and contents and structure of specs for all modes.

  • NSW_Realtime_Train_Technical_Doc.pdf : It only has descriptions on some fields of Trips and Agency and Alerts. Nothing about real-time table fields and the rest of Bundle tables.
  • NSWTrains_4trak_Technical.pdf : This one is the most complete one in terms of table and fields coverage. But still you can find anything about mentioned IDs data structure.
    I f you have a look at other specs: “TfNSW_Realtime_Train_Technical_Doc.pdf, TfNSW_Realtime_Bus_Technical_Doc.pdf” it makes you more confused in terms of document structure and content. Just as an instance here is “route_id” explanation in TfNSW_Realtime_Bus_Technical_Doc.pdf:
    The route__id field contains an ID that uniquely identifies a route. The route__id is dataset unique.
    Constructed as “(CONTRACT ID)(ROUTE ID)”_ What is contract ID? RoutId = ContractId_RouteId !?
    For example: “2447__10A”the actual data is something like:21-S9-sj2-1

That would be great if you can let me know the business meaning of Trip_id, SeviceId, VehicleId, Route_Id and ShapeId (These are all composite keys that are aggregation of a number of properties that are not clear in all modes)


#4

Point taken regarding the format of each of the documents, they have been produced incrementally as each feed was developed. They are more consistent than they used to be, and we are still working on it, please bear with us :slight_smile:

The id 21-S9-sj2-1 is an example from the Complete GTFS bundle: https://opendata.transport.nsw.gov.au/dataset/timetables-complete-gtfs. The relevant documentation for this bundle is here: https://opendata.transport.nsw.gov.au/sites/default/files/TfNSW_GTFS_release_notes.pdf
The format of that ID is defined by the scheduling software and goes something like “OperatingBranch-RouteNumber-Instance-RouteVersion”. In general these values (apart from RouteNumber) aren’t that meaningful for consumers so they haven’t been defined in the technical documentation.

TfNSW_Realtime_Bus_Technical_Doc.pdf relates to the For Real-Time GTFS bundles for buses: https://opendata.transport.nsw.gov.au/dataset/public-transport-timetables-realtime