### Install Golang GTFS-realtime Bindings

Source: https://gtfs.org/documentation/realtime/language-bindings/golang

Install the gtfs-realtime-bindings library for Golang using go get.

```bash
go get github.com/MobilityData/gtfs-realtime-bindings/golang/gtfs

```

--------------------------------

### Install Golang Protobuf Library

Source: https://gtfs.org/documentation/realtime/language-bindings/golang

Install the golang protobuf library dependency using go get.

```bash
go get google.golang.org/protobuf/proto

```

--------------------------------

### Install gtfs-realtime-bindings

Source: https://gtfs.org/documentation/realtime/language-bindings/python

Install the gtfs-realtime-bindings module using easy_install or pip.

```bash
# Using easy_install
easy_install --upgrade gtfs-realtime-bindings
```

```bash
# Using pip
pip install --upgrade gtfs-realtime-bindings
```

--------------------------------

### Install gtfs-realtime-bindings

Source: https://gtfs.org/documentation/realtime/language-bindings/nodejs

Install the Node.js npm package for GTFS-realtime bindings.

```bash
npm install gtfs-realtime-bindings

```

--------------------------------

### feed_info.txt Example

Source: https://gtfs.org/documentation/schedule/examples/feed-info

This example demonstrates the structure of the feed_info.txt file, including fields for publisher name, URL, language, validity dates, and version.

```text
feed_publisher_name,feed_publisher_url,feed_lang,feed_start_date,feed_end_date,feed_version
Transport for Cairo,http://transportforcairo.com/,en,20160101,20161201,0.5

```

--------------------------------

### Full Dataset Trip Update Feed Example

Source: https://gtfs.org/documentation/realtime/examples/trip-updates

This example demonstrates the structure of a full dataset trip update feed, including header information and multiple entity updates for different trips and stops.

```protobuf
# header information
header {
  # version of speed specification. Currently "2.0". Valid versions are "2.0", "1.0".
  gtfs_realtime_version: "2.0"
  # determines whether dataset is incremental or full
  incrementality: FULL_DATASET
  # the moment where this dataset was generated on server
  timestamp: 1284457468
}

# multiple entities can be included in the feed
entity {
  # unique identifier for the entity
  id: "simple-trip"

  # "type" of the entity
  trip_update {
    trip {
      # selects which GTFS entity (trip) will be affected
      trip_id: "trip-1"
    }
    # schedule information update
    stop_time_update {
      # selecting which stop is affected
      stop_sequence: 3
      # for the vehicle's arrival time
      arrival {
        # to be delayed with 5 seconds
        delay: 5
      }
    }
    # ...this vehicle's delay is propagated to its subsequent stops.

    # Next information update on the vehicle's schedule
    stop_time_update {
      # selected by stop_sequence. It will update
      stop_sequence: 8
      # the vehicle's original (scheduled) arrival time with a
      arrival {
        # 1 second delay.
        delay: 1
      }
    }
    # ...likewise the delay is propagated to subsequent stops.

    # Next information update on the vehicle's schedule
    stop_time_update {
      # selected by stop_sequence. It will update the vehicle's arrival time
      stop_sequence: 10
      # with the default delay of 0 (on time) and propagate this update
      # for the rest of the vehicle's stops.
    }
  }
}

# second entity containing update information for another trip
entity {
  id: "3"
  trip_update {
    trip {
      # frequency based trips are defined by their
      # trip_id in GTFS and
      trip_id: "frequency-expanded-trip"
      # start_time
      start_time: "11:15:35"
    }
    stop_time_update {
      stop_sequence: 1
      arrival {
        # negative delay means vehicle is 2 seconds ahead of schedule
        delay: -2
      }
    }
    stop_time_update {
      stop_sequence: 9
    }
  }
}

```

--------------------------------

### Loop Route Stop Times Example

Source: https://gtfs.org/documentation/schedule/schedule-best-practices

This example shows how to model a loop route by including the first/last stop twice in `stop_times.txt` to represent the complete round trip.

```text
trip_id | stop_id | stop_sequence
9000| 101| 1
9000| 102| 2
9000| 103| 3
9000| 101| 4
```

