Unable to search for the "A Line" from downtown Seattle

[onebusaway]

Unable to search for the "A Line" from downtown Seattle

[barbeau]

We're seeing a similar issue here in Tampa:

From Scherer drive in Pinellas County, you can find routes 4, 19, 52, but not 14, 20, 23"

Looks like the default radius in Android is 15,000m.

@paulcwatts Any idea what a good value for Puget Sound would be? I'm still looking into what a good value would be for Tampa.

cc @cagryInside

[paulcwatts]

40,000m encompasses pretty much all of the Seattle-Tacoma region. I seem to remember though that the radius caps out on the server somewhere -- however, that could have changed, it's been years since I last looked at this bug.

[barbeau]

Looks like the server-side routes-for-location API default is 10,000m when a query parameter isn't provided.

Looking at the Android code closer, it appears that the following logic is used to search for routes:

1. Look for nearby matches via REST API using user location (no radius specified)
2. If no results from 1., then look for nearby matches via REST API using region center (radius of 15,000m)

So, in most cases (when user location is provided), we're actually defaulting to the server radius of 10,000m.

[barbeau]

@caitbonnar Could you check into what search radius is current used for OBA iOS when search for nearby routes/stops? See above thread for details, but in short - the app can specify the radius, or rely on the server-side default (10,000m).

[barbeau]

@paulcwatts 40,000m looks like a good encompassing radius for most of Tampa Bay area as well (assuming your near downtown Tampa - and if you're more at the fringes of the area, you don't want anything on the opposite side anyway). I propose we fix this in OBA Android by increasing the radius to 40,000m, and using this radius when searching based on user's real-time location. I just did a quick test and it seems to work fine in Tampa. If there are no objections I'll submit a PR for this shortly.

(An aside - this site is a good quick tool to visualize radius around a point)

If we run into additional issues in the future with radius for specific deployments, we might want to consider making it a field in the Regions API that can be set per-region.

[caitbonnar]

@barbeau It appears that we use the maximum of the region's radius (@Wizecoder and I tried to trace it back -- it looks like this is actually the area currently displayed on the map, not a region as defined by the regions file... but we could be wrong here) and 15000m, similar to Android.

I think we actually construct a bounding box based on the lat/lons from the regions file to determine whether or not the user is in or out of service area (I remember asking you a lot of questions about this awhile back). Perhaps you could also think of using the radius of the box (i.e. the max of length and width) if you wanted to make sure search the entire region. Not sure if what you're looking for is just a reliable default here, though.

[bbodenmiller]

OneBusAway/onebusaway-iphone#67 (comment) may be useful for details on how search works on iOS.

[barbeau]

Thanks @caitbonnar @bbodenmiller @Wizecoder. Yes, I'm looking for a fairly generalizable default here.

I just posted to the oba-dev list on this as well to see if anyone else has additional input:
https://groups.google.com/forum/#!topic/onebusaway-developers/PGbHs3bGopA

[barbeau]

I'm now realizing that when I fixed this, I expanded the route search radius, but not the stop search radius (I missed a method call). Since this ticket was explicitly for route search, I'm opening another ticket for stop search.