ATLAS: when the network became a map.

Airline colours were part of the rendering engine.

AirlineColors.as is unusually explicit. For each aircraft icon it loads separate SVG components and applies a ColorTransform to the body, wings, tail and engines. This made airline-specific liveries possible while preserving the aircraft's actual silhouette.

// B747
body    → colors.Body
wings   → colors.Wings
tail    → colors.Tail
engines → colors.Engines

The CVS history is equally clear:

A community receiver map

ATLAS was not just a visual frontend for one receiver. The source speaks repeatedly about SBS stations, active senders and sender collections. Stations could be displayed on the map, selected for details, used to show aircraft from that station, and even used to estimate a station's reception range.

Other recovered features include aircraft trails, airport markers, filtering by aircraft type, flight and registration lookup, altitude labels, day/night simulation, aircraft position lights, “ghost” aircraft handling, carrier filtering, sender details and encrypted data streams.

Show aircrafts from this station
Show appr. range for this station
Centre map at aircraft
Centre map at flight
filter by aircraft type

Why it feels familiar today

ATLAS should not be described as “modern crowd-sourced flight tracking before modern crowd-sourced flight tracking” without qualification. By 2010 browser-based aircraft maps and Mode-S receiver networks already existed. What is historically striking is the continuity of the design path: ACARSd had already linked distributed community receivers and remote clients years earlier, and ATLAS turned that concept into a polished global map.

The visual details are especially notable. Type-specific aircraft silhouettes and airline-colour rendering were implemented in this source in late 2010 — not as a retrospective mock-up, but as production code.

The Porsche that never arrived

When the FlightGlobal enquiry arrived, Daniel F. was working for INLINE as marketing manager. KjM had known him for many years as a friend and as a former employee of Jürgen H.'s company. Daniel called with a memorable prediction:

“Meyer, now we’re going to sell your project — and soon you’ll be driving a Porsche.”

At the first meeting in London, which KjM attended, the discussion quickly became more concrete. FlightGlobal wanted the application implemented in Flash. Daniel expected that a suitable developer could be found quickly through online freelancer marketplaces. The schedule, however, was hard: in KjM's recollection the delivery window was only about four weeks, with a contractual penalty of nearly €1,000 for every day of delay.

Ten days before the deadline, Daniel called again. This time the message was rather different: “Meyer, I can’t find anyone.”

KjM bought an enormous book on Flash programming and started learning the part he actually needed: ActionScript. The surviving ATLAS repository confirms that the resulting application was built as an ActionScript/Flex project. Two days before the next London visit, his version was finished. Two days later, FlightGlobal accepted it.

Technical note: the surviving source is a Flex/ActionScript application compiled to the Flash platform. The Flex SDK later became the Apache Flex project; the 2010 development itself predates the Apache handover.

The Porsche, incidentally, is still only a dream.

Before FlightShare2, winsend2 was already feeding ATLAS.

The newly recovered Windows CVS trees fill in an important missing step. winsend2 began as a contributor for SBS-1/BaseStation and RadarBox data, then grew into a much larger workstation with ACARS decoding, route tracking, reports, local databases and a realtime web server. Its CVS history on 16 October 2010 records a release specifically “to work with new collector and atlas”.

This was also a clear technology shift from the earlier ACARSClient. There was no Tcl/Tk GUI in winsend2: the recovered tree is a native Win32 C application, with WinMain, Windows callbacks, dialogs, list views and resource files. Paths embedded in the resources and the compatibility layer point directly to the MinGW32 development environment.

FlightGlobal later wanted something deliberately simpler: a feeder that did not expose the whole winsend2 toolbox. The result was FlightShare2. Its own interface identifies it as an “Atlas contribution tool” written by INLINE GmbH for FlightGlobal. It accepted SBS/BaseStation data on TCP 30003 and RadarBox input, maintained a compact per-aircraft state and sent normalised contacts to the central collector. FlightShare2 kept the same native direction: essentially C plus the Win32 API, again with a real Windows GUI instead of Tcl/Tk.

Evidence boundary: the winsend2/ATLAS and FlightShare2/FlightGlobal links are directly visible in the recovered CVS/source. KjM's recollection explains the product decision: FlightGlobal considered winsend2 too extensive and asked for a deliberately “dumb” feeder that simply delivered the data.

The project that ended another project

There is a bitter personal chapter behind ATLAS. In KjM's 2026 recollection, the agreement required development of ACARSd and related projects to cease if the commercial collaboration was not renewed. ACARSd had never been a business; it was an expensive hobby and a technical passion. When the collaboration ended, active development stopped.

The old Pentium 133 associated with the project was destroyed in anger. The servers at acarsd.org, however, continued operating for years and were only finally shut down around the introduction of GDPR in 2018.

Evidence boundary: ATLAS dates, FlightGlobal integration, aircraft icon logic and community SBS functionality are directly visible in the recovered CVS source. The contract clause, the P133 story and the GDPR shutdown are the author's 2026 recollections and are presented as such.