3 ms·

"Give me a list of all flights originating at LAX, SFO, SEA and terminating at JFK or MIA, with at least one connection in either SLC or MSP with a minimum conn

"Give me a list of all flights originating at LAX, SFO, SEA and terminating at JFK or MIA, with at least one connection in either SLC or MSP with a minimum connection time of 3 hours and include every airline except Delta and Spirit. Do not include results if they require more stops than the minimum possible stops" Origin: "LAX, SFO, SEA" Destination: "JFK, MIA" Outbound routing codes: "SLC,MSP ~DL,F9+" Outbound extension codes: "MINCONNECT 3:00" Extra stops -> No Extra Stops. You can also use extension codes to find flights based on duration or number of miles flown. Edit: Actually a better example to show the power of ITA would be something like "~DL,AA,UA SLC,MSP AA" for the outbound routing code, which says "don't use Delta, American or United for the first segment (to SLC/MSP) and do use American for the second segment (from SLC/MSP)"

apaprocki 5y ago
This kind of software is what I lump into the category of "just give me regular expressions". There's so many interfaces that would be simplified by (hard!) standardizing textual abbreviations and providing something powerful like regular expressions. I'm currently shopping for expansion PEX (a.k.a. F1960) fittings and it drives me up a wall when all you want is sizeA: 1", sizeB: 1", typeA: F1960, typeB: MNPT and all you can use is a free text query. Search for '1" F1960 MNPT' or equivalent and you get back all kinds of things that have nothing to do with what you searched for. That's par for the course when businesses don't have what you want and they're trying to give you anything to not have zero results -- but in this case they do have the parts, their crap search just doesn't return them. Try searching for PEX-A vs PEX-B at Home Depot and it's clear many people will accidentally buy the wrong thing. Airline searches (for me, at least) were very similar. 99% of engines would not give you results spanning across two tickets (no codeshare agreement) or take into account human factors. More recently, search results started to show "pain factor" mostly as an amount of connection time or overall trip time. That (again, for me) is not pain -- pain is connecting in LHR or CDG when you could connect in VIE or WAW. Or worse, getting some flight pushed in your face on a single ticket that has a LHR/LGW transfer vs. two separate tickets in a much smaller airport further east. Similarly, why not offer a plane type filter on every search? Pain is flying on some 20-30 year old airframe on a big airline instead of a Dreamliner on a smaller one. (LOT, if you're interested... :))
- ngcc_hk 5y ago
  I would say network graphic operational research code more. May be the interface is like regular expression. But wonder underlying code is not.
- rchowe 5y ago
  I'd argue ITA Matrix serves folks that know airports and aircraft well enough to figure the human factors in their heads (e.g. if you can fly Delta and connect in either AMS or CDG, choose AMS), and just want to find a valid solution set at the lowest price for a query. The lack of split ticketing means you will be protected in the case of a misconnect. I'd say this is a good case for a declarative language like SQL or Prolog: "just give me X that satisfies Y and Z, I don't care how you get it." Existing search engines either have a painful number of dropdown menus or are free-text only with limited power user features.

apaprocki 5y ago

This kind of software is what I lump into the category of "just give me regular expressions". There's so many interfaces that would be simplified by (hard!) standardizing textual abbreviations and providing something powerful like regular expressions. I'm currently shopping for expansion PEX (a.k.a. F1960) fittings and it drives me up a wall when all you want is sizeA: 1", sizeB: 1", typeA: F1960, typeB: MNPT and all you can use is a free text query. Search for '1" F1960 MNPT' or equivalent and you get back all kinds of things that have nothing to do with what you searched for. That's par for the course when businesses don't have what you want and they're trying to give you anything to not have zero results -- but in this case they do have the parts, their crap search just doesn't return them. Try searching for PEX-A vs PEX-B at Home Depot and it's clear many people will accidentally buy the wrong thing. Airline searches (for me, at least) were very similar. 99% of engines would not give you results spanning across two tickets (no codeshare agreement) or take into account human factors. More recently, search results started to show "pain factor" mostly as an amount of connection time or overall trip time. That (again, for me) is not pain -- pain is connecting in LHR or CDG when you could connect in VIE or WAW. Or worse, getting some flight pushed in your face on a single ticket that has a LHR/LGW transfer vs. two separate tickets in a much smaller airport further east. Similarly, why not offer a plane type filter on every search? Pain is flying on some 20-30 year old airframe on a big airline instead of a Dreamliner on a smaller one. (LOT, if you're interested... :))

ngcc_hk 5y ago
I would say network graphic operational research code more. May be the interface is like regular expression. But wonder underlying code is not.
rchowe 5y ago
I'd argue ITA Matrix serves folks that know airports and aircraft well enough to figure the human factors in their heads (e.g. if you can fly Delta and connect in either AMS or CDG, choose AMS), and just want to find a valid solution set at the lowest price for a query. The lack of split ticketing means you will be protected in the case of a misconnect. I'd say this is a good case for a declarative language like SQL or Prolog: "just give me X that satisfies Y and Z, I don't care how you get it." Existing search engines either have a painful number of dropdown menus or are free-text only with limited power user features.