1. id - All entities should have an id. The id should be unique within the context the entity live. For aggregates which live in a global space the id must be unique. This apply to all entities listed in the index service.
2. The hashCode()/equals() method is consistent and based on the id (identity). We frequently use this to index and lookup entities.

This can be used during routing to add extra cost or prune the search, depending on the user preferences.

The intended audience for this score are frontend developers wanting to show a simple UI rather than having to iterate over all the stops and trips.

Note: the information to calculate this score are all available to the frontend, however calculating them on the backend makes life a little easier and changes are automatically applied to all frontends.

CIRCLE_CLOCKWISE and CIRCLE_CLOCKWISE are used to represent traffic circles.

One use-case is to run a routing search in debug-filter-mode and instead of removing itineraries from the result, the itineraries could be tagged instead. These notices are meant for system testers and developers and should not be used for end user notification or alerts.

Turn onto Broadway from W 57th St (coming from 7th Ave):
distance = 100 (say)
walkDirection = RIGHT
streetName = Broadway
everything else null/false

Now, turn from Broadway onto Central Park S via Columbus Circle
distance = 200 (say)
walkDirection = CIRCLE_COUNTERCLOCKWISE
streetName = Central Park S
exit = 1 (first exit)
immediately everything else false

Instead, go through the circle to continue on Broadway
distance = 100 (say)
walkDirection = CIRCLE_COUNTERCLOCKWISE
streetName = Broadway
exit = 3
stayOn = true
everything else false

Currently only barrier=bollard is supported. Node barrier=bollard implies access=no, foot=yes, bicycle=yes

On this vertex geometry is split and two new edges are created.

If start/end vertex of StreetEdge is BarrierVertex edge isn't traversable with CAR.

Created by mabu on 11.5.2015.

To debug unexpected results is sometimes very time consuming. This class make it possible to list all stop arrival events during the search for a given list of stops and/or a path.

The debug events are not returned as part of the result, instead they are posted to registered listeners. The events are temporary objects; hence you should not hold a reference to the event elements or to any part of it after the listener callback completes.

One of the benefits of the event based return strategy is that the events are returned even in the case of an exception or entering a endless loop. You don´t need to wait for the result to start analyze the results.

Debugging stops

Debugging path

Created by demory on 2/16/17.

See Encoded polyline algorithm format

This class marks something that comes from the street network itself. It is used for linking origins in Analyst to ensure that they are linked to the same locations regardless of changes in the transit network between (or eventually within) graphs.

FareComponent is a sequence of routes for a particular fare.

A filter should do only one thing! For example do not change the itineraries and delete elements in the same filter. Instead, create two filters and insert them after each other in the filter chain.

This allows decoration of each filter and make it easier to reuse logic. Like the is reused in several places.

Reading compressed HTTPS resources is supported. The only format supported is gzip (extension .gz).

Translations are in src/main/resources/WayProperties_lang.properties and internals_lang.properties

locale is set in request.

It just returns string it is given in constructor.

Netex ONLY. Operators are available only if the data source is Netex, not GTFS.

The source of this location can be an OSM node (point) in which case the precise location is used.

If the source is an area (way) then the centroid is computed and used.

This class marks something that comes from the street network itself. It is used for linking origins in Analyst to ensure that they are linked to the same locations regardless of changes in the transit network between (or eventually within) graphs.

Instances of this class only exist in the context of a given pattern for a given round. Hence when comparing instances we may assume that they have the same number-of-transfers and the same Pattern. We take advantage of this by excluding all "constant" criteria from the pattern-ride comparator used by the pareto-set of patternRides.

This implementation of the multi-criteria Range Raptor keep all pareto-optimal _rides_ for each pattern while possessing each stops down the line. This class keep the needed state for these rides to avoid recalculating each value more than once and to be able put then in a .

We do not do this the same way as described in the original Raptor paper. The original McRaptor algorithm keep a bag of labels(stop-arrivals) while traversing the pattern. We keep a "bag" of patternRides in MultiCriteriaRoutingStrategy for the given pattern. The main differences are:

