Greetings;  we'd like to try to open up this forum and use it as a launching pad for users with questions on the newly released PlaneXML Flight Tracking API.

By posting your questions or comments here, it allows the rest of the developer community to see your questions and answers, and shares your experiences with everyone else.  This helps by providing a resource for other users who may have the same questions as you :)

Any questions posted here will be answered as quickly and as thoroughly as possible :)

Andy

Hi,

I'm trying to access the API using PHP and NuSoap

I'm using pretty much the same code as I have working for the flightaware API but I'm not getting a response object back from you.

My code looks like this:

require_once('include/lib/nusoap.php');

$username = "myusername";
$password = "mykey";   

$result = array();   
$url = "http://planexml.flightwise.com/ws/PlaneXMLbeta1.asmx?WSDL";

$client = new soapclient($url,true);
$client->user = $username;
$client->pass = $password;

$proxy = $client->getProxy();
$proxy->setCredentials($username, $password);

$result = $proxy->Registration('N700AL');

print_r($result);

I'm getting no result back from your server.   If I print_r $proxy I see the WSDL from your end.

Any thoughts would be appreciated.

Andrew

After a little playing with it I discovered that a bad query doesn't generate a result (the query above was badly constructed... my bad).

As an example:

$result = $proxy->Search(array("query" => "(type=='C510' || type=='C525')","IncludeDetails" => true,"IncludeDynamicInfo" => true));

works just fine... however

$result = $proxy->Search(array("query" => "(type=='C510' || type=='C525') && status=5","IncludeDetails" => true,"IncludeDynamicInfo" => true));

generates nothing. 

There are two thoughts to this:

1) The API should generate an error if the query is bad
2) As far as I can see from your API the second query is good!

Any thoughts?

Andrew

The issue with the query above that doesn't work isn't the API it's your doc.

Your example is:

type=='P28R' && (dest=='ORL' || dept=='ORL') && status=5

it should be

type=='P28R' && (dest=='ORL' || dept=='ORL') && status==5

Which is obvious if you think about it since it is a C query

I would still like to see an error on the bad query however.

Andrew

Hey Andrew! Right you are. I've gone ahead and corrected the typo in the docs. As for the error, you're correct - it should be generating an error when the query is malformed. I'll check into that and see if we can get a fix up in the next 24 hours.

Thanks for the eagle-eye on the bugs :)

Thanks. 

BTW what does the status "Decontrolled" mean?  It does not appear in your documentation.

Are you planning to give a full list of all of the fields and their meaning such as "BBOX"

Thanks,

Andrew

At the current time, "decontrolled" is not used and will probably be removed from the docs. BBOX is a lat/lon bounding box for the entire flight (including the departure and destination airports, plus a small buffer zone).

Thanks.

Do you know when you will have pricing for this service?

It's likely due within the next 30 days; we're just waiting for some good solid loading performance to back it up.

I'm still working with "Search"

If I have IncludeDetails set to false then DepartureTime is output as a conventional PHP-style unixtime.  If it is set to true it's output as text eg 04/09/2009 08:55 AM EDT (1255Z).

I'm not sure of the logic behind the change based on that parameter.  It would be ideal if all times were in unixtime format.

Regards

Andrew

Wow, that's an odd one! I'll run some tests today to see what's up.

We're considering the option of converting all times to Unix times for Beta2; our primary reason for this was that the "human readable" times are likely the end desired result for most interfaces anyway, and they're appropriately adjusted for the correct time zones automatically, as well as including the time zone itself, and we already provide a "computational" time in the form of the "Arrival Minutes" field, which tells you how many minutes before a flight arrives, or how many minutes since it has arrived.

If we do convert to Unix times, we'll end up sending them as GMT/Zulu times and then including a field for the time zone (GMT Offset)... but we'd love to hear your feedback. Can you tell me of some instances where having a "computational" time would help out over how the info is conveyed now?

My application is to display flight information on a user group website (two different ones actually).

Those sites already have infrastructure to display time/dates in whatever format the user would like to see and in whatever timezone he is located in.  The ideal for me if to get all times from you in a unix format (eg 1239289782) which is of course referenced to GMT/Zulu.  Starting from that common format I can use PHP's date() and and the existing timezone correction infrastructure of my sites to display your timestamps in the same format and referenced to the same time zone as everything else on the site (for that specific user).  If I use your dates in a textual format, I need to backwards convert them back to unixtime so that I have a common frame of reference to work from.  I also need a Zulu time to work from so that I have a common frame of reference.

The ideal would be to (as you suggest) get all times as unixtime with a local timezone correction in a field in case I need to show times in a destination timezone rather than the users default timezone.  The latter is "nice to have" as far as I'm concerned.  However I can see that it would be much more important for others.

Andrew

agreen:

Wow, that's an odd one! I'll run some tests today to see what's up. We're considering the option of converting all times to Unix times for Beta2; our primary reason for this was that the "human readable" times are likely the end desired result for most interfaces anyway, and they're appropriately adjusted for the correct time zones automatically, as well as including the time zone itself, and we already provide a "computational" time in the form of the "Arrival Minutes" field, which tells you how many minutes before a flight arrives, or how many minutes since it has arrived. If we do convert to Unix times, we'll end up sending them as GMT/Zulu times and then including a field for the time zone (GMT Offset)... but we'd love to hear your feedback. Can you tell me of some instances where having a "computational" time would help out over how the info is conveyed now?

Hello,

I think I may be at a disadvantage it would seem.  I can get data ok via the API, but only using the query method.  That's ok with me, if I can get everything that way.  My question is, is the doc to reference for creating these queries?  For example, I'm not sure what the "type" of P28R means.  Is there somewhere that lists these types and describes their meaning?  FAA.GOV maybe?

Also, is there a listing of the possible queries that can be used in the documentation and the values that are returned?

Thanks in advance,

Darren

I've actually found the documentation on the codes, but am not getting a formatted reply with the airport info data structure (or any).  I can actually receive a response if I do a search as in the example above, but when I try one of the other functions nothing is returned.  Can you tell from the following code if I'm doing something wrong?

Thanks,

Darren

require_once('soap/nusoap.php');

$auth = array(
'user' => 'My User Name',
'pass' => 'My API Key',
);
$result = array();  
$url = "http://planexml.flightwise.com/ws/PlaneXMLbeta1.asmx?WSDL";
$client = new nusoap_client($url,$auth);

$proxy = $client->getProxy();
$result = $proxy->AirportInfo('ORL',true,true);
print_r($proxy);  (shows WSDL)
print_r($result); (No results)

I've now picked this up again and am testing with the beta 2 API.

The above issue is still there.  If IncludeDetails = false then I get unixtime, if it is true I get a text version of the time.

Thanks for looking at it.

Andrew