--------------------------------

### Install GtfsRealtimeBindings NuGet Package

Source: https://gtfs.org/documentation/realtime/language-bindings/dotnet

Install the GtfsRealtimeBindings module from the NuGet repository to use the generated classes in your project.

```powershell
Install-Package GtfsRealtimeBindings

```

--------------------------------

### Install GTFS-realtime Ruby Gem

Source: https://gtfs.org/documentation/realtime/language-bindings/ruby

Install the `gtfs-realtime-bindings` gem to use the GTFS-realtime classes in your Ruby project.

```bash
gem install gtfs-realtime-bindings

```

--------------------------------

### GTFS-Realtime Service Alert Example

Source: https://gtfs.org/documentation/realtime/examples/service-alerts

This example demonstrates the structure of a GTFS-Realtime service alert, including header information, active periods, affected entities, cause, effect, and translated text for URLs, headers, and descriptions.

```protobuf
# header information
header {
  # version of speed specification. Currently "2.0". Valid versions are "2.0", "1.0".
  gtfs_realtime_version: "2.0"

  # determines whether dataset is incremental or full
  incrementality: FULL_DATASET

  # the time where this dataset was generated on server
  # for determining the sequence of alert feeds
  timestamp: 1284457468
}
# multiple entities can be included in the feed
entity {
  # unique identifier for the entity
  id: "0"

  # "type" of the entity
  alert {
    # multiple periods can be defined when alert is active
    active_period {
      # start time in POSIX epoch format
      start: 1284457468
      # end time in POSIX epoch format
      end: 1284468072
    }
    # selects which GTFS entities will be affected
    informed_entity {
      # valid parameters: 
      # agency_id, route_id, route_type, stop_id, trip (see TripDescriptor)
      route_id: "219"
    }
    # multiple selectors (informed_entity) can be included in one alert entity
    informed_entity {
      stop_id: "16230"
    }
    # multiple fields can be included in one informed_entity
    informed_entity {
      stop_id: "16299"
      route_id: "100"
      # This example means route 100 at stop 16299.
      # This does not apply to any other stop on route 100 and any other route at stop 16299.
    }

    # cause of the alert - see gtfs-realtime.proto for valid values
    cause: CONSTRUCTION
    # effect of the alert - see gtfs-realtime.proto for valid values
    effect: DETOUR

    # the given url provides additional information
    url {
      # multiple languages/translations supported
      translation {
        # page hosted outside of Google (at provider/agency, etc.)
        text: "http://www.sometransitagency/alerts"
        language: "en"
      }
    }

    # header for the alert will be highlighted
    header_text {
      # multiple languages/translations supported
      translation {
        text: "Stop at Elm street is closed, temporary stop at Oak street"
        language: "en"
      }
    }

    # Alert description. Additional info to the header text
    description_text {
      # multiple languages/translations supported
      translation {
        text: "Due to construction at Elm street the stop is closed. The temporary stop can be found 300 meters north at Oak street"
        language: "en"
      }
    }
  }
}
```

--------------------------------

### GTFS Agency Data Example

Source: https://gtfs.org/documentation/schedule/examples/attributions

Example of agency.txt content showing multiple transit agencies.

```text
agency_id,agency_name,agency_url,agency_timezone,agency_lang
202,Bornholms Trafik,https://bat.dk,Europe/Berlin,da
204,FYNBUS,https://fynbus.dk,Europe/Berlin,
206,NT,https://www.nordjyllandstrafikselskab.dk,Europe/Berlin,
276,Rejseplanen,https://www.rejseplanen.dk,Europe/Berlin,
```

--------------------------------

### GTFS Attribution Data Example

Source: https://gtfs.org/documentation/schedule/examples/attributions

Example of attributions.txt content to classify an agency as a data producer.

```text
attribution_id,organization_name,attribution_url,is_producer,is_operator,is_authority
rp,Rejseplanen,https://www.rejseplanen.dk,1,,
```

--------------------------------

### Example Blocks and Service Day

Source: https://gtfs.org/documentation/schedule/reference

