stops-for-location always return empty list with outOfRange: true

[AngeloAvv]

When using the default onebusaway-docker configuration, *-for-location endpoints always return empty data with outOfRange: true even though you're in the exact center of the region.

http://localhost:8080/onebusaway-api-webapp/api/where/stops-for-location.json?key=TEST&lat=38.555308&lon=-121.735991

{
   "code":200,
   "currentTime":1723120309387,
   "data":{
      "limitExceeded":false,
      "list":[

      ],
      "outOfRange":true,
      "references":{
         "agencies":[

         ],
         "routes":[

         ],
         "situations":[

         ],
         "stopTimes":[

         ],
         "stops":[

         ],
         "trips":[

         ]
      }
   },
   "text":"OK",
   "version":2
}

Steps to reproduce:

1. docker-compose up oba_bundler
2. docker-compose up oba_app

3. Browse to http://localhost:8080/onebusaway-api-webapp/api/where/agencies-with-coverage.json?key=TEST so you can find the exact center of the agency

   {
   "code":200,
   "currentTime":1723120137641,
   "data":{
     "limitExceeded":false,
     "list":[
        {
           "agencyId":"unitrans",
           "lat":38.555308,
           "latSpan":0.03564399999999779,
           "lon":-121.735991,
           "lonSpan":0.10500400000000809
        }
     ],
     "references":{
        "agencies":[
           {
              "disclaimer":"",
              "email":"",
              "fareUrl":"",
              "id":"unitrans",
              "lang":"en",
              "name":"Unitrans",
              "phone":"530-752-BUSS",
              "privateService":false,
              "timezone":"America/Los_Angeles",
              "url":"http://unitrans.ucdavis.edu"
           }
        ],
        "routes":[
   
        ],
        "situations":[
   
        ],
        "stopTimes":[
   
        ],
        "stops":[
   
        ],
        "trips":[
   
        ]
     }
   },
   "text":"OK",
   "version":2
   }

4. Browse to http://localhost:8080/onebusaway-api-webapp/api/where/stops-for-location.json?key=TEST&lat=38.555308&lon=-121.735991

You can also apply a radius of 100Km or change the location to one of the available stops, but you'll always receive the same answer: empty list with outOfRange: true.

Am I missing something?

[aaronbrethorst]

Thanks for the report, @AngeloAvv! @Altonhe - Do you think you could look at this and see if you can figure out what might be happening?

[Altonhe]

@AngeloAvv The default time zone in the OneBusAway Docker setup is set to America/New_York, while the default GTFS data source, Unitrans, uses the America/Los_Angeles time zone. You can adjust these settings in the docker-compose.yml file, and that should resolve the issue.

[AngeloAvv]

Hello @Altonhe , thanks for your reply. I tore everything down and tried switching the TZ param in the docker-compose.yml as you suggested but nothing has changed. I also tried using another GTFS dataset, this time using Europe/Rome (I live in Italy) as mentioned in the agency details but I'm receiving the same results as above. Both Unitrans and my private dataset are not working.

[aaronbrethorst]

@AngeloAvv can you confirm the timezone value that is being set in your Docker container matches the timezone value from the GTFS data's agency.txt file?

[AngeloAvv]

@aaronbrethorst yes they are the same. I also checked the timezone was properly set by executing echo $TZ straight into the oba_app container (docker exec -it <container_id> sh).

I still don't understand what's the purpose of the timezone when I'm not looking for a date but for the position. Can you please elaborate?

[aaronbrethorst]

I still don't understand what's the purpose of the timezone when I'm not looking for a date but for the position. Can you please elaborate?

Wish I could! The timezone being set correctly is critical to the functioning of the web app, but I can't actually tell you why. I don't know enough about the internals of the OBA API webapp to speak to this, unfortunately.

[AngeloAvv]

Using the debugger I discovered that the documentation might be wrong: according to this, coordinates should be passed using a dot to separate the integer part from the decimal part, but in my case, the latitude has been rounded to 3.8555308E7 and the longitude to -1.21735991E8, definitely not the same values I put in my endpoint.

Then I realized coordinates should be passed using a comma to separate the integer part from the decimal part. As soon as I changed it, the debugger reported the proper values for both latitude and longitude and as a result, I was able to retrieve the nearby stops.