With the introduction done it’s time to dive deeper into the boring technical bits. I’m sorry for those of you who are not at all interested in things like file formats, bit depth and such nonsense this one might not be for you, but for the rest of us map nerds lets dig into things!
When I launched my first attempt to map Greyhawk Internet was still in its early days, print was the norm and JPEG was just invented. At first, I just stumbled along and tried to make it look OK, but after a while I realized it would take years, many years, to finish so setting up a workflow that could work long term was crucial. Now when I’m starting over again, I’m keenly aware of the fact that this project will probably take the rest of my active days, so a proper plan is key to making it possible, and the result usable. The key bit in this project is that it leaves a robust set of cartography material for Greyhawk fans to use and build upon for the future long term.
The result will consist of digital data in various forms, images, heightmaps, masks, vectors, text and database files and more. My first priority is to try and use open files formats whenever possible, so files can be opened and edited even after the tools I’m using now will no longer be available.
Terrain starts with heightmaps, the greyscale image that provides elevation data. The resolution I’ve settled on is 5ft per pixel, as a D&D nerd I couldn’t resist that homage to the game. It is also a useful compromise between large- and small-scale maps. Detailed enough to show individual buildings, trees and the like, but still possible to cover large areas like a whole continent. The Flanaess will be around 22 million pixels across at this resolution.
World Machine and my hardware limit me to work on an area of 65,536 x 65,536 pixels (64K) which cover an area of 3,844 square miles at 5ft per pixel. Currently I have created a dozen of these areas, which are nearly 50,000 square miles and several more is in the making. So good progress at this stage.
The heigh data needs to be stored in a format that is accurate enough, which dictates the bit depth needed. If the goal would be a Minecraft terrain 8bit data would be enough, but Greyhawk the way I want to present it need more than the blocky terrain of Minecraft. The Bit Depth sets the limits for how much data each pixel can contain, a 1-bit file can have a value of 0 or 1. Minecraft terrain probably requires 16-bits with covers 65,536 height values. My aim is to cover a height from seal level to 12.5 kilometers which is a bit over 41,000 feet, which ought to be enough height for impressive mountains.
41,000 feet is over 400,000 inches so only having 65,536 height values might mean a bit of that jagged stair effect when looking closely. I’m not taking any chances and will store the heigh data using 32-bits which gives me 4,294,967,295 height levels to play with which is enough even for closeups. The file format I’ve chosen to use is OpenEXR, which was created by Industrial Light & Magic Studios to store all sorts of complex image data, and it supports 32-bit data.
When working with digital terrain creation, a way to select only areas that have a certain, elevation, slope, direction facing or other feature, or to manually place things like trees, roads or buildings. For this, masks are needed and they are greyscale images like heightmaps, white for total presence and black for total absence, and degrees of grey for everything in between. Bit depths range from 8-bit to 32-bit in rare cases. For 8- and 16-bits PNG is my format of choice. PNG is technically supporting up to 32-bits but that seems to be iffy, so I stick with EXR here as well for the few masks where I need lots of precision. Like Erosion masks used when creating textures for example, when very gradual changes are needed.
Most masks are only useful when creating and editing heightmaps or textures, but some masks are useful for changing things like rods, building, trees and other things on the map, so I will make sure they are preserved. For this I will use PNG, EXR and layered TIFF files. Which are all standards that will be around for many decades or longer into the future.
Textures will be saved as JPG’s and/or TIFF’s, depending on how detailed they need to be and how much storage can be saved using compression. WepP and JPEX XL are newer formats I’m looking into as well might be the way forward if they become widely used standards. Both offer great features, and good compression.
Areas that are done and ready to be presented will be summed up as JPG’s, PDF’s, and TIFF’s. The data will also be available as GeoPackage which is a way to package GIS data as a single database containing all sorts of stuff from terrain images, vector data for things like roads and borders and symbols all in one bundle.
My goal is to set up a server to offer this in a browser or for use straight into GIS software like QGIS, like OpenStreetMap is today. Started to test that on my LAN and its promising. The next step when I have more data ready is to set up a Virtual Private Server with my web hosting company and install it there. I have a domain name and server capacity ready to go. This might have to be by invitation only, if it gets popular the bandwidth costs can shoot up. The content will be available to download as final maps or GeoPackage for free for everyone, so you can run a server on your machine at home or set up your own server with your own version if you want to.
I’m using my webserver and Notion to host and distribute content. In many ways I prefer Notion, it is searchable and easier to work with. I’m thinking of moving all the downloadable content to Notion and letting my website become more of a landing page, sending people to my Patreon for my blog, Notion for downloadable content, and in the future a map server for online maps.
I’m tempted to present the new maps as JPG’s or PDFs of a 24 x 36 inch sheets useful both digitally and printed. 24 x 36 is a standard format available almost everywhere you can get stuff printed and the cost is reasonable. The problem with 24x36 inches is that it is too big to print on most home printers, 13 x 19 inch might be better for home printing. 8,5 x 11 inches are the easiest for printing and storage, but very limiting when covering large areas. Test maps have to be made.
Below is a layout idea for 24 x 36 inch maps. Oerth globe map top left to get a base idea where on the planet this is. Large area map on the left with other maps in the series marked out as well. Below that room is for notes of the area, sources and links. Scale projection and other technical details below that and Credits and edition at the bottom left.
B
The main map area would be 24.5 x 24.5 inches and can be either top down or isometric, I’m going to make both versions. More on this is my next post, which will be a lot more interesting to look at.
This type of layout with mini-map and all the information might be useful for some series of maps, others might be most useful as full page maps with as little disturbing stuff on there as possible, so you can lay them side by side to present larger areas distraction free. I’m thinking that isometric maps might be really cool this way.
Maps that are primarily used to find things and to refer to them would benefit from overview maps, grids and scale information.
Next will be to present the map data I’m putting together, top down and isometric renders and some overview maps. Below are a couple of sneak peaks..
