Can machine learning help identify regional airports that have the potential to support commercial airline service? What does it take to build an application that combines geographic information, demographic statistics, economic indicators, and aviation data into a meaningful analytical tool? And how much of that work actually involves machine learning versus traditional data engineering and software development?
In this episode, host Krish Palaniappan speaks with Mandar Chaudhari, a full-stack geospatial engineer at Land IQ and aviation researcher at George Mason University. Mandar walks through RASAT (Regional Air Service Analysis Tool), a research application developed through his work with Dr. Lance Sherry at the Center for Air Transportation Systems Research. Their conversation explores the problem RASAT addresses, its underlying architecture, the selection of machine learning algorithms, data processing pipelines, geospatial visualization, and the broader challenges of building products that solve meaningful problems.
Podcast
A practical exploration of regional airport viability, machine learning, data engineering, model explainability, and the challenges of turning research into useful software — on Apple and Spotify.
Understanding the Problem: Which Airports Could Support Commercial Service?
The United States has thousands of airports, but only a portion offer regularly scheduled commercial passenger flights. Some serve private aviation, flight training, and other general aviation activities, while others provide commercial service supported by federal subsidies through the Essential Air Service (EAS) program. RASAT attempts to identify airports whose surrounding communities exhibit characteristics associated with successful commercial airline operations. Consider a small town where residents must drive several hours to reach an airport with scheduled flights. If that community has a growing population, meaningful economic activity, and tourism demand, could its local airport potentially support commercial service?
RASAT categorizes airports into three groups: Type 1 airports without scheduled commercial passenger service, Type 2 airports with subsidized service, and Type 3 airports with unsubsidized commercial service. Type 3 airports provide positive training examples because they already support commercial operations without subsidies, while Types 1 and 2 provide contrasting examples. The objective is to identify airports in the latter groups whose characteristics resemble those of airports already supporting unsubsidized service. Mandar emphasizes that the tool is intended for initial screening rather than replacing detailed aviation feasibility studies, which must also consider passenger demand, airline economics, operating costs, aircraft availability, and other operational factors.
Using Machine Learning Instead of Manually Weighted Rules
One approach to evaluating airports would be to identify relevant characteristics, assign weights to each, and calculate an overall score. Krish raises this possibility, comparing the problem to evaluating a collection of records through a consistent set of parameters. RASAT takes a different approach by using XGBoost, an open-source machine learning library particularly well suited to structured, tabular datasets. Rather than manually assigning fixed weights, the model learns relationships between airport characteristics and existing commercial service patterns.
The research incorporates approximately 45 features covering demographics, economics, hospitality, alternative transportation, nearby airports, ports, borders, and industry composition. Population, population growth, median household income, poverty rates, gross regional product, tourism activity, and proximity to other commercial airports provide different perspectives on potential passenger demand. Some relationships are indirect. For example, proximity to a seaport may indicate logistics, manufacturing, or international trade activity that could contribute to business travel, even though the port itself primarily handles freight.
Mandar explains that the feature selection process was informed by aviation expertise and the availability of consistent data across airports, rather than relying on another AI model to recommend parameters. The team considered alternatives such as logistic regression and random forests before selecting XGBoost for its ability to capture nonlinear relationships and interactions between variables. A large population alone may not indicate strong commercial potential, but population combined with tourism activity and limited access to alternative airports could provide a more meaningful signal.
Understanding Commercial Viability Scores and Model Explainability
RASAT generates a commercial viability score for each airport, indicating how closely its regional characteristics align with patterns learned from airports supporting unsubsidized commercial service. During the demonstration, Mandar selects Friedman Memorial Airport in Idaho, which receives a score of approximately 92.3. John F. Kennedy International Airport receives a score of approximately 90, illustrating an important distinction: the score is not a ranking based on airport size, passenger volume, or proximity to a major international hub. A smaller airport can receive a higher score than a major airport because the model evaluates regional characteristics rather than treating the largest airports as ideal benchmarks.
The application also explains which features influence individual predictions using SHAP, a technique for interpreting machine learning outputs. Instead of presenting a score without context, RASAT displays feature contributions so researchers can understand which variables influence an airport’s assessment. For example, median household income, proximity to tourist destinations, or distance from alternative airports may contribute differently depending on the airport being evaluated. These are not fixed coefficients applied uniformly across every airport. Their influence varies according to the relationships learned by the model. The demonstration also surfaces a presentation issue: the displayed feature contributions do not appear to total 100%, potentially because some features are omitted from the interface. This reinforces the importance of ensuring that model explanations are presented accurately and transparently.
Data Engineering: The Foundation of the Application
A significant portion of the discussion focuses on the work required before machine learning can begin. RASAT combines information from several public sources, including the U.S. Census Bureau, Federal Aviation Administration, Department of Transportation, Bureau of Economic Analysis, National Park Service, and OpenStreetMap. These sources provide data in different formats, including JSON responses from APIs, downloadable CSV files, spreadsheets, and geographic datasets. The engineering challenge is to collect, preserve, clean, normalize, and combine this information into a consistent representation for every airport.
Mandar describes a Python-based data processing pipeline that begins by preserving the original source files. Separate scripts retrieve datasets, standardize identifiers, handle missing values, and convert information into compatible structures. Geographic aggregation is particularly important because many demographic and economic datasets are organized by county rather than airport. RASAT uses airport coordinates to identify surrounding counties within a defined catchment area, generally around 60 miles for regional demographic features, and aggregates the relevant information into airport-level records. This transforms disparate county-level statistics into features that can be associated with individual airports.
Interestingly, the application does not rely on a traditional SQL, NoSQL, or vector database. Its research-oriented architecture uses files throughout the processing pipeline. Once the data is prepared and the machine learning model has generated its predictions, the application stores airport records, feature values, scores, and contributions in precomputed JSON files. The web application loads these records and displays the relevant information when a user selects an airport. Updated source data can be incorporated by rerunning the Python pipeline and regenerating the output files. This architecture keeps the application relatively straightforward while separating data preparation and model execution from the user-facing interface.
Local Machine Learning Development and Cloud Costs
The conversation also examines whether machine learning applications require expensive cloud infrastructure. Mandar explains that RASAT’s data processing, feature engineering, and model training were performed locally on his computer, with the web application deployed through a hosting platform. The relatively modest dataset—roughly a few thousand airports with approximately 45 features each—does not inherently require large-scale distributed infrastructure.
Krish connects this to a broader concern faced by independent developers and startups: the cost of cloud services, model usage, and infrastructure during experimentation. While cloud platforms such as AWS offer substantial capabilities, usage-based pricing can become expensive without appropriate controls. Mandar contrasts RASAT’s local development approach with his professional work at Land IQ, where AWS services such as EC2 and Lambda support hosted applications and data processing workflows. Their discussion highlights the importance of choosing infrastructure according to actual project requirements rather than assuming every machine learning application needs an elaborate cloud architecture.
Building an Interactive Geospatial Application
RASAT uses Mapbox to visualize airports geographically and allow users to explore their surrounding regions. The interface includes an airport selector, commercial viability scores, feature values, contribution indicators, and an interactive map. Airports are distinguished by their service categories, and users can inspect locations and nearby alternatives. Geographic visualization is particularly relevant because proximity to other commercial airports, regional population centers, and transportation infrastructure influences how an airport’s potential should be interpreted.
Krish questions whether a graphical interface is necessary when the underlying information could be queried through an API or conversational interface. Mandar acknowledges that questions such as identifying the five highest-scoring airports without commercial service could be answered directly from the processed data. RASAT also provides downloadable rankings that can be filtered and sorted. However, he argues that the map and dashboard support a different kind of exploration. A researcher may not know which questions to ask initially, and seeing nearby airports or geographic relationships can reveal patterns that might not emerge from a textual response. The distinction is between retrieving a known answer and discovering relationships through visual exploration.
Limitations: Airfare, Passenger Behavior, and Real-World Demand
One of the more interesting exchanges concerns factors that RASAT does not currently incorporate. Krish uses the Washington, DC metropolitan area as an example, where travelers may choose among Dulles International Airport, Reagan National Airport, and Baltimore/Washington International Airport. Proximity matters, but passengers may willingly travel farther for cheaper tickets, more convenient schedules, or direct flights. If an airport scores highly based on regional population and economic activity, does that necessarily mean passengers will choose to fly from it?
Mandar acknowledges that airfare is an important limitation of the current model. Airports without scheduled passenger service do not have existing airfare data, while prices at operating airports vary significantly by airline, destination, season, and booking date. This makes it difficult to construct a consistent pricing feature across the dataset. Similarly, strong regional characteristics do not guarantee actual passenger demand. For airports already offering commercial service, passenger traffic and load factors can provide additional context, but airports without service lack equivalent historical observations.
The discussion identifies a potential direction for further research: comparing predicted viability against observed passenger behavior, including where residents currently travel to catch flights, what they pay, and which destinations they choose. Such information could help distinguish between an airport that appears promising based on regional characteristics and one that could realistically attract sufficient passengers to support airline operations.
Where Does the Engineering Effort Actually Go?
Krish asks Mandar to hypothetically divide 100 hours of project development across research, data acquisition, processing, machine learning, and interface development. Mandar estimates that problem definition might account for approximately 10 hours, data discovery and validation for 20, cleaning and feature engineering for 20, pipeline integration and machine learning for another 20, and experimentation and evaluation for approximately 20 more. The remaining 10 hours would go toward the web application and integration.
Although these are illustrative estimates rather than actual project time records, they reveal an important characteristic of applied machine learning: the majority of the work may occur outside the visible application. Mandar identifies research and analysis as the most challenging aspects, while building the interface was comparatively straightforward. The discussion also considers how AI-assisted coding tools are changing the skills required for projects like RASAT. When asked which capabilities he would prioritize when hiring someone for similar work, Mandar identifies problem-solving and analytical thinking first, followed by data engineering and data literacy. Programming remains useful, but the ability to define ambiguous problems, identify suitable data, and evaluate results is central to the project’s success.
From Software Engineer to Product Builder
The final portion of the conversation moves beyond aviation analytics when Mandar asks Krish how an engineer can develop a product-oriented mindset. Drawing on his experience building products at Snowpal, Krish explains that developing technically sophisticated software is only one part of creating a successful business. Engineers accustomed to receiving requirements may underestimate the difficulty of identifying customer needs, validating demand, marketing products, acquiring customers, and generating revenue.
One of his most important lessons is that developers frequently overestimate the value of features they find technically challenging. A capability that required months of engineering might generate little customer interest, while a relatively simple feature could prove highly valuable. This creates a difficult psychological challenge: developers become attached to what they build and may resist removing or simplifying features that customers do not need.
Krish advocates shipping early versions quickly, even when they lack the polish developers would ideally prefer. The goal is to validate the core value of a feature before investing heavily in supporting functionality. He compares this to demonstrating the experience of living on the 57th floor of a building without first constructing and presenting all 56 floors beneath it. In software, the challenge is finding ways to demonstrate the most valuable capability without spending excessive time building infrastructure that customers may not care about.
The conversation also addresses entrepreneurship more broadly. Krish emphasizes that starting a company involves substantially more than engineering and is rarely the easiest path to making money. Sales, customer acquisition, product positioning, hiring, and sustaining motivation can prove more difficult than writing the software itself. For engineers considering entrepreneurship, understanding these responsibilities is essential to moving from implementing requirements to building products that people actually want.
Conclusion
RASAT provides a practical example of applying machine learning to a real-world transportation research problem. By combining public aviation, demographic, economic, and geographic datasets, the application helps researchers identify regional airports whose characteristics suggest potential for unsubsidized commercial service. Its architecture demonstrates how Python-based data pipelines, XGBoost, SHAP, precomputed JSON files, and Mapbox can work together without requiring an expensive or unnecessarily complex infrastructure.
Equally important are the broader engineering lessons that emerge from the discussion. Selecting an algorithm is only one part of building an analytical application. Understanding the problem, collecting reliable data, designing meaningful features, explaining predictions, recognizing limitations, and presenting results in a useful form all contribute to the quality of the solution. The conversation also reinforces the distinction between creating technically sound software and building a successful product.
For students, early-career engineers, and independent developers, Mandar’s experience offers an encouraging example of what can be accomplished with publicly available datasets, established machine learning libraries, and a focused research question. Meaningful software does not necessarily require a large team or expensive infrastructure, but it does require curiosity, disciplined problem-solving, and a willingness to test assumptions.