Demonstrates how distinct blocks can be defined for different days of the week, showing sequential trips operated by a single vehicle. This example highlights the relationship between trips, service days, and block IDs.

```text
route_id | trip_id | service_id | block_id | _(first stop time)_ | _(last stop time)_
red | trip_1 | mon-tues-wed-thurs-fri-sat-sun | red_loop | 22:00:00 | 22:55:00
red | trip_2 | fri-sat-sun | red_loop | 23:00:00 | 23:55:00
red | trip_3 | fri-sat | red_loop | 24:00:00 | 24:55:00
red | trip_4 | mon-tues-wed-thurs | red_loop | 20:00:00 | 20:50:00
red | trip_5 | mon-tues-wed-thurs | red_loop | 21:00:00 | 21:50:00
```

--------------------------------

### Example trips.txt Records

Source: https://gtfs.org/documentation/schedule/reference

Illustrates how to use trip_headsign and direction_id to assign names to travel in each direction for a set of trips. These records can be used in time tables.

```text
trip_id,...,trip_headsign,direction_id
1234,...,Airport,0
1505,...,Downtown,1
```

--------------------------------

### Example stop_times.txt for Block Transfers

Source: https://gtfs.org/documentation/schedule/examples/transfers

Shows the `stop_times.txt` data corresponding to the `trips.txt` example, detailing arrival and departure times for stops. This data, combined with `trips.txt`, allows GTFS to identify opportunities for in-seat transfers.

```text
trip_id | arrival_time | departure_time | stop_id | stop_sequence  
---|---|---|---|---
RouteATrip1 | 12:00:00 | 12:01:00 | A | 1  
RouteATrip1 | 12:05:00 | 12:06:00 | B | 2  
RouteATrip1 | 12:15:00 |  | C | 3  
RouteBTrip1 |  | 12:18:00 | C | 1  
RouteBTrip1 | 12:22:00 | 12:23:00 | D | 2  
RouteBTrip1 | 12:30:00 |  | E | 3  
```

--------------------------------

### Allowed Zone Overlap Constraint (Sequential Windows)

Source: https://gtfs.org/documentation/schedule/examples/flex

This example shows an allowed configuration where stop_times.txt records for the same trip_id have sequential, non-overlapping pickup/drop-off windows, even if geometries overlap. This is permitted.

```text
trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window  
tripA | portland | 1 | 2 | 1 | 08:00:00 | 12:00:00  
tripA | northportland | 2 | 2 | 1 | 12:00:00 | 14:00:00  
tripA | vancouver | 3 | 1 | 2 | 10:00:00 | 14:00:00  
```

--------------------------------

### Define a basic shape in shapes.txt

Source: https://gtfs.org/documentation/schedule/reference

This example shows the minimum required fields to define a shape using three points. Ensure `shape_id` is unique and `shape_pt_sequence` increases for each point.

```csv
shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence
A_shp,37.61956,-122.48161,0
A_shp,37.64430,-122.41070,6
A_shp,37.65863,-122.30839,11
```

--------------------------------

### Example trips.txt for Block Transfers

Source: https://gtfs.org/documentation/schedule/examples/transfers

Illustrates the structure of `trips.txt` to define trips belonging to the same block, enabling block transfers. Ensure `block_id` is consistent for consecutive trips served by the same vehicle.

```text
route_id | trip_id | block_id  
---|---|---
RouteA | RouteATrip1 | Block1  
RouteB | RouteBTrip1 | Block1  
```

--------------------------------

### Allowed Zone Overlap Constraint (Different Pickup/Drop-off Types)

Source: https://gtfs.org/documentation/schedule/examples/flex

This example demonstrates an allowed configuration where stop_times.txt records for the same trip_id have overlapping windows but different pickup_type or drop_off_type values, preventing a conflict. This is permitted.

```text
trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window  
tripA | portland | 1 | 2 | 1 | 08:00:00 | 12:00:00  
tripA | northportland | 2 | 1 | 2 | 10:00:00 | 14:00:00  
tripA | vancouver | 3 | 1 | 2 | 10:00:00 | 14:00:00  
```

