I’m a new user integrating FlightXML into a .NET application. I’ve run into a few issues I’d like to bring to your attention, I tried e-mailing the problems but got no response.
When using the AirportInfo method, the lat/lon are reversed. Here is an example for KDFW:
When trying the ZipCode method, an error is returned:
can’t read “data(long)”: no such element in array
I don’t understand the TimeZone presentation in the AirportInfo, as you can see above it shows:
Time Zone: CST6CDT.
I’d like to see the documentation improved so we can better understand the input and return values.
I’d like to see a test system on your site where I can enter a value and see the return results. This will allow us to test the system directly from your implementation vs. ours so we can verify there is an error in the system vs. our implementation.
I’d like to join a “developer” mailing list so you can e-mail me information related to problems, improvements, outages, etc. to the service we pay for.
You have additional resources I’d love to have access to such as your airport diagrams, PDF approach plates, etc. Maybe methods that return byte arrays would be better than Base64 encoded strings?
I’d like to see information on the use of the “offset” and “nextoffset” properties and how to effectively use them in iterating results, etc, requering for the next set of data, etc.
The time zones are in the standard POSIX time zone format. CST6CDT means Central Standard Time (UTC-6) in the winter and Central Daylight Time in the summer.
I don’t understand this request, can you clarify?
We don’t currently have one, but we will notify you when we do.
I’ll pass this on to the development team. I don’t believe XML/WSDL supports byte arrays, so we have to use base64 encoding.
nextOffset is FlightXML advising you of the offset to use in your next query if you’d like more data.
Thank you for your reply - good info! Regarding #4:
I’d like to see a page that has each available web service method listed and can take the required inputs and then I click submit. The return values would be presented on screen. Again, this allows me to verify my implementation against yours before filing a bug report, and let’s me see how it works, etc.
I would like to make one more suggestion and that is the ability to pass in a parameter such as a query string parameter on the web service calls the indicates I’m in test mode. Queries in test mode would not be charged and they would return stale/old/bogus data for testing only. Although the fees are affordable, having to query your service during the development of a system could be setup to be free and then when we put our systems in production for real time data we would not pass in the “mode” switch and be charged for the queries now.
I’d love a test system as well… Currently when we run functional tests, we can’t exactly verify what comes back from FlightAware because the data changes… We can check that we do get data, but not exactly what it is. Having a static dataset in a test mode would be great.
This has been fixed.