Assistance with SearchBirdseyePositions

I’m a new to the FlightAware API. My goal is to pull a list of flights that have crossed withing a specific area and were traveling within a specific altitude range over the last hour.

My challenge right now is getting SearchBirdseyePositions with a properly formatted query string. For example, if I want to confine my results over the San Francisco airport, I would use SearchBirdseyePositions {range lat 37.601258 37.636882} {range lon -122.413616 -122.291737}, my actual URL looks like:{range%20lat%2037.601258%2037.636882}%20{range%20lon%20-122.413616%20-122.291737}&howMany=1&uniqueFlights=0

If I am reading the documentation correctly, I should get at least one flight and all positions recorded. When I run the query, I consistently get {“error”:“no results”}. So forget about searching over a time period, I can’t even get a single result within a geo boundary at a really busy airport!

I am able to run a successful query against the Search resource. Searching for flights in the same lat/lon boundry, my URL looks like this:"37.601258%20-122.413616%2037.636882%20-122.291737"%20-inAir%200&howMany=1&offset=0

Unfortunately, Search appears to only return the last known altitude.

Can someone point me in the right direction?

Your syntax looks like it should be fine, so I’m not certain why you would have a problem. I will try to debug the problem further.

Is it possible that my query is taking too long to complete? I purposely picked a busy area, thinking I would guarantee my chances of getting at least one result. All I really want is a starting point that I can build from that will allow me to see how various filters would affect my results. Once I get those fine tuned - I plan to run the query against an area that might get one or two flights a day.

Yes, unfortunately there is a server-imposed time limit for any request to complete and if it exceeds that limit it will return a blank response. It used to be possible to get position searches by lat/lon to complete before the timeout, but it looks like our growth in data coverage has recently pushed things over that time threshold with the current “birdseye” infrastructure (the internal name of one of our backend data repositories).

We do have plans to switch to a new backend infrastructure in the coming weeks, which should be more performant, but I don’t think we can make and easy fixes for this in the immediately near future as a workaround.

EDIT: We may have a shorter-term workaround to improve the performance of these searches and allow it to complete within the time limit, but we’ll need to do some engineering/testing first before we can deploy it…

Thanks for looking into this!

Okay, retry your request and see if that’s better. It seems to be much faster and more reliable in my testing just now.

YES! Responses are snappy and I’m getting the results I was looking for. Thanks for your help!

Glad to hear. Thanks for testing it.