• Alight-/arrival specific cost is not included when comparing PatternRides. This is ok, since we add this before adding a path to the stop-arrivals at a given stop. This assumes that the cost of alighting/arrival is the same for all paths arriving by the same trip. This allow us to eliminate paths, without doing the actual stop-arrival cost calculation.
• We do NOT allow a one trip to exclude the pattern-rides of another trip in the pareto-set. Two PatternRides are both optimal, if they have boarded the same pattern, in the same round, but on different trips/vehicles. This have no measurable impact on performance, compared with allowing an earlier trip dominating a later one. But, it allows for a trip to be optimal at some stops, and another trip to be optimal at other stops. This may happen if the generalized-cost is not increasing with the same amount for each trip between each stop.
• We do not have to update all elements in the "pattern-bag" for every stop visited. The relative-cost is calculated once - when adding the path to the "pattern-bag" of PatternRides.

We currently support route full IDs (agency ID + route ID), agency ID + route name, or route name only. Support for other matching expression can be easily added later on.

All defaults should be specified here in the RouteRequest, NOT as annotations on query parameters in web services that create RouteRequests. This establishes a priority chain for default values: RouteRequest field initializers, then JSON router config, then query parameters.

An important detail: Routes in GTFS are not a structurally important element, they just serve as user-facing information. It is possible for the same journey pattern to appear in more than one route.

OTP already has several classes that represent this same thing: A TripPattern in the context of routing. It represents all trips with the same stop pattern A ScheduledStopPattern in the GTFS loading process. A RouteVariant in the TransitIndex, which has a unique human-readable name and belongs to a particular route.

We would like to combine all these different classes into one.

Any two trips with the same stops in the same order, and that operate on the same days, can be combined using a TripPattern to simplify the graph. This saves memory and reduces search complexity since we only consider the trip that departs soonest for each pattern. Field calendarId has been removed. See issue #1320.

A StopPattern is very closely related to a TripPattern -- it essentially serves as the unique key for a TripPattern. Should the route be included in the StopPattern?

Naming; This class is named SubMode, not NetexSubMode because we want to migrate gtfsRouteType into the same concept.

This class is thread-safe, and the performance overhead should affect the graph built time, but not routing.

Remember to use the #dispose(Vertex) to delete the temporary vertex from the main graph after use.

The constructor accepts any three numbers and will normalize them to add up to 1. time and slope are rounded to the closest two decimal number, then safety := 1.0 - (time + slope). This is done to make the rounding predictable and to allways add up to one. This allows this class to be used in an index of a cache. For example:

   ( 1.0, 1.0, 1.0 ) => ( time: 0.33, slope: 0.33, safety: 0.34 )
 

This class is currently only used with bicycle routing, but is not limited to that.

THIS CLASS IS IMMUTABLE AND THREAD-SAFE.

TODO OTP2 - Move this to package: org.opentripplanner.model - after as Entur NeTEx PRs are merged. - Also consider moving its dependencies in: org.opentripplanner.routing - The NEW Timetable should not have any dependencies to

This can be translated street names, GTFS alerts and notes.

This options are used in client "Travel by" drop down.

Each travel option consist of two variables: - value is a value which is sent to the server if this is chosen ("TRANSIT, WALK", "CAR", etc.) - name is a name with which client can nicely name this option even if specific value changes ("TRANSIT", "PARKRIDE", "TRANSIT_BICYCLE", etc.)

Travel options are created from org.opentripplanner.routing.graph.Graph transitModes variable and based if park & ride, bike & ride, bike sharing is supported. List itself is created in TravelOptionsMaker#makeOptions(HashSet, boolean, boolean, boolean)

Do NOT log the issue in the class where the issue is detected/created.

This is called a JOURNEY_PATTERN in the Transmodel vocabulary. However, GTFS calls a Transmodel JOURNEY a "trip", thus TripPattern.

The id is a unique identifier for this trip pattern. For GTFS feeds this is generally generated in the format FeedId:Agency:RouteId:DirectionId:PatternNumber. For NeTEx the JourneyPattern id is used.

All fields are immutable except for the availability, capacity which may be updated by updaters. If any other properties change a new VehicleParking instance should be created.

Connected to streets by StreetVehicleParkingLink. Transition for parking the bike is handled by VehicleParkingEdge.

All fields are immutable. If any other properties change a new VehicleParkingGroup instance should be created.

This is a ValueObject (design pattern).

THIS CLASS IS IMMUTABLE AND THREAD-SAFE.