X-Plane 12.1.1 has been released!

Well now, it didn't take long for Laminar to push out the latest build-level update after their initial minor-level update of X-Plane 12 lineup.

Somewhat surprisingly, it looks like no new gateway sceneries were included in this update. While this is indeed surprising (since I don't really remember if there have been any releases in the past that didn't include any new updates from gateway - but I could be wrong; my memory isn't what it used to be) it isn't exactly alarming ... X-Plane 12.1.1 release notes does state that this is a minor release to address bug fixes in the sim's core functionality. Going through the extra steps of including updated scenery could entail further testing and might have delayed the release.

Also, it looks like our data is consistent with what can be seen on the Gateway site, so I'm fairly confident that this has indeed been intentional.

What's up with the airport marker rendering?

I've been getting some questions regarding the airport markers rendering. When you zoom in and out on the map interface, it may sometimes take multiple seconds for the markers to re-render properly. This is a known issue on the map interface site.

Let's take a short walk through the memory lane...

Originally

When the Gateway Map interface was originally created over a decade ago during the early 2010s, we didn't actually use any map overlay rendering. Instead, all markers matching end-user's search criteria were individually placed using Google Maps API. This approach works when there are - at most - a couple of hundred markers to be drawn and ... during the early days of Scenery Gateway, this was the case.

The problem with this approach is that as the number of markers goes up, the amount of data being transmitted from server to client increases with every new marker as well as the memory requirements of the client (browser) displaying the map.

WedBOT enters the Arena

One day, rather early on the history of Gateway, Laminar decided to include all airports in the Gateway (with "WedBOT" as the author of such "non-improved airports") - not only the modified ones. This made sense, because now they could more easily accommodate the increasing number of scenery developers participating in the Gateway. For us this was absolutely disastrous. With tens of thousands of airports to display on the map, our site - the Gateway Map interface - slowed to a crawl. Laminar show only 10 results at a time, but we ... had a bit of a problem; you can't realistically paginate a free-scrolling map :)

At the time, we decided to take the approach Google suggested for users of their Google Maps -service; server-side rendering of markers and displaying them as overlays on individual map tiles. They even offered rather easy way for us to achieve this; Google Fusion Layers could fetch data from Google Fusion Tables we could query as if they were database tables and render the results as map overlays. This was blazingly fast, it worked and achieved exactly what we wanted.

Of course, all good things come to and end and ... Google Fusion Tables SaaS was discontinued back in 2019 and we were back to square one. Google had other optional sources we could have used to fetch data from aside from Fusion Tables - but most (if not all, can't remember) were way too expensive for our needs; a non-profit actor such as ourselves doesn't really have the means to pay for things like that.

Current state

We decided to implement our own server-side rendering of the map overlays. Of course, we needed somewhat more optimized way to get the data for each and all queries our users were throwing our way from our database, because our original database was not designed for this. The thing is ... even with an optimized data storage, our server was simply not fast enough to render the markers on the tile overlays fast enough.

These days we actually do the overlay rendering asynchronously on a separate process. The client asks for an overlay tile and needs to wait until a number of other tiles have been rendered until it receives the final result. Obviously, we do have rigorous cacheing implemented so we don't need to keep rendering same things over and over again ... but like every developer knows there are only two difficult things in programming; naming things, cache invalidation, off-by-one -errors ... and handling asynchronous responses. :)

So...?

To answer the original question "What's up with the airport marker rendering?" ... we are doing our best. Sometimes our best just isn't enough - the response times for overlay marker rendering layer is hugely dependent on our server load at any given time. It might be nearly instant, it might take a couple of seconds ... it might take (relatively thinking) forever if you happen to reach the site while we're under DDoS -attack ... but we are trying our best.