Go Back  FlyerTalk Forums > Miles&Points > Mileage Run Deals > Mileage Run Discussion
Reload this Page >

TIP: More hidden features of ITA

Community
Wiki Posts
Search
Old Jan 21, 2015, 10:55 am
FlyerTalk Forums Expert How-Tos and Guides
Last edit by: hillrider
Here are some more hidden features of the ITA software.

The extensions to the itasoftware routing language are accessed by postpending commands after a '/'. There's a wide set of commands available, but there's no description of them available on the ITA web site. Unfortunately, each command applies only to one part of the trip, so they must usually be entered in each box.

EXCLUDE SPECIFIC AIRLINES
Command is "-airlines XX ..."
Ex: prohibit jetBlue or Delta
from: BOS ::/ -airlines B6 DL
to: LAX ::/ -airlines B6 DL

LIMIT TO SPECIFIC AIRLINES
Command is "airlines XX ..."
Ex: consider only jetBlue or Delta
from: BOS ::/ airlines B6 DL
to: LAX ::/ airlines B6 DL

LIMIT TO A SINGLE ALLIANCE
Command is "alliance star-alliance|oneworld|skyteam"
Ex: oneworld carriers only
from: BOS ::/ alliance oneworld
to: LAX ::/ alliance oneworld

EXCLUDE CODESHARES
Command is "-codeshare"
Ex: prohibit jetBlue or Delta
from: BOS ::/ -codeshare
to: LAX ::/ -codeshare

LIMIT DURATION OF ITINERARY, IN MINUTES
Command is "maxdur XXX"
Ex: no more than 5hrs for each part of trip
from: BOS ::/ maxdur 300
to: LAX ::/ maxdur 300

EXCLUDE OVERNIGHT STOPS, AIRPORT CHANGES, REDEYES, PROPELLER PLANES, TRAINS, HELICOPTERS, ANY KIND OF SURFACE TRAVEL
Commands are "-overnight", "-change", "-redeye", "-prop", "-train", "-helicopter", "-surface"
Ex: no overnight stops, no airport changes, no redeyes, no propeller planes
from: BOS ::/ -overnight, -change, -redeye, -prop
to: LAX ::/ -overnight, -change, -redeye, -prop

SET MINIMUM OR MAXIMUM TIME FOR CONNECTIONS, IN MINUTES
Commands are "minconnect XX", "maxconnect XX"
Ex: no less than one hour, no more than two hour connections
from: BOS ::/ minconnect 60, maxconnect 120
to: LAX ::/ minconnect 60, maxconnect 120

EXTRA CONNECTION TIME
Command is "padconnect XX"
Ex: require at least 20 minutes more than airline specified minimum connection time
from: BOS ::/ padconnect 20
to: LAX ::/ padconnect 20

PUTTING LOTS OF THINGS TOGETHER
Separate with commas.
Ex:
from: BOS :: UA UA / f bc=l|bc=y, -redeye, -prop
to: LAX :: UA+ / f ua.bos+lax.yup, padconnect 20, -overnight
Print Wikipost

TIP: More hidden features of ITA

Thread Tools
 
Search this Thread
 
Old Oct 25, 2011, 1:25 pm
  #151  
 
Join Date: Aug 2010
Posts: 286
Originally Posted by igopogo
First, 25! combinations would imply that you are looking at routes that are 25 legs long. In fact, if you are looking at ALL possible routes, there would be even more than that
Indeed, I left out the direct routes (and everything in between) because the number of paths was large enough to make my point.

Originally Posted by igopogo
But, searching algorithms that find the cheapest path are MUCH more sophisticated than simply checking every possible solution and finding the shortest one.
Sophistication buys you nothing. It costs. It increases software bug density. You need the sophistication to get a reasonable answer in a reasonable amount of time -- but it's a necessary evil, not a benefit that is good to have.

Originally Posted by igopogo
They quickly eliminate whole groups of paths that cannot possibly lead to a solution. There are 25 vertices and (if I remember Euler correctly) 552 edges in your example. The dijkstra algorithm can find the cheapest path in 25*552=13800 computational steps, maximum.
The dijkstra algorithm is an approximation. That's why it gets an answer that is good enough in an acceptable amount of time.

