hsldevcom/opentripplanner

An open source multi-modal trip planner

Overview

OpenTripPlanner (OTP) is an open source multi-modal trip planner, focusing on travel by scheduled public transportation in combination with bicycling, walking, and mobility services including bike share and ride hailing. Its server component runs on any platform with a Java virtual machine ( including Linux, Mac, and Windows). It exposes GraphQL APIs that can be accessed by various clients including open source Javascript components and native mobile applications. It builds its representation of the transportation network from open data in open standard file formats (primarily GTFS and OpenStreetMap). It applies real-time updates and alerts with immediate visibility to clients, finding itineraries that account for disruptions and service changes.

Note that this branch contains OpenTripPlanner 2, the second major version of OTP, which has been under development since 2018. The latest version of OTP is v2.5.0, released in March 2024.

If you do not want to use this version, please switch to the final 1.x release tag v1.5.0 or the dev-1.x branch.

Performance Test

📊 Dashboard

We run a speed test (included in the code) to measure the performance for every PR merged into OTP.

More information about how to set up and run it.

Repository layout

The main Java server code is in src/main/. OTP also includes a Javascript client based on the Leaflet mapping library in src/client/. This client is now primarily used for testing, with most major deployments building custom clients from reusable components. The Maven build produces a unified ("shaded") JAR file at target/otp-VERSION.jar containing all necessary code and dependencies to run OpenTripPlanner.

Additional information and instructions are available in the main documentation, including a quick introduction.

Development

OpenTripPlanner is a collaborative project incorporating code, translation, and documentation from contributors around the world. We welcome new contributions. Further development guidelines can be found in the documentation.

Development history

The OpenTripPlanner project was launched by Portland, Oregon's transport agency TriMet (http://trimet.org/) in July of 2009. As of this writing in Q3 2020, it has been in development for over ten years. See the main documentation for an overview of OTP history and a list of cities and regions using OTP around the world.

Getting in touch

The fastest way to get help is to use our Gitter chat room where most of the core developers are. Bug reports may be filed via the Github issue tracker. The OpenTripPlanner mailing list is used almost exclusively for project announcements. The mailing list and issue tracker are not intended for support questions or discussions. Please use the chat for this purpose. Other details of project governance can be found in the main documentation.

OTP Ecosystem

• awesome-transit Community list of transit APIs, apps, datasets, research, and software.

opentripplanner's Issues

Expose serviceDay value for Leg

Absolute stoptimes that can be converted to a unix time and on to valid Date objects require a serviceDay value. This value is returned for stoptimes returned to nearby departure and stoptimesForDate(serviceDay: ) queries.

{
  "scheduledArrival": 74400,
  "realtimeArrival": 74400,
  "scheduledDeparture": 74400,
  "realtimeDeparture": 74400,
  "serviceDay": 1485122400,
}

But it is not included in Legs returned to plan queries. As serviceDay changes at different times depending on route, not at midnight, it seems that there is no reliable way to get the correct serviceDay for stoptimes of trips of planned Legs, especially if they are at night time.

Add serviceDay as a value to Legs that are transitLegs.

Slow responses for HFP cache queries

The following request for HFP cache takes several seconds to respond. Response delay was much smaller when I tried this some months ago, so something must be slowing these requests down currently.

https://api.digitransit.fi/realtime/vehicle-positions/v1/hfp/journey/tram/+/+/#

Much more frequent OTP timeouts for a month

Expected behavior

Act as usual with only a few timeouts

Observed behavior

Lots of timeouts (only timeouts on some itineraries...) with latest OTP snapshots for approx. a month

Version of OTP used (exact commit hash or JAR name)

8e1b5cf commit (currently latest)

Data sets in use (links to GTFS and OSM PBF files)

https://ratp.spiralo.net/router-paris.zip

Command line used to start OTP

Docker containter with 7Go memory limit for java.

Router config and graph build config JSON

files are into the router-paris.zip file, like GTFS ones.

Steps to reproduce the problem

Try a request from Luxembourg, Paris, France to Rue Léontine Sohier, Longjumeau, France or a lot of others.

Error reading bike rental feed from http://digitransit-proxy:8080/out/helsinki

When I try to run the docker image I get the following:
Error reading bike rental feed from http://digitransit-proxy:8080/out/helsinki-fi.smoove.pro/api-public/stations
java.net.UnknownHostException: digitransit-proxy

Steps to reproduce the problem

docker run --rm --name otp-hsl -p 9080:8080 -e ROUTER_NAME=hsl -e JAVA_OPTS=-Xmx5g -e ROUTER_DATA_CONTAINER_URL=https://api.digitransit.fi/routing-data/v2/hsl hsldevcom/opentripplanner

Improvements for pedestrians

• Sidewalk naming
• Separate indoors and tunnels
• Opening hours for indoors
• Improved walking directions

Diverging and combining trains

Add details for stoptimes index api

• Mode of tripPattern
• Stop boarding/alighting status

OTP Airplane support

• Check status of airplanes branch
• It should be possible to configure time between itinerary legs by mode. e.g. for plane use xxmin

Minimum routing specification

• Start with OTP defaults
• See what OTP supports and consider improving OTP defaults for:
  • walking cost linear (length & time)
  • walking cost non-linear (e.g. below 1000m and over 1000m)
  • waiting before first vehicle
  • waiting time during transfer
  • transport mode ("kulkumuotokohtaiset kertoimet") ("bus", "train", "airplane", "Long distance bus"...)
  • boarding cost ("nousuvastus")

This will be improved in #11

DirectionId type not consistent

Trip has directionId with type String whereas Pattern has directionId with type Int, although they seem to refer to exact same data. Probably should be Int, if possible.

Also, directionId values in Trips and Patterns seem to be 0 or 1, while MQTT feed directionId values are 1 or 2 in the topic, as follows
/hfp/journey/type/id/line/direction/headsign/start_time/next_stop/(geohash_level)/geohash/#

These should be more consistent, now they lead to unnecessary confusion and bugs in code.

Sidewalk naming

This might be related to OSM

Profile routing

"Unexpected role in multipolygon" makes graph building fail using OSM extracts since latest merges

Since PR #79 merging, I'm not able to build graphs anymore, due to a "expected role in multipolygon" error.

Please fix!

What is the correct way to add vehicle positions?

Hello,

I have started working on my own Digitransit instance. As of now, I have working search routing in the UI based on OpenTripPlanner API with both static GTFS and protocol buffer GTFS-RT trip updates.

I however am unable to to find a suitable way to plug a GTFS-RT vehicle positions feed in. I have the feed already set up, working and tested with other tools. I see that on http://reittiopas.hsl.fi/ there are vehicle positions being used, but the updaters I can find do not support GPS data ingestion: real-time-alerts, bike-rental, bike-park, websocket-gtfs-rt-updater, stop-time-updater etc.

This issue is discussed in the original opentripplanner repo´s issues: opentripplanner#2329 and a pull request with an updater for pbf gtfs-rt positions feed was submitted, but closed and not merged: opentripplanner@cee935a

From what I can see, no suitable updater is present neither in the original OTP, and not in the HSLdevcom version:
https://github.com/HSLdevcom/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/updater/GraphUpdaterConfigurator.java
https://github.com/opentripplanner/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/updater/GraphUpdaterConfigurator.java

Could you please me point me in the right direction as to how to achieve the integration of vehicle positions that is present in Reittiopas (be it either GTFS-RT, MQTT or other)? Maybe this is done through another component and not OTP but from the few days of studying the code and attempted network requests, it seems that the GPS data displayed on the map upon selecting a route/trip is somehow coming from OTP.

Improved routing specification

Specify how our minimun routing should be improved. See #23.

Questions:

• How to calibrate routing weigh (what does optimal route mean?)
• Route alternatives (What suboptimal routes are searched?)
  • Should we search for different times?
  • Should we search for different connections?
  • Should we search by different calibrations?
  • Alternatively, should we search only generalized routing (e.g. bus 54 every 10minutes)

Come up with a list that affects to calibration weighs. E.g. (price, waiting location, co2, eu directives, traffic coordination (liikenteenohjaus), trustworthiness, where I have to walk, weather,...)

We should go through current implementation docs and see what values are used there.

Please merge a commit from upstream to fix routing to stops when no OSM data

With new linker, OTP lost ability to route to stops where no OSM data is available. This was re-implemented in opentripplanner@deb2544 could you please merge it?

Thanks!

Separate indoors and tunnel

Sidewalk naming

Improved walking directions

In DefaultFareServiceImpl fare calculation logic issue.

Here is the code in org.opentripplanner.routing.impl.DefaultFareServiceImpl.java :

private Fare _getCost(GraphPath path, Set<String> allowedFareIds) {
    List<Ride> rides = createRides(path);
    // If there are no rides, there's no fare.
    if (rides.size() == 0) {
      return null;
    }
    Fare fare = new Fare();
    boolean hasFare = false;
    for (Map.Entry<FareType, Collection<FareRuleSet>> kv : fareRulesPerType.entrySet()) {
      FareType fareType = kv.getKey();
      Collection<FareRuleSet> fareRules;
      if (allowedFareIds != null) {
        fareRules = kv.getValue().stream()
            .filter(f -> allowedFareIds.contains(f.getFareAttribute().getId().toString()))
            .collect(Collectors.toList());
      } else {
        fareRules = kv.getValue();
      }
      // Get the currency from the first fareAttribute, assuming that all tickets use the same
      // currency.
      Currency currency = null;
      if (fareRules.size() > 0) {
        currency =
            Currency.getInstance(fareRules.iterator().next().getFareAttribute().getCurrencyType());
      }
      hasFare = populateFare(fare, currency, fareType, rides, fareRules);
      // log.info("Fares for {} available: {}", fareType, hasFare);
    }
    return hasFare ? fare : null;
  }

inside the for loop, if we have 4 fareTypes need to calculate, let's assume the result as below:
1_fareType : hasFare = true
2_fareType: hasFare = true
3_fareType: hasFare = true
4_fareType: hasFare = false
what will be the result return from this method ? null right ?
I wonder this is written as design or it's a logic error.
if it's a logic error , I advice to update the code to be
hasFare = populateFare(fare, currency, fareType, rides, fareRules) || hasFare;

As a passenger I want to travel from Tampere to Turku (stop hierarchy)

Add support for Finnish client locale

Select/prioritize/show alternative routes

As a passenger I want to use line 550. How can I get to it?

TimedExecutorServiceExecutionStrategy makes Lucene indexing failing

Since PR #94 merging, Lucene indexing is failing:

19:42:27.156 INFO (LuceneIndex.java:148) Starting background Lucene indexing. 19:42:38.224 INFO (ExecutionStrategy.java:42) Exception while fetching data java.lang.RuntimeException: Lucene indexing failed. at org.opentripplanner.common.LuceneIndex.index(LuceneIndex.java:100) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.common.LuceneIndex.access$200(LuceneIndex.java:47) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.common.LuceneIndex$BackgroundIndexer.run(LuceneIndex.java:149) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.common.LuceneIndex.<init>(LuceneIndex.java:68) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.routing.graph.GraphIndex.getLuceneIndex(GraphIndex.java:449) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.index.IndexGraphQLSchema.lambda$new$242(IndexGraphQLSchema.java:1943) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at graphql.execution.ExecutionStrategy.resolveField(ExecutionStrategy.java:40) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.index.TimedExecutorServiceExecutionStrategy.lambda$execute$332(TimedExecutorServiceExecutionStrategy.java:57) [otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_66-internal] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_66-internal] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_66-internal] at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_66-internal] Caused by: java.nio.channels.ClosedByInterruptException: null at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202) ~[na:1.8.0_66-internal] at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:970) ~[na:1.8.0_66-internal] at org.apache.lucene.store.MMapDirectory.map(MMapDirectory.java:283) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.store.MMapDirectory$MMapIndexInput.<init>(MMapDirectory.java:228) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:195) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.store.Directory.copy(Directory.java:185) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.store.TrackingDirectoryWrapper.copy(TrackingDirectoryWrapper.java:50) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.IndexWriter.createCompoundFile(IndexWriter.java:4672) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.DocumentsWriterPerThread.sealFlushedSegment(DocumentsWriterPerThread.java:535) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:502) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:508) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:380) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:472) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1534) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1204) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1185) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.common.LuceneIndex.addStop(LuceneIndex.java:114) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] at org.opentripplanner.common.LuceneIndex.index(LuceneIndex.java:85) ~[otp-1.1.0-SNAPSHOT-shaded.jar:1.1] ... 11 common frames omitted

Please fix :)

GraphQL support

Enhance Vertext/Edge debugging

Walk transit steps should include OSM ids

Support for airplanes

• Server
• OTP Client
• Navigator proto

Configurable boarding times for different modes

GraphQL Timeout Error Message not clear

When executing a GraphQL Query that runs into the (default) timeout of 30 seconds, an Error Response is returned that sadly doesn't reference the timeout (and such the reason why the query didn't succeed).
This caused a lot of confusion why our OTP instance didn't want to respond with stops for a GraphQL query and only cleared after we digged into the OTP code.

Expected behavior

The returned json contains an errorType or message that warns the user about the abortion of the query because of the timeout.

Observed behavior

In the returned json, there is nowhere a reference to a timeout found, instead a DataFetchingException with a null message appears:

{"data":{},"errors":[{"stack":[...]],"errorType":"DataFetchingException","locations":null,"message":"Exception while fetching data: null"}]}

Full Response

HTTP/1.1 500 Internal Server Error
Access-Control-Allow-Credentials: false
Content-Type: application/json
Date: Fri, 03 Apr 2020 20:46:44 GMT
Connection: close
Content-Length: 3072

{"data":{},"errors":[{"stack":["java.util.concurrent.FutureTask.report(FutureTask.java:121)","java.util.concurrent.FutureTask.get(FutureTask.java:192)","org.opentripplanner.index.ResourceConstrainedExecutorServiceExecutionStrategy.execute(ResourceConstrainedExecutorServiceExecutionStrategy.java:81)","graphql.execution.Execution.executeOperation(Execution.java:85)","graphql.execution.Execution.execute(Execution.java:44)","graphql.GraphQL.execute(GraphQL.java:201)","org.opentripplanner.routing.graph.GraphIndex.getGraphQLExecutionResult(GraphIndex.java:1055)","org.opentripplanner.routing.graph.GraphIndex.getGraphQLResponse(GraphIndex.java:1035)","org.opentripplanner.index.IndexAPI.getGraphQL(IndexAPI.java:657)","sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)","sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)","java.lang.reflect.Method.invoke(Method.java:498)","org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)","org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)","org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)","org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)","org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)","org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)","org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)","org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)","org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)","org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)","org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)","org.glassfish.jersey.internal.Errors.process(Errors.java:315)","org.glassfish.jersey.internal.Errors.process(Errors.java:297)","org.glassfish.jersey.internal.Errors.process(Errors.java:267)","org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)","org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)","org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)","org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384)","org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:224)","org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)","org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)","java.lang.Thread.run(Thread.java:745)"],"errorType":"DataFetchingException","locations":null,"message":"Exception while fetching data: null"}]}

Version of OTP used (exact commit hash or JAR name)

docker image: hsldevcom/opentripplanner:4325c2e143dcdc8c81ba36fb0f7f2e549667ed38

Steps to reproduce the problem

• Use a graph with lots and lots of stops (> 17.000), like verschwoerhaus/opentripplanner-data-container-vsh:2020-04-03-latest
• Allow maximum of 8GB RAM for the JVM, as set by default in the otp docker container: ENV JAVA_OPTS="-Xms8G -Xmx8G"
• Send a request to http://<otp-host>:8080/otp/routers/<router>/index/graphql with a long running query returning lots of objects, like the query hsl-map-server/tilelive-otp-stops issues for getting all the stops: https://github.com/HSLdevcom/tilelive-otp-stops/blob/3f0cac4ace1b6b506424ea0372c46ab190652914/index.js#L42-L62

Where does this come from?

In #94 (DT-607, DT-56) the TimedExecutorServiceExecutionStrategy (later ResourceConstrainedExecutorServiceExecutionStrategy) was introduced, to add a timeout to long running graphql queries to prevent a DOS.

Opening hours for indoors

Caused by: org.onebusaway.csv_entities.exceptions.MissingRequiredFieldException: missing required field: pathway_type

Expected behavior

pathway_mode would be read as defined in the spec.

Observed behavior

OTP requires a pathway_type field, that is not in the spec (seems to be pathway_mode under another name)

Version of OTP used (exact commit hash or JAR name)

891117f (master)

Data sets in use (links to GTFS and OSM PBF files)

IFDM dataset from Paris.

Steps to reproduce the problem

Use a GTFS file with a pathway.txt file.

Thanks for your help!

Geometry of trams only has stop-to-stop resolution

While other route patterns seem to have the usual high accuracy for their geometry, trams seem to only have stop-to-stop resolution. So the latitudes and longitudes are only given for each stop in geometry array.

I believe this is a regression to how it was just some days (perhaps weeks?) ago. Maybe some error in source data?

[edit] this only seems to affect some tram routes as query with trip(id: "HSL:1007B_20170508_La_1_1441") returns the usual resolution geometry.

