As a result, each time we increase the zoom level by one whole number, we require four times as many tiles to represent the entire world. Meanwhile, every tile image is always a constant pixel size, so by extension, a single tile also covers only ¼ the geographical area of the next-lower zoom level. The consequence of this is that given any viewport size, increasing the zoom by one means we decrease the geographical area depicted in that viewport by a factor of four. That is, if a distance of one mile took up ten pixels on screen, at the next zoom level it would take up twenty. Each time we increase the zoom level by a whole number, we double the scale of the map. There is, however, a pertinent consequence of this three-dimensional system: the number of possible XYZ combinations grows at an astonishing rate. When a user zooms in closely on an area, we want to show lots of detail-minor roads, airport runways, etc.-but if that same user zooms out to look at the entire US, then depicting every minor road and runway at that level would seriously clutter the map!
![non uniform grid mapping non uniform grid mapping](https://www.mathworks.com/help/examples/matlab/win64/InterpolateScatteredDataOveraUniformGridExample_01.png)
The third zoom dimension is important, as it allows us to tailor what’s depicted on a tile to the current zoom level. This, in turn, saves unnecessary work and data transport-that is, loading imagery that the user cannot view.įor most cases where we use tiles on FlightAware maps, we use a three-dimensional coordinate system, which identifies tiles based on their geographical location (X/Y coordinates, corresponding to longitude and latitude) and their zoom level (a Z “coordinate”). By doing this, when a user is looking at a small subset of the globe, we can load only the tiles needed for what’s visible in the map viewport.
![non uniform grid mapping non uniform grid mapping](https://media.springernature.com/lw685/springer-static/image/art%3A10.1038%2Fs41467-020-17500-1/MediaObjects/41467_2020_17500_Fig8_HTML.png)
While we certainly have the ability to render all the content as a single large image, in practice we break this up into individual smaller images. Let’s use FlightAware’s classic blue base layer as an example. When we talk about “tiles,” what we’re really talking about is breaking up data or imagery for a map into small, bite-sized chunks. Particularly pertinent to this discussion is how maps use tiles to provide a solid user experience. Web-based map products are ubiquitous these days thanks to tools like Google Maps, and with their popularity has come plenty of standardization in how maps work. Each of these steps needs to work promptly and efficiently-after all, even the most compelling map depiction will lose some of its impact if users must wait 10+ seconds for the depiction to actually load! Web maps and tilingīefore we get into the meat of these challenges, we’ll briefly discuss some mapping concepts. Making this map function presents significant challenges-there can be upwards of 10,000 aircraft en route at any given time, and that’s a lot of data to fetch, process, transport to the client browser, and render. Perhaps the most visible application, however, is the FlightAware live map-a product that attempts to depict all en route aircraft around the world.
#NON UNIFORM GRID MAPPING SOFTWARE#
Philip Clifton is a Senior Software Engineer 2 and Team Lead, responsible for guiding the overall implementation of Web technologies at FlightAware.įor many users of FlightAware, one of the most visible and visual experiences on the website are the maps, depicting flight data in various forms-individual flights, traffic to/from airports, and airline fleets.