Not every platform improvement needs to introduce a completely new feature. Sometimes, a relatively small change behind the scenes can remove unnecessary work today — while creating the foundation for much more tomorrow.
That is exactly what we have done with the Airports module in eAvio Platform.
We have expanded and standardized the way airport and aerodrome data is stored, introduced direct integration with OpenAIP, and made it significantly easier for operators to build and maintain their own list of locations.
From selecting a country to a ready-to-use airport list
The most visible part of the update is our new OpenAIP integration.
Administrators can now simply select a country and choose to import its locations. eAvio handles the rest in the background, communicating directly with OpenAIP through its API and adding the available locations to the organization’s database.
The same process can also be used to update existing data when needed.
There are no files to download, prepare, or upload. More importantly, an organization no longer needs to wait for us to prepare its initial airport list. The process is available directly inside eAvio and is fully automated.
Airports, aerodromes — and your own locations
Although we call it the Airports module, the underlying concept is deliberately broader.
Not every location used in aviation has an ICAO code, and an ICAO code is therefore no longer a mandatory identifier in eAvio. This gives the data model more flexibility to represent different types of aerodromes and other locations relevant to an operator.
Organizations can also continue to add their own custom locations. This is useful for locations that may not be available through OpenAIP or another standardized data source.
The difference is that all of these locations can now live within a cleaner and more consistent data structure.
We have also expanded the information that can be stored for each location, including data such as precise coordinates and elevation.
More data in the background, not more complexity for pilots
Expanding the airport database does not mean adding unnecessary information to the pilot-facing interface.
On the frontend, airports remain what pilots need them to be: a fast and simple way to select the relevant departure, arrival, or other location.
eAvio also continues to prioritize locations based on actual usage. The airports and locations most frequently used by an organization are presented at the top, so expanding the database does not mean pilots have to search through an increasingly long list every time they use the platform.
The database can become richer while the everyday experience stays simple.
A small update with a bigger purpose
There is another reason we invested in the underlying airport data model
Standardized location data gives us a much better foundation for what comes next.
Knowing more about a location — and having that information represented consistently — can eventually support smarter workflows around flight planning, flight orders and automated validations.
For example, location data could become another layer of context when checking a flight order or planning a flight. Coordinates, elevation and other airport information create possibilities that simply do not exist when a location is stored as little more than a name and a code.
Those are directions for future development rather than features we are announcing today. But building them starts with getting the underlying data right.
The latest Airports update does exactly that: less manual work for administrators today, a more standardized source of airport data across eAvio, and a stronger foundation for the features we build tomorrow.