{
  trip(id: "HSL:1003 _20170508_La_2_1423") {
    gtfsId
    pattern {
      geometry {
        lat
        lon
      }
    }
  }
}

Complete response below:

{
  "data": {
    "trip": {
      "gtfsId": "HSL:1003 _20170508_La_2_1423",
      "pattern": {
        "geometry": [
          {
            "lat": 60.19256090000013,
            "lon": 24.930717699999875
          },
          {
            "lat": 60.1922220999999,
            "lon": 24.936283799999977
          },
          {
            "lat": 60.191135199999906,
            "lon": 24.94093719999998
          },
          {
            "lat": 60.190622699999906,
            "lon": 24.94557789999997
          },
          {
            "lat": 60.186781500000386,
            "lon": 24.94845870000003
          },
          {
            "lat": 60.18531529999993,
            "lon": 24.951408299999994
          },
          {
            "lat": 60.18350619999994,
            "lon": 24.95271009999999
          },
          {
            "lat": 60.181311699999725,
            "lon": 24.949989899999995
          },
          {
            "lat": 60.17906760000015,
            "lon": 24.95006559999993
          },
          {
            "lat": 60.17336340000017,
            "lon": 24.949187599999963
          },
          {
            "lat": 60.1716923000001,
            "lon": 24.947397300000084
          },
          {
            "lat": 60.17043500000034,
            "lon": 24.940672800000034
          },
          {
            "lat": 60.16779039999983,
            "lon": 24.941512799999895
          },
          {
            "lat": 60.16625370000038,
            "lon": 24.94238930000003
          },
          {
            "lat": 60.16467160000027,
            "lon": 24.937878300000005
          },
          {
            "lat": 60.1627774000002,
            "lon": 24.93904600000002
          },
          {
            "lat": 60.1609003000002,
            "lon": 24.94166850000002
          },
          {
            "lat": 60.1580242000002,
            "lon": 24.94180290000002
          },
          {
            "lat": 60.158176000000076,
            "lon": 24.94551740000002
          },
          {
            "lat": 60.15847440000025,
            "lon": 24.94982020000002
          },
          {
            "lat": 60.15952860000026,
            "lon": 24.954968900000022
          },
          {
            "lat": 60.16154810000026,
            "lon": 24.95648490000003
          }
        ]
      }
    }
  }
}

Departure/arrival stop and time more easily available

In many cases it is useful to get the first/last stop and departure/arrival time for a trip, perhaps for a large number of trips or patterns using a single query.

While the current graphQL API allows querying for all stops and stoptimes to get to this information, it feels cumbersome at best. Having to query all stops and stopime for long routes with many stops in them makes it currently slow or difficult to get to this data.

If possible, add departureStop, arrivalStop, departureStoptime, arrivalStoptime to all elements that support these.

Add ability to match GTFS-RT updates without trip id

Identical stoptimes for many stops on trip

Querying stoptimes for a trip returns clearly incorrect departure times. The scheduledArrival and scheduledDeparture values for different stops may have same values (to the second). This should match neither scheduled timetables or estimated realtime stop times. It does not happen for every trip but still noticeably often.

This issue has been in the Digitransit API for months now, and I find it peculiar that this has not surfaced and got fixed in any testing done so far...

For example,

{
  trip(id: "HSL:1075_20170501_La_1_1554") {
    stoptimesForDate(serviceDay: "20170506") {
      stop {
        gtfsId
      }
      scheduledArrival
      realtimeArrival
      scheduledDeparture
      realtimeDeparture
      serviceDay
      realtime
    }
  }
}

Response

{
  "data": {
    "trip": {
      "stoptimesForDate": [
        ...
        {
          "stop": {
            "gtfsId": "HSL:1240121"
          },
          "scheduledArrival": 58080,
          "realtimeArrival": -1,
          "scheduledDeparture": 58080,
          "realtimeDeparture": -1,
          "serviceDay": 1494018000,
          "realtime": true
        },
        {
          "stop": {
            "gtfsId": "HSL:1240122"
          },
          "scheduledArrival": 58080,
          "realtimeArrival": 58107,
          "scheduledDeparture": 58080,
          "realtimeDeparture": 58107,
          "serviceDay": 1494018000,
          "realtime": true
        },
        ...
        {
          "stop": {
            "gtfsId": "HSL:1383107"
          },
          "scheduledArrival": 58440,
          "realtimeArrival": 58467,
          "scheduledDeparture": 58440,
          "realtimeDeparture": 58467,
          "serviceDay": 1494018000,
          "realtime": true
        },
        {
          "stop": {
            "gtfsId": "HSL:1383109"
          },
          "scheduledArrival": 58440,
          "realtimeArrival": 58467,
          "scheduledDeparture": 58440,
          "realtimeDeparture": 58467,
          "serviceDay": 1494018000,
          "realtime": true
        },
        ...
        {
          "stop": {
            "gtfsId": "HSL:1382113"
          },
          "scheduledArrival": 58620,
          "realtimeArrival": 58647,
          "scheduledDeparture": 58620,
          "realtimeDeparture": 58647,
          "serviceDay": 1494018000,
          "realtime": true
        },
        {
          "stop": {
            "gtfsId": "HSL:1382143"
          },
          "scheduledArrival": 58620,
          "realtimeArrival": 58647,
          "scheduledDeparture": 58620,
          "realtimeDeparture": 58647,
          "serviceDay": 1494018000,
          "realtime": true
        },
        ...
        {
          "stop": {
            "gtfsId": "HSL:1384149"
          },
          "scheduledArrival": 58860,
          "realtimeArrival": 58887,
          "scheduledDeparture": 58860,
          "realtimeDeparture": 58887,
          "serviceDay": 1494018000,
          "realtime": true
        },
        {
          "stop": {
            "gtfsId": "HSL:1384151"
          },
          "scheduledArrival": 58860,
          "realtimeArrival": 58887,
          "scheduledDeparture": 58860,
          "realtimeDeparture": 58887,
          "serviceDay": 1494018000,
          "realtime": true
        },
        ...
      ]
    }
  }
}

Translations for GTFS data

This should be loaded from translations.txt. This is currently pending the integration of the new GTFS loader in OTP, as the OBA loader does not support translations, and is not easily expendable.

Check if current APIs support everything we need

graphQL/stoptimes call returns 500, when using a GTFS file with frequencies

We realized that after adding a new gtfs file to our OTP instance, with trips with frequencies (besides scheduled times), the calls to graphQL "stoptimes" were returning 500.
To be sure of this, we removed the frequencies.txt file and the issue disappeared (of course we didn’t had results for the period where frequencies were applied).

We tried this on both “prod” and “latest” docker images.

Another thing we noticed, whilst using the file with frequencies, was that:

• When using OTP builtin webinterface, we were able to see results
• When using digitransit (whose requests go through graphql) we were not

With further debug, it was found that the call to get stoptimes would work only with scheduledTimetable:

@@ -1800,9 +1804,30 @@
                         .name("stoptimes")
                         .description("List of times when this trip arrives to or departs from a stop")
                         .type(new GraphQLList(stoptimeType))
                        .dataFetcher(environment -> TripTimeShort.fromTripTimes(
                                index.patternForTrip.get((Trip) environment.getSource()).scheduledTimetable,  # HERE!
                                environment.getSource()))

In this situation, OTP throws the following:

otp_1          | 18:40:40.356 WARN (ExecutionStrategy.java:70) Exception while fetching data
otp_1          | java.lang.ArrayIndexOutOfBoundsException: null
otp_1          | 18:40:40.357 WARN (FieldErrorInstrumentation.java:174) Exception while fetching field
otp_1          | java.lang.ArrayIndexOutOfBoundsException: null
otp_1          | 18:40:40.409 WARN (ExecutionStrategy.java:70) Exception while fetching data
otp_1          | java.lang.ArrayIndexOutOfBoundsException: null
otp_1          | 18:40:40.411 WARN (FieldErrorInstrumentation.java:174) Exception while fetching field
otp_1          | java.lang.ArrayIndexOutOfBoundsException: null
otp_1          | 18:40:40.429 WARN (FieldErrorInstrumentation.java:133) Errors executing query

