Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell and a web service to translate an airport code to a city name.

Microsoft Scripting Guy, Ed Wilson, is here. One thing that I have never really understood is the relationships between airport codes and the airport name. Now, some of them make sense. CLT for Charlotte is not too much of a stretch. LGA for Laguardia in New York also makes sense. But MSY, BNA, and others seem to be completely random.

However, before I get too carried away and try to use Get-Random to do the translation, I thought I would conduct a Bing search and see if I could find something a bit more helpful. I came up with a free web service. I happen to love web services—especially since the New-WebServiceProxy cmdlet made its way into Windows PowerShell 2.0. In fact, over the past several years, I have written about New-WebServiceProxy 15 times. Check out these posts for more excellent examples of how to use this easy-to-use cmdlet.

The airport web service exposes a number of methods. One of the cool things about many web services, is that when I hit the service page, it automatically exposes the web service schema as shown in the image that follows.

Creating the script

The script to connect to the airport web service is really simple. The first thing I do is create a variable to hold the WSDL for the web service. This is the entry point for using the web service, and I obtained it from a directory of web services on the Internet. There are many such directories of free web services available. The one I used is Airport Information Webservice. The web page for the service mentions the WSDL schema location, and all I did was copy it and store it in a variable:

$wsdl = ‘http://www.webservicex.net/airport.asmx?WSDL’

Next, I use the New-WebServiceProxy cmdlet and feed it the URL that is stored in the $wsdl variable. The Namespace parameter and the Class parameter values are not used in this script, but I need to give them something. I often use the values from script to script. I store the returned proxy in the $Proxy variable. This is shown here:

$proxy = New-WebServiceProxy -Uri $wsdl -Namespace proxy -Class ip

Now, I call the GetAirportInformationByAirportCode method. Yeah, I know it is a long method name, but if I have run the script prior to getting to this point, the Tab expansion will pick up the method name, and therefore, I avoid typing it. In addition, by populating the $proxy variable, I know if I have messed anything up, and the script is easier to troubleshoot.

I cast the returned information into an XML document to make it easier to navigate the information I want to obtain. I have hardcoded the CLT airport into the script, but you would want to change that by including a parameter (or even turning this into a function) and creating a module to expose all of the interesting methods. Here is the line of script:

[xml]$rtn = $proxy.getAirportInformationByAirportCode(“CLT”)

Now to display the information. By picking up the NewDataSet.Table property, I show all of the information. I found this by playing around with the output. One thing that might make sense is to combine several properties and display the Lat/Long as a single entity—or maybe not. Who knows, it is up to you. Here is my line of script:

$rtn.NewDataSet.Table

That is it. Four lines of script.

The complete script

The complete script is only four lines long, and it could be written in a single line if one were so inclined. Here is the script.

$wsdl = ‘http://www.webservicex.net/airport.asmx?WSDL’

$proxy = New-WebServiceProxy -Uri $wsdl -Namespace proxy -Class ip

[xml]$rtn = $proxy.getAirportInformationByAirportCode(“CLT”)

$rtn.NewDataSet.Table

When the script runs, it returns the data in a Table property. The output is shown here in the Windows PowerShell ISE output pane:

That is all there is to using Windows PowerShell and a web service to translate an airport code to the city name. Join me tomorrow when I will have more Windows PowerShell goodness.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy