Skip to content

Commit 2e6887e

Browse files
author
scmcca
committed
[Formatting fix] Add newlines before lists
Improved syntax for different markdown parsers
1 parent 0033573 commit 2e6887e

File tree

1 file changed

+4
-0
lines changed

1 file changed

+4
-0
lines changed

gtfs/spec/en/reference.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,7 @@ This section defines terms that are used throughout this document.
4545

4646
### Presence
4747
Presence conditions applicable to fields and files:
48+
4849
* **Required** - The field or file must be included in the dataset and contain a valid value for each record.
4950
* **Optional** - The field or file may be omitted from the dataset.
5051
* **Conditionally Required** - The field or file must be included under conditions outlined in the field or file description.
@@ -70,6 +71,7 @@ Presence conditions applicable to fields and files:
7071

7172
### Field Signs
7273
Signs applicable to Float or Integer field types:
74+
7375
* **Non-negative** - Greater than or equal to 0.
7476
* **Non-zero** - Not equal to 0.
7577
* **Positive** - Greater than 0.
@@ -363,6 +365,7 @@ Primary key (`from_stop_id`, `to_stop_id`, `from_trip_id`, `to_trip_id`, `from_r
363365
When calculating an itinerary, GTFS-consuming applications interpolate transfers based on allowable time and stop proximity. [Transfers.txt](#transferstxt) specifies additional rules and overrides for selected transfers.
364366

365367
Fields `from_trip_id`, `to_trip_id`, `from_route_id` and `to_route_id` allow higher orders of specificity for transfer rules. Along with `from_stop_id` and `to_stop_id`, the ranking of specificity is as follows:
368+
366369
1. Both `trip_id`s defined: `from_trip_id` and `to_trip_id`.
367370
2. One `trip_id` and `route_id` set defined: (`from_trip_id` and `to_route_id`) or (`from_route_id` and `to_trip_id`).
368371
3. One `trip_id` defined: `from_trip_id` or `to_trip_id`.
@@ -394,6 +397,7 @@ Files [pathways.txt](#pathwaystxt) and [levels.txt](levelstxt) use a graph repre
394397
To navigate from the station entrance/exit (a node represented as a location with `location_type=2`) to a platform (a node represented as a location with `location_type=0` or empty), the rider will move through walkways, fare gates, stairs, and other edges represented as pathways. Generic nodes (nodes represented with `location_type=3`) can be used to connect pathways throughout a station.
395398

396399
Pathways must be defined exhaustively in a station. If any pathways are defined, it is assumed that all pathways throughout the station are represented. Therefore, the following guidelines apply:
400+
397401
- No dangling locations: If any location within a station has a pathway, then all locations within that station should have pathways, except for platforms that have boarding areas (`location_type=4`, see guideline below).
398402
- No pathways for a platform with boarding areas: A platform (`location_type=0` or empty) that has boarding areas (`location_type=4`) is treated as a parent object, not a point. In such cases, the platform must not have pathways assigned. All pathways should be assigned for each of the platform's boarding areas.
399403
- No locked platforms: Each platform (`location_type=0` or empty) or boarding area (`location_type=4`) must be connected to at least one entrance/exit (`location_type=2`) via some chain of pathways. Stations not allowing a pathway to the outside of the station from a given platform are rare.

0 commit comments

Comments
 (0)