--------------------------------

### Allowed Zone Overlap Constraint (Different Locations)

Source: https://gtfs.org/documentation/schedule/examples/flex

This example shows an allowed configuration where stop_times.txt records for the same trip_id have overlapping windows but refer to different location_ids, thus avoiding a direct overlap conflict. This is permitted.

```text
trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window  
tripA | portland | 1 | 2 | 1 | 08:00:00 | 12:00:00  
tripA | gresham | 2 | 2 | 1 | 10:00:00 | 14:00:00  
tripA | vancouver | 3 | 1 | 2 | 10:00:00 | 14:00:00  
```

--------------------------------

### Download and Parse GTFS-realtime Feed

Source: https://gtfs.org/documentation/realtime/language-bindings/java

This example demonstrates downloading a GTFS-realtime feed from a URL, parsing it into a FeedMessage object, and iterating over entities to print trip updates. Ensure your Maven repository references are set up correctly.

```java
import java.net.URL;

import com.google.transit.realtime.GtfsRealtime.FeedEntity;
import com.google.transit.realtime.GtfsRealtime.FeedMessage;

public class GtfsRealtimeExample {
  public static void main(String[] args) throws Exception {
    URL url = new URL("URL OF YOUR GTFS-REALTIME SOURCE GOES HERE");
    FeedMessage feed = FeedMessage.parseFrom(url.openStream());
    for (FeedEntity entity : feed.getEntityList()) {
      if (entity.hasTripUpdate()) {
        System.out.println(entity.getTripUpdate());
      }
    }
  }
}
```

--------------------------------

### Define Station and Entrances in stops.txt

Source: https://gtfs.org/documentation/schedule/examples/pathways

Use `location_type` to distinguish between a station (1) and its entrances (2). Associate entrances with the parent station using `parent_station`. Indicate wheelchair accessibility with `wheelchair_boarding` (1 for accessible, 2 for not).

```csv
stop_id,stop_name,stop_lat,stop_lon,location_type,parent_station,wheelchair_boarding
12034,Waterfront Station,49.285687,-123.111773,1,,
90,Waterfront Station Stairs Entrance on Granville,49.285054,-123.114375,2,12034,2
91,Waterfront Station Escalator Entrance on Granville,49.285061,-123.114395,2,12034,2
92,Waterfront Station Elevator Entrance on Granville,49.285257,-123.114163,2,12034,1
93,Waterfront Station Entrance on Cordova,49.285607,-123.111993,2,12034,1
94,Waterfront Station Entrance on Howe,49.286898,-123.113367,2,12034,2
```

--------------------------------

### Download and Parse GTFS-realtime Feed in Ruby

Source: https://gtfs.org/documentation/realtime/language-bindings/ruby

Demonstrates downloading a GTFS-realtime data feed from a URL, parsing it into a `FeedMessage` object, and iterating over entities to print trip updates. Ensure you replace "URL OF YOUR GTFS-REALTIME SOURCE GOES HERE" with your actual feed URL.

```ruby
require 'protobuf'
require 'google/transit/gtfs-realtime.pb'
require 'net/http'
require 'uri'

data = Net::HTTP.get(URI.parse("URL OF YOUR GTFS-REALTIME SOURCE GOES HERE"))
feed = Transit_realtime::FeedMessage.decode(data)
for entity in feed.entity do
  if entity.field?(:trip_update)
    p entity.trip_update
  end
end

```

--------------------------------

### Update Composer Dependencies

Source: https://gtfs.org/documentation/realtime/language-bindings/php

After adding the dependency to `composer.json`, run `composer update` to download and install the package.

```bash
composer update
```

--------------------------------

### Download and Parse GTFS-realtime Feed in Golang

Source: https://gtfs.org/documentation/realtime/language-bindings/golang

Demonstrates downloading a GTFS-realtime data feed from a URL, parsing it into a FeedMessage struct, and iterating over the entities. Ensure you replace placeholder values for username, password, and the feed URL.

```go
package main

import (
    "fmt"
    "google.golang.org/protobuf/proto"
    "github.com/MobilityData/gtfs-realtime-bindings/golang/gtfs"
    "io/ioutil"
    "log"
    "net/http"
)

func main() {
    var (
        username = "YOUR_ACCESS_KEY"
        password = "YOUR_SECRET_KEY"
    )

    client := &http.Client{}
    req, err := http.NewRequest("GET", "URL OF YOUR GTFS-REALTIME SOURCE GOES HERE", nil)
    req.SetBasicAuth(username, password)
    resp, err := client.Do(req)
    defer resp.Body.Close()
    if err != nil {
        log.Fatal(err)
    }
    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        log.Fatal(err)
    }

    feed := gtfs.FeedMessage{}
    err = proto.Unmarshal(body, &feed)
    if err != nil {
        log.Fatal(err)
    }

    for _, entity := range feed.Entity {
        tripUpdate := entity.GetTripUpdate()
        trip := tripUpdate.GetTrip()
        tripId := trip.GetTripId()
        fmt.Printf("Trip ID: %s\n", tripId)
    }
}

```

--------------------------------

### TimeRange Message

Source: https://gtfs.org/documentation/realtime/reference

Represents a time interval. The interval is considered active at time `t` if `t` is greater than or equal to the start time and less than the end time.

```APIDOC
## TimeRange Message

### Description
A time interval. The interval is considered active at time `t` if `t` is greater than or equal to the start time and less than the end time.

### Fields
- **start** (uint64) - Conditionally required - Start time, in POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC). If missing, the interval starts at minus infinity. If a TimeRange is provided, either start or end must be provided - both fields cannot be empty.
- **end** (uint64) - Conditionally required - End time, in POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC). If missing, the interval ends at plus infinity. If a TimeRange is provided, either start or end must be provided - both fields cannot be empty.
```

--------------------------------

### Configure Continuous Stops Everywhere in routes.txt

Source: https://gtfs.org/documentation/schedule/examples/continuous-stops

Use `continuous_pickup` and `continuous_drop_off` fields set to '0' in routes.txt to allow riders to be picked up or dropped off at any safe location along the route.

```text
route_id,route_short_name,route_long_name,route_type,continuous_pickup,continuous_drop_off
2,2,Bellows Falls In-Town,3,0,0
53,53,Bellows Falls / Battleboro Commuter,3,0,0
55,55,Bellows Falls / Springfield Shuttle,3,0,0
```

--------------------------------

### Circular Trip with Two Headsigns

Source: https://gtfs.org/documentation/schedule/schedule-best-practices

This example demonstrates a circular trip where `stop_headsign` is used to indicate two distinct directions ('outbound' and 'inbound') along the route.

```text
trip_id | arrival_time | departure_time | stop_id | stop_sequence | stop_headsign
trip_1 | 06:10:00 | 06:10:00 | stop_A | 1 | "outbound"
trip_1 | 06:15:00 | 06:15:00 | stop_B | 2 | "outbound"
trip_1 | 06:20:00 | 06:20:00 | stop_C | 3 | "outbound"
trip_1 | 06:25:00 | 06:25:00 | stop_D | 4 | "inbound"
trip_1 | 06:30:00 | 06:30:00 | stop_E | 5 | "inbound"
trip_1 | 06:35:00 | 06:35:00 | stop_F | 6 | "inbound"
trip_1 | 06:40:00 | 06:40:00 | stop_A | 7 | ""
```

--------------------------------

### Define Zone (GeoJSON Locations)

Source: https://gtfs.org/documentation/schedule/examples/flex

A simplified GeoJSON example defining the operational zone for Brown County, used to specify geographic boundaries for demand-responsive services.

```json
{
  "type": "FeatureCollection",
  "features": [
    {
      "id": "area_708",
      "type": "Feature",
      "geometry": {
        "type": "Polygon",
        # Simplified, only presenting 3 coordinates here.
        "coordinates": [
          [
            [
              -94.7805702,
              44.4560958
            ],
            [
              -94.7805608,
              44.4559928
            ],
            [
              -94.7805218,
              44.4559649
            ]
          ]
        ]
      },
      "properties": {}
    }
  ]

}
```