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.