Last edited by garyschmitt; Oct 25, 2011 at 1:37 pm
garyschmitt is offline  
Old Oct 25, 2011, 1:35 pm
  #152  
In memoriam
 
Join Date: Feb 2004
Posts: 692
Just to throw in two more cents... ITA Software (based in Cambridge, Mass) is packed with MIT and Harvard computer engineers. (Check out some of their staff: http://www.itasoftware.com/careers/l...ur-people.html)

I point this out in support of what igopogo wrote above-- I'm sure they already know the way to shave computing cycles off searches. I think ITA's real challenges are all in product management (i.e. specific user experience and featureset), not computing cycles, search timeouts or other raw horsepower issues.

(And they're probably staying awfully busy with Google integration, too...)
pnoeric is offline  
Old Oct 25, 2011, 1:44 pm
  #153  
 
Join Date: Aug 2010
Posts: 286
Originally Posted by pnoeric
Just to throw in two more cents... ITA Software (based in Cambridge, Mass) is packed with MIT and Harvard computer engineers. (Check out some of their staff: http://www.itasoftware.com/careers/l...ur-people.html)
Indeed - you need very skilled engineers for this problem.

Originally Posted by pnoeric
I point this out in support of what igopogo wrote above--
This doesn't support igopogo's point, it supports mine. If one could simply apply an algorithm as common as dijkstra, you could hire high-schoolers for the job.

Originally Posted by pnoeric
I'm sure they already know the way to shave computing cycles off searches. I think ITA's real challenges are all in product management
I disagree. Look at their job applications. They're computational and programmatic puzzles. They're looking for more good engineers.
garyschmitt is offline  
Old Oct 25, 2011, 1:51 pm
  #154  
In memoriam
 
Join Date: Feb 2004
Posts: 692
Originally Posted by garyschmitt
Indeed - you need very skilled engineers for this problem.
Perhaps I misunderstood your original post.

Originally Posted by garyschmitt
I disagree. Look at their job applications. They're computational and programmatic puzzles. They're looking for more good engineers.
I see their open positions, but that doesn't dissuade me from thinking they need to focus on product management at least as much as the engineering side of things. Currently ITA looks like a fantastic power-tool that is designed and built by engineers.... that's awesome, and we all love it, and use it all the time. But in taking that power tool and making it part of Google (unsurprisingly, another company [and set of products] designed and built by engineers), they will want to be thinking more "big picture" about the features more mainstream customers want and how to make them more user-friendly.

(Of course, for those of us here on Flyertalk... we probably want more powertool-y functionality... damn the interface, full speed ahead! )
pnoeric is offline  
Old Oct 25, 2011, 2:04 pm
  #155  
 
Join Date: Aug 2010
Posts: 286
Originally Posted by pnoeric
Perhaps I misunderstood your original post.
The bottom line is that finding the definitively cheapest airfare is an unsolved problem. There is simply not enough processing power available to tackle the problem, even with the most sophisticated algorithms that find exact answers. Hence why adding restrictions to your search can sometimes reveal a better price. All aggregators apply a "lossy" algorithm, which very quickly finds something that is likely to be close to the best airfare. It's generally good enough, but it's a trade-off.

They can only let you leech so much CPU. Some search tools out there offload some of the processing into the visitors machine (e.g. dohop), so the server gives you a small database, and you run javascript to find the best route from a small number of relevant records.

Originally Posted by pnoeric
I see their open positions, but that doesn't dissuade me from thinking they need to focus on product management at least as much as the engineering side of things.
Certainly there are copious limitations of ITA software (even though it's the most powerful all-around search tool). Perhaps the biggest limitation is that it cannot handle multi-booking flights. This means it often does not find the cheapest route (it finds the cheapest convenient flights). I would hate to see resources wasted on management as opposed to improving a tool that clearly has plenty of room to evolve.
garyschmitt is offline  
Old Oct 25, 2011, 2:12 pm
  #156  
In memoriam
 
Join Date: Feb 2004
Posts: 692
Originally Posted by garyschmitt
Some search tools out there offload some of the processing into the visitors machine (e.g. dohop), so the server gives you a small database, and you run javascript to find the best route from a small number of relevant records.
How interesting! I just tried dohop and here's the records they dump onto my computer, to let me do super-quick local filtering/sorting. Love this approach.

http://ds.dohop.com/search/?lang=en&...1211&d2=141211
pnoeric is offline  
Old Oct 25, 2011, 6:29 pm
  #157  
 
Join Date: Nov 2007
Location: MSP
Programs: DL PM, Hilton Diamond
Posts: 710
Originally Posted by garyschmitt
Indeed - you need very skilled engineers for this problem.

I disagree. Look at their job applications. They're computational and programmatic puzzles. They're looking for more good engineers.

And skilled Flyertalkers. I use ITA as an iterative search engine. e.g.

I first search MSP to ONT (and include neighboring airports and +/- 1 day) to get an overall idea of general fares

I then limit it to the cheapest airport/day combinations and add in DL+ and/or DL, DL, DL

I then try forcing it between certain city pairs (usually those that are served by competitors) For example for ONT, I might force it through LAX.

I often throw in different hub cities to see if I can bring the mileage up, etc.

I definitely find that often more search criteria = cheaper fares, but of course, not always.
Cellisttoo is offline  
Old Oct 25, 2011, 6:34 pm
  #158  
 
Join Date: Nov 2010
Location: SFO
Posts: 305
Originally Posted by garyschmitt
Sophistication buys you nothing. It costs. It increases software bug density.
It's sophisticated, not complicated. You're right, a high school student could do it.

Originally Posted by garyschmitt
The dijkstra algorithm is an approximation. That's why it gets an answer that is good enough in an acceptable amount of time.
Dijkstra will be very unhappy to hear that. Whoops, if he were alive. He was under the impression that it arrived at a solution. He's got a bunch of mathematicians convinced also.

My only point was, the search is not an unsolved problem in **math**, and the cheapest route can be solved quickly. But finding the absolute cheapest route is not necessarily what ITA wants to do. The cheapest route may not have seats available, or may not be one that the average Joe wants to take (i.e. may involve a couple 23 hour layovers and a trip to Alaska and back, or maybe a 5-minute connection at DFW). Sure, we'd like to find the lowest fare even it means spending some time 2000 miles off our path...might prefer it actually. But ITA is in the business of serving average joes (or helping airlines serve average joes) so I'm gonna guess that more "thought" goes into determining what constitutes a reasonable, available route, and finding those routes. Working in the squishy, social, computer-guessing-what-a-human-wants is exactly what google (whoops, ITA) engineers are supposed to be doing. This is almost an unsolved (or perhaps un-optimized) problem in social science.

They like us to bang on their system and see if it works, but they are really not designing the system for us. And certainly they are not going to give us access to an algorithm that takes one full minute of real server time, that would be way too expensive.
igopogo is offline  
Old Oct 25, 2011, 9:57 pm
  #159  
FlyerTalk Evangelist
 
Join Date: Mar 2004
Location: SGF
Programs: AS, AA, UA, AGR S (former 75K, GLD, 1K, and S+, now an elite peon)
Posts: 23,194
Originally Posted by pnoeric
Currently ITA looks like a fantastic power-tool that is designed and built by engineers.... that's awesome, and we all love it, and use it all the time. But in taking that power tool and making it part of Google (unsurprisingly, another company [and set of products] designed and built by engineers), they will want to be thinking more "big picture" about the features more mainstream customers want and how to make them more user-friendly.
Don't forget that Google isn't the only user of ITA's product and they aren't just concerned about making it human-usable in the future...that stuff is already happening now. ITA powers several airlines' search results, including Alaska's. It's highly customized to favor results on AS metal and only search a limited subset of partner carriers and fares.

ITA's matrix is a publicly-accessible testbed with access to the raw data and technology they offer, but it is far from the core market and focus of ITA's resources.

I'd still like (and would pay for!) a power-user tool, though.
jackal is online now  
Old Nov 13, 2011, 10:21 am
  #160  
 
Join Date: Apr 2008
Posts: 389
I've noticed that if you look at the booking details of an itinerary using Matrix 2, the base fare is displayed in the currency of the sales city, whereas in Matrix 1 it's always displayed in the airline's currency of record. Is it possible to force Matrix 1 to change the currency in which it displays the base fare?

(I see that the fare construction at the bottom of the booking details page in Matrix 1 does display the equivalent in the sales city currency, but this is rounded off to the nearest unit, and so it is usually slightly different from the amount displayed by Matrix 2.)

Alternately can anyone suggest a way to look up the current NUC conversion rates?
palefire is offline  
Old Nov 13, 2011, 10:29 am
  #161  
 
Join Date: Aug 2007
Location: Near SEA
Programs: UA MM, AS MVPG75K, Marriott Lifetime Gold
Posts: 7,969
Originally Posted by palefire
Alternately can anyone suggest a way to look up the current NUC conversion rates?
xe.com is what I use for conversion rates.
bmvaughn is offline  
Old Nov 13, 2011, 10:33 am
  #162  
 
Join Date: Apr 2008
Posts: 389
Originally Posted by bmvaughn
xe.com is what I use for conversion rates.
Sure. But the current daily exchange rate is generally not the same as the monthly published IATA conversion rates, which is what is needed here.
palefire is offline  
Old Nov 13, 2011, 11:53 am
  #163  
KVS
FlyerTalk Evangelist
 
Join Date: Jan 2004
Location: Worldwide
Posts: 12,949
Arrow

Originally Posted by palefire
I've noticed that if you look at the booking details of an itinerary using Matrix 2, the base fare is displayed in the currency of the sales city, whereas in Matrix 1 it's always displayed in the airline's currency of record. Is it possible to force Matrix 1 to change the currency in which it displays the base fare?

(I see that the fare construction at the bottom of the booking details page in Matrix 1 does display the equivalent in the sales city currency, but this is rounded off to the nearest unit, and so it is usually slightly different from the amount displayed by Matrix 2.)

Alternately can anyone suggest a way to look up the current NUC conversion rates?
Not directly, but you can retrieve Fares in NUC in the KVS Tool, if desired. For example:

[KVS Availability Tool 6.7.0/Diamond - Sabre: Fares/DotRes/US]
Code:
LON  London Metro UK = LHR LGW STN LTN LCY QQS QQW ZLS ZEP
NYC  New York Metro NY US = JFK LGA
R/T  01 Dec 2011 | 15 Dec 2011 | Economy

Carrier    From    To    Fare      Cur                      Fare Basis/TD
---------  ------  ----  --------  ----  --------  ---  --  -------------
TP         LON     NYC       119   NUC                      ALLNTAP
BA         LON     NYC       120   NUC                      OLXUKJB
CO         LON     NYC       120   NUC                      KLXNNZGB
VS         LON     NYC       120   NUC                      OLXMGA
DL         LON     NYC       120   NUC                      TLXPRGB
KL         LON     NYC       120   NUC                      NLXPRGB
US         LON     NYC       120   NUC                      SLXEU0WD
AZ         LON     NYC       120   NUC                      LLXPRGB
FI         LON     NYC       120   NUC                      UQRZSPEC
SN         LON     NYC       120   NUC                      ELXNNZGB
UX         LON     NYC       120   NUC                      PLXPRO20
5W         LON     NYC       159   NUC                      NVIEXRT
BA         LON     NYC       184   NUC                      QLXUKJB
CO         LON     NYC       184   NUC                      LLXNNZGB
VS         LON     NYC       184   NUC                      NLXMGA
DL         LON     NYC       184   NUC                      ULXPRGB
US         LON     NYC       184   NUC                      LLWEU0WD
SN         LON     NYC       184   NUC                      ELWNNZGB
UX         LON     NYC       184   NUC                      QLXPRO20
FI         LON     NYC       194   NUC                      NQRZSPEC
TP         LON     NYC       207   NUC                      KPROMOUK
FI         LON     NYC       249   NUC                      OQRZSPEC
SN         LON     NYC       249   NUC                      LLWNNZGB
5W         LON     NYC       253   NUC                      OVIEXRT
UN         LON     NYC       265   NUC                      VSALE2M
5W         LON     NYC       273   NUC                      OVIEXOW
TP         LON     NYC       273   NUC                      ALTPGB
KU         LON     NYC       298   NUC                      TLE6MGB1
5W         LON     NYC       311   NUC                      SVIEXRT
5W         LON     NYC       343   NUC                      SVIEXOW
UX         LON     NYC       343   NUC                      ALXSX1YS
SK         LON     NYC       346   NUC                      TLUKECO
FI         LON     NYC       346   NUC                      SQRZECON
SU         LON     NYC       353   NUC                      LLPX
TP         LON     NYC       361   NUC                      KLTPGB
AB         LON     NYC       366   NUC                      EFLYRT
BA         LON     NYC       375   NUC                      NLXUKJB
CO         LON     NYC       375   NUC                      TLXNNGBW
VS         LON     NYC       375   NUC                      XLXGB
DL         LON     NYC       375   NUC                      ULXAPGBW
DL         LON     NYC       375   NUC                      ULXSXUK
KL         LON     NYC       375   NUC                      TLXSRGB
US         LON     NYC       375   NUC                      WLXEUNW1
UX         LON     NYC       394   NUC                      ULXSX1YS
5W         LON     NYC       414   NUC                      QVIEXOW
5W         LON     NYC       414   NUC                      QVIEXRT
KU         LON     NYC       423   NUC                      LLE6MGB1
BA         LON     NYC       427   NUC                      SLXUKJB
CO         LON     NYC       427   NUC                      SLXNCGBW
VS         LON     NYC       427   NUC                      QLXGB
Originally Posted by palefire
Sure. But the current daily exchange rate is generally not the same as the monthly published IATA conversion rates, which is what is needed here.
There you go:
http://www.IATA.org/ps/publications/pages/iroe.aspx
KVS is offline  
Old Nov 14, 2011, 12:05 pm
  #164  
 
Join Date: Nov 2011
Location: DEN
Posts: 15
Originally Posted by garyschmitt
The bottom line is that finding the definitively cheapest airfare is an unsolved problem. There is simply not enough processing power available to tackle the problem, even with the most sophisticated algorithms that find exact answers.
I'm not sure if it's just my newbie incapabilities with the ITA software or this unsolved mathematical problem you speak of, but I hope someone can enlighten me on my current dilemma.

I've been looking for the cheapest possible one-way flight from basically anywhere in Europe to SYD between 1 - 10 Dec 2011. I found LIS-BRU-AUH-SYD for $521 on Dec 2, 3 & 5 after a very long search. But now I'm trying to replicate it on ITA by putting 4 other EU airports in the "Departing from" field (LHR, CDG, FRA, MAD, LIS) and SYD as the destination, however the lowest price shows up as $999. What am I missing? Is there a limit of 3 airports that you can search? The $521 (and a recent $515 addition) from LIS show up when it is one of 3 airports, but not when it's the last of 4 or any thereafter.

However, if I put a list of 30 airport codes in, I come out with $665 as the cheapest, but the search finds some flights with some airports that I listed at the end of the line (i.e. LHR, CDG, FRA, MAD, AMS, FCO, MUC, IST, LGW, BCN, ORY, ZRH, DME, AYT, CPH, PMI, VIE, SVO, OSL, DUS, MXP, STN, DUB, MAN, BRU, ARN, ATH, TXL, LIS, HAM, HEL).

Ultimately I'd like to be able to search a number or airports at the same time, instead of one by one and know that I've covered all bases. I've also tried different things in the adv routing codes box as well, like X+, and EY+ (for X+ the cheapest is still $665, and interestingly for EY+ the exact $521 flight comes up but for $579?)

Any wisdom would be greatly appreciated.
flmyngo is offline  
Old Nov 14, 2011, 7:01 pm
  #165  
 
Join Date: Aug 2004
Location: SAT
Programs: AA EXP BA Gold, TK Gold, Hyatt Globalist, Hilton Diamond, AS 100K, QR PLT, SAS Gold, IHG Spire, AMR
Posts: 5,898
why dont you just try to add 5 key cities in Europe to cover the entire region and then expand your search by 300 miles radius?

MAD | DUB | FRA | ARN| FCO should allow you cover most European airports...
Deltahater is offline  


Contact Us - Manage Preferences - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service -

This site is owned, operated, and maintained by MH Sub I, LLC dba Internet Brands. Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Designated trademarks are the property of their respective owners.