That's because the Trip didn't had a "scheduledTimetable".
So we've implement a fix. Its been working for some time an we believe its ok:

                         .name("stoptimes")
                         .description("List of times when this trip arrives to or departs from a stop")
                         .type(new GraphQLList(stoptimeType))
                        .dataFetcher(environment ->{
                                Timetable timetable = index.patternForTrip.get((Trip) environment.getSource()).scheduledTimetable;

                                // If the Trip is frequency-based, there are no scheduled tripTimes (they must com from <FrequencyEntry>.tripTimes)
                                if (timetable.tripTimes.isEmpty()) {

                                        // This should probably be encapsulated into a function named TripTimeShort.fromFrequencyTripTimes,
                                        // since it does the same as existing function TripTimeShort.fromTripTimes, but for Frequency.
                                        // Or, it could also be moved into TripTimeShort.fromTripTimes.

                                        List<TripTimeShort> out = Lists.newArrayList();

                                        for (FrequencyEntry freq : timetable.frequencyEntries) {
                                              TripTimes times = freq.tripTimes;
                                               for (int i = 0; i < times.getNumStops(); ++i) {
                                                         out.add(new TripTimeShort(times, i, timetable.pattern.getStop(i), null));
                                               }
                                        }
                                       return out;
                               } else {
                                       return TripTimeShort.fromTripTimes(timetable, environment.getSource());
                               }
                        })
                         .build())
```

We're grad to share it via patch or pull request.

Make graph building faster

Dear all,

Would it be possible to pull this PR opentripplanner#2271 into your OTP fork, to make graph building faster? It really improves building time for Paris (2 fold decrease). BTW, there also may have some other interesting things to merge from upstream master.

Thanks :)

Routing ignores OSM building:min_level?

Expected behavior

Routing uses only ways at levels between building:min_level and building:levels to route from a building.

Observed behavior

Routing uses level 1 if a path near (or under) the building is present.

Version of OTP used (exact commit hash or JAR name)

N/A

Data sets in use (links to GTFS and OSM PBF files)

HSL Reittiopas Web interface as of 26 Nov 2017.

Command line used to start OTP

N/A

Router config and graph build config JSON

HSL Reittiopas Web interface as of 26 Nov 2017.

Steps to reproduce the problem

Query a route from a building with building:min_level above 1 and complex paths near it. In this case, Kirjokansi 2 A, Espoo to Heikintori in Reittiopas is a good example. Routing seems to assume a footpath at level 1 (under the building, in a shopping mall) is accessible directly from the building. Footpath on level 4 or pedestrian area on level 6, both levels included in the building (>= building.min_level) should be used instead.

This seems to be sensitive to walking distance preference. These particular queries show unintuitive routes of different kind (both routed through level 1) at the time of writing:

https://www.reittiopas.fi/reitti/Kirjokansi%202%20A%2C%20Espoo%3A%3A60.17555%2C24.804613/Heikintori%2C%20Kauppamiehentie%201%2C%20Espoo%3A%3A60.176583%2C24.802581?time=1511601844

https://www.reittiopas.fi/reitti/Kirjokansi%202%20A%2C%20Espoo%3A%3A60.17555%2C24.804613/Heikintori%2C%20Kauppamiehentie%201%2C%20Espoo%3A%3A60.176583%2C24.802581?arriveBy=false&minTransferTime=180&time=1511602038&walkReluctance=3.5999999999999996

If there's an alternative solution to this routing issue, I'm welcome to hear of it as an OSM contributor. Amount of such buildings is going to increase in HSL area as a result of new 3D combined metro station - shopping mall - residential building complexes being built.

Expose geometry as polyline instead of lat,lon list

Leg currently returns a legGeometry: LegGeometry which looks like this:

"legGeometry": {
  "length": 17,
  "points": "ueenJey~uCyDxCOmAIs@G_@Ec@G_@YfA}@l@a@Xm@`@IDOH^xCPl@CP@L"
}

Pattern and Trip instead only expose geometry: [[Float]] list which takes up much more space to express the same thing. Even though compression probably solved the bandwidth issue mostly, it would still be nice to systematically use polyline encoding for all geometries. Coordinate arrays can stay as an alternative.

Please add patternGeometry to Pattern and tripGeometry to Trip.

{
  "lat": 60.168929,
  "lon": 24.613933
},
{
  "lat": 60.168883,
  "lon": 24.614113
},
{
  "lat": 60.168766,
  "lon": 24.614327
},
{
  "lat": 60.168152,
  "lon": 24.615018
},
{
  "lat": 60.168025,
  "lon": 24.615231
},
{
  "lat": 60.167764,
  "lon": 24.615461
},
{
  "lat": 60.167609,
...

Trip queries currently fail for most requests in /hsl endpoint

This started yesterday (Feb 3). The folllowing simple trip(id: ) sample query fails most of the time when sent to /hsl endpoint, currently only about 1/3 of trip(id: ) requests return the correct response. In /finland endpoint the same request works every time as it should.

I don't know if this is limited to a specific set of Trips or applies to all of them.

IMHO, there should be some automated monitoring for this type of stuff, and it should not stay in api.digitransit.fi for this long...

[edit] Seems like this type of Reittiopas link also sometimes fails to load because of the same reason https://beta.reittiopas.fi/linjat/HSL:4561/pysakit/HSL:4561:1:01/HSL:4561_20170123_La_2_1259

{
  trip(id: "HSL:2147_20170130_Pe_2_2254") {
    gtfsId
  }
}

failed response:

{
  "data": {
    "trip": null
  }
}

correct response:

{
  "data": {
    "trip": {
      "gtfsId": "HSL:2147_20170130_Pe_2_2254"
    }
  }
}

Plan search fails to the some coordinates inside helsinki

Plan search for the following coordinates fails with PathNotFoundException

from: {lat: 60.168961, lon: 24.924713}, to: {lat: 60.158830, lon: 24.933685

The coordinates are valid but is in the middle of a house compound

https://www.google.fi/maps/place/60%C2%B009'31.8%22N+24%C2%B056'01.3%22E/@60.15822,24.9326136,17.33z/data=!4m5!3m4!1s0x0:0x0!8m2!3d60.15883!4d24.933685?hl=en

Add support for searching stops by actual walking distance

hannesj@ec31bd4

Clean unused OTP code, branches and rebase upstream

• Fuzzy matching is not used anymore
• Rebase upstream
• Check our modifications to time table api and check if that should be discarded

Unable to run docker image in Google Cloud

NOTE: this issue system is intended for reporting bugs and tracking progress in software
development. For all other usage and software development questions or discussion, please write to
the user mailing list(https://groups.google.com/forum/#!forum/opentripplanner-users) or post a
question in the developer chat: https://gitter.im/opentripplanner/OpenTripPlanner.

Expected behavior

Image should be deployed succesfully

Observed behavior

When attempting to deploy image in cloud run I get the following error:

• Error retrieving graph source bundle https://api.digitransit.fi/routing-data/v2/finland/router-finland.zip from otp-data-server... retrying in 5 s...

I think it could be related to the API key that is now needed to access routing data

Version of OTP used (exact commit hash or JAR name)

I used the latest image from docker hub: https://hub.docker.com/r/hsldevcom/opentripplanner

Data sets in use (links to GTFS and OSM PBF files)

Command line used to start OTP

On the cloud shell of Google Cloud platform (linux) I used this:

• docker pull hsldevcom/opentripplanner:latest
• docker tag hsldevcom/opentripplanner:latest gcr.io/helsinki-transport/hsldevcom/opentripplanner:latest
• docker push gcr.io/helsinki-transport/hsldevcom/opentripplanner:latest

These commands pull tag and push the container image to the container registry of GCP.

Router config and graph build config JSON

Steps to reproduce the problem

On GCP open the cloud shell and run this:

• docker pull hsldevcom/opentripplanner:latest

• docker tag hsldevcom/opentripplanner:latest gcr.io/helsinki-transport/hsldevcom/opentripplanner:latest

• docker push gcr.io/helsinki-transport/hsldevcom/opentripplanner:latest

• Then try to load container image in cloud run.

I hope I have provided enough information. Let me know if you need any more details.

Localization

We want to have the following in Finnish, Swedish, Sami and English (if available):

• Street names from OSM
• Internal strings on OTP
• Translations.txt from the various GTFS-feeds

[regression] Origin and destination are not designated by their names but using coordinates

As you can see below, Addresses (names) are not used anymore in Origin and Destination. A fix has been committed upstream: opentripplanner@08470b8 please fix :)

As a passenger I want to travel by OnniExpress

Unable to run docker with M1 Macs

Expected behavior

Docker run should not get stuck

Observed behavior

Using M1 Mac docker run for OpenTripPlanner gets stuck and prints only JAR=otp-shaded.jar

Data sets in use

I followed the guide in the link on how to use OpenTripPlanner with docker
https://digitransit.fi/en/developers/architecture/x-apis/1-routing-api/

Command line used to start OTP

docker run -e OTP_DATA_CONTAINER_URL=http://otp-data-container:8080 -p 8080:8080 hsldevcom/opentripplanner

Steps to reproduce the problem

Run the above command in Apple silicon M1 environment