Currently, zoom level 16 is fully implemented.

At this time, tiles completely compiled and rendered at zoom level 16 are offered.

Every increase of a zoom level quadruples the time, the space, and the amount of images required for a complete latitude and longitude tile.

For example, the tile +51+007 (EDLW) requires 228 renders in total, to be able to construct a full tile.

Therefore, zoom level 17 would already require 912 images at the same resolution, whereas zoom level 18 would quadruple this number once more to 3648 renders - also at the same resolution.

The amount of final DDS images after the conversion in Ortho4XP is similar, and each DDS texture takes up approximately 10 MB of space.

Also, rendering a full tile at zoom level 16 takes about 90 minutes with multithreading and full CPU usage. Therefore, zoom level 17 would need 6 hours (360 minutes) and zoom level 18 would then take 24 hours.

As such, zoom level 16 is the best compromize in size, speed, and quality.

I have done experiments and tests on zoom level 17, but locally limited - for example it could be implemented for airport regions with a defined radius.

When the X-World (Pro) scenery package is added to the X-Plane flight simulator, building and many roads will be placed and overlayed exactly at their correct coordinates, thus completing the scenery. This also reduces the amount of data to be processed for every render.

However, with lower rendering distance, and possibly lesser world detail, less geometry is rendered, resulting in "empty" residential areas. For this reason I am working on a mechanism that can place buildings in the renders separately, thus enabling me to offer two versions of each tile - with and without buildings, and roads.

As soon as this becomes available, I am considering offering these tiles under the label Orthographic Pro.

No. The engine is developed entirely by me, with only the occasional cross-check of some technical implementations against an AI. This only affected smaller parts or mechanisms of the code to improve its efficiency.

The engine itself is free of generative AI. The resource pool is hand-curated and hand-made from photo-realistic source material from Bing and Google Maps. Some tags receive individual manipulation and post-processing effects, such as a border around farmland or shadows being cast by forest areas.

The engine itself and the accompanying tools are written in Python, and on a Fedora Linux system.

The long-term and large-scale idea of the project is to provide as many tiles as possible, for the entire globe. This is a very ambitious goal all things considered, but still - the set goal is to provide tiles for many countries and continents. Once Germany completes with its coverage, I will move on to more countries in Europe, and by the same token, implement the mechanic to employ different resource pools for different parts of the world.

For example, at this time the resource pool used for Germany is more tailored to central and western Europe. When I move on to the USA for example, a different resource pool for the tags will be required. At that point I will proceed to generate a separate resource pool for North America. The mechanism in Orthographic will then be able to utilize the correct pool automatically.

In other words, other countries and continents are the long-term goal.

Correct. The render engine runs locally, and only utilizes the texture pool that is provided. Some tags get a number of render tricks applied, for example farmlands or meadows. The engine renders the image in a defined order of OSM layers.

There is an additional number of manual steps required before the mesh can be generated. Once these are completed, I am using the popular Ortho4XP tool (shred86 fork) to generate the final mesh. I am using Sonny's LiDAR scans, in 3" resolution. I might consider offering tiles with a higher terrain resolution at some point.

With my main machine, it currently takes about 90 minutes to render a complete tile - plus the preparation to bring the OSM data into my format, compiling the tile, and uploading it to my server, I arrive between 2 and 2.5 hours. The largest chunk of this time is the render itself, and the exact time required depends on the amount of data in the entire tile. Some city-rich areas take longer, as they feature a lot of smaller residential areas, whereas rural areas often feature larger farmland or forest areas, which results in lesser data that needs to be processed.

Indeed. Before I have made this project public, I have been in contact with Austin Meyer and Ben Supnik.

Digital clone use cases are possible and highly encouraged. Contact me directly with the email link in the footer to discuss the deployment and licensing for these use-cases.

While I am using the Mercator coordinate system, numbering system and projection, it is effectively using the same mathematical formulas that are used for map services like Google or Bing Maps. However, with MSFS 2024, the imagery is streamed directly from Microsoft's Azure servers. Not only would it require a man-in-the-middle proxy to "fake" an Azure server and to redirect MSFS's requests to that server, it would also need the renders on higher zoom levels readily available on that fake server. As outlined earlier, I only offer zoom level 16, and implementing a "redirect" to zoom level 16 when zoom level 18 is requested, would be a very involved technical process for which I currently do not have the time or the resources.