Sunday, August 31, 2008

Map-making

At last, I find myself working on D&D. It’s been a very dry three weeks.

Oh, I’m not doing any hard core problem solving. I have to build up to that. No, for the time being, I’m quite happy to work on map-making…the long struggling effort to map the earth in 20-mile hexes. I thought the most useful thing I could do here would be to outline the process.

This has been honed considerably in the last few years, and as a measure of where I’ll be five years from now, I think it will be useful to look back at this and see where I was. So unless you’re of a cartographic frame of mind, prepare to be bored.

The first step begins with the accumulation of data from the link on my blog, http://www.fallingrain.com/. This lets me know the location of all the towns, cities and elevation points everywhere, including their latitude and longitude; elevation is of great importance to my maps. As far as I know, I’m the only person making a D&D map that includes them.

Presuming that the first hex of the world map has, as its center, the North Pole, the rest of the map is a series of concentric circles moving outwards; there are 310 and a half hexes between the Pole and the Equator, so that each concentric "ring" represents approximately 0.29 degrees of latitude (or 20 miles). Each ring has a designated number, so that "Ring 1" is the Pole and as one moves southward the ring numbers increase. Archangel is located on Ring 89; Moskva on Ring 118; Budapest on Ring 147 and so on. The only ring that does not have a number is the "Equator Ring," which I named for my own convenience. (The ring north of the equator is 310; the ring south of the equator is 311).

Each successive ring as one moves towards the equator has six more hexes than the previous ring. Thus, Ring 147 has 883 hexes; Ring 247 has 1,483 hexes; and the Equator Ring has 1,867 hexes.

Each hex ring is still 360 degrees in longitude, regardless of how many hexes it might include. In order to plot the position of each piece of data from fallingrain, I have to divide the various rings by the longitude in order to determine which ring accommodates which data. To put that another way:

Ring 155 is almost halfway between the pole and the equator. In latitude, it encompasses all points between 45.04 and 45.32 degrees N. In total it includes 931 hexes. I divide 360 by 931 and end up with a number equalling approximately 0.38 degrees of longitude per hex. Each of these 931 hexes are then listed on a BIG file I have on Excel, as is every ring. Thus, when I want to locate a particular settlement, such as the city of Brod in Slavonia (latitude 45.16 N; longitude 18.02 E), I find the corresponding hex and locate the city.

Now, if you can picture the circular hex map that is the northern hemisphere, then you know there are going to be six points on each ring where the map "shifts 60 degrees"…a hex is not a circle, and thus pressing a circle into a hex shape causes some distortion. This is a problem working with a sphere on a flat surface. I don’t worry very much about the distortion, since the travellers "on the ground" don’t recognize it when it occurs—although I will admit it is sometimes a bitch to draw coastlines so that they are both properly distorted AND accurate. Oh well.

I literally have tens of thousands of pieces of data regarding elevations, and these are sorted into their appropriate hexes. What generally happens is that each hex has a "maximum" elevation and a "minimum" elevation…often with dozens of points in between, which are catalogued but which don’t interest me much. The benefit of having the minimum elevation for each hex is that I can trace the general course of the rivers (this is not always so, a canyon will often need to be considered and the river directed correctly), particularly streams I do not have a map for because, well, most atlases concentrate on Europe and America and not much else. Expedia.com is a godsend for this sort of thing; it helps get the rivers in the right place.

I section the planet into squares that are 30 hexes by 35; this is a convenient map size for me to work on, making each file approximately 2-5 megabytes in size and not overwhelming the computer’s ram while I work on the map. Ultimately, I suppose I could eventually have a large enough computer that I would need only two maps, the north hemisphere and the south, but I’m not there at the moment.

So much for background stuff. Now I have the template. I make a small note on each hex denoting its elevation. The next step is to place the cities.

Which cities I "use" is determined by those recorded in the 1952 Collier’s Encyclopedia I’ve mentioned before. Virtually no list of cities you could choose to use would be complete; no atlas or encyclopedia gives a complete listing for every settlement worldwide, along with its population, so at some point one has to say, "I’ll use this list" and have done with it. The list from the encyclopedia is extensive; typically a region such as Germany will have about 300 settlements listed.

I research each city on the list through wikipedia (I used to use other, printed sources, but wikipedia is fucking brilliant) in order to determine if a) it was founded before 1650, eliminating any cities listed as being modern; b) who was in possession of the city in 1650, to establish my borders; c) what its name was in 1650; and d) how often the city has been razed, pillaged, burnt to the ground, destroyed by an earthquake and so on.

The older the city, the larger the percentage of its population as listed by the encyclopedia I include. Thus, if a city has a population listed as 10,000 and was founded in 1636, that will be a small village (100 people); if, on the other hand, the city was founded in 1200 BCE, that city’s population will be quite substantial (6,000). I have a system that takes into account the number of times the city was destroyed by invaders, fires and disasters, along with its age, that gives me its size.

This does not always correspond to actual earth estimates in 1650. Fuck it. It’s more important to me to have a consistent system than to rely on inconsistent data from 400 years ago.

It is fiddling, annoying work to place the cities just so on the map, and in which corner of the hex in question, but I’m crazy so I do it. Having the location of the cities enables me to take traces of coastlines from Expedia and distort them into shape, and to determine the correct courses of the rivers. These I then draw onto the map. Now and then, these too are not exactly as the earth, but it is my world and I’m not willing to spend the rest of my life making the rivers just so. Close enough is close enough.

Wherever a river passes through a hex, I use the minimum elevation to designate that hex. Hexes without rivers are designated by the maximum elevation. This enables me to get a better sense of the level of the land and helps determine the location of roads (which avoid higher elevations).

For marketing purposes (my trade table), I measure distances between cities by the number of hexes. An elevation change of 400 feet is equal to +1 additional hex to the distance. Thus, if a road were to climb 3200 feet to ascend a pass, which would be 8 additional hexes added onto the travel distance. Descending an elevation is precisely the same; it may seem easy to walk down hill, but moving a loaded wagon downhill is just as difficult as dragging it uphill. Thus, if the other side of the pass were just as much of a drop, moving the two linear hexes over the pass would be the equivalent of 18 hexes distant.

Such considerations help define the network of roads I have in my world. Since water hexes are equivalent to 1/3 of a land hex, it becomes quite clear how sea travel is more practical—and also in which parts of the world it is not. For example, which is shorter: the overland distance between the Persian Gulf to Palestine, or the distance completely around the Arabian Peninsula?

Well, I don’t know yet, as that is the section of the world that I’m mapping at the moment. History tells us the overland route was shorter. I have little doubt, as I discover just how fucking big Arabia is in 20-mile hexes, that this will be the case.

Using this system to tell me where the roads ought to be has been an awakening. I have been peering habitually at maps since I was seven years old, as I have always loved them. Yet it has only been in the last five years that I have deeply comprehended the three dimensional nature of regions such as Russia, Eastern Europe, Turkestan and Western Siberia. Making maps this way is very much like doing it by Braille; I have such a sense for the physical, as well as the cultural aspects (I do a lot of reading on wikipedia), that it is like actually travelling. Sometimes I get so deep into the place that I have to physically jerk my mind back into my own temporal space when I rise from my computer.

It’s very fulfilling.

P.S. I hope to be loading some maps onto the blog soon, so you can get a look at what this looks like. I am waiting on an updated copy of the program that will let me do that, as the present "convert to jpeg" format in my present program apparently has a bug.

9 comments:

  1. You're a mad man.

    I scored a 1960's (1964 I think) University of Chicago edition Encyclopedia Britannica 20-volume set with index and atlus about a week ago. I went to a book sale at a local art museum and it was on a table with a sticker that said, "Free." I thought of you the moment I spotted it.

    ReplyDelete
  2. I've been admiring your maps on the wiki, but I'm having trouble figuring out the projection you're using.

    As I understand your description here, you start with one hex centered at the North Pole, with vertices at Greenwich, 60E/W, 120E/W, and 180; this is "Ring 1". This is surrounded by the six hexes of "Ring 2", whose centers are 20 miles south of the Pole; the twelve hexes of "Ring 3", whose centers are twenty miles further south; and so on.

    My problem is that I keep coming out one hex off when I try to apply this. For instance, I tried to figure out the hex of Franz Josef Land on your Jotunheim map. According to Google Earth, the northernmost point you have drawn is at about 81.2 degrees; about 8.8 degrees or 30.3 hexes south of the Pole. On your map, this point is just south of Ring 30. But thirty and a bit hexes south of the Pole should be just south of Ring 31, right?

    Forgive me if I've utterly misunderstood how you're computing your hex latitudes. In particular, this post is two and a half years old, so it's quite possible you've changed what you're doing since then.

    ReplyDelete
  3. No Gilgamec, you have it spot on. What's more, you've run into the same problem I first ran into when I first did this ... which is very funny.

    My solution was to take the 360 degrees around each ring and divide it by the number of rings. Thus, the circumference distance at each planetary ring is 20 miles x the number of hexes ... but to be honest, I don't calculate the rings according to distances, but according to the latitudes and the meridians.

    The distance of 1 degree is 69 standard miles, and therefore one 20-mile hex is 0.289134 degrees. I built an excel table that set the centers of each ring that many degrees apart. It's much easier to calculate in degrees than miles.

    As such, the hexes of the first ring (after the polar ring) are each 60 degrees in longitude wide. The hexes of the next ring are 30 degrees wide, and so on. There are (not dead certain about this) 1860 hexes in the equatorial ring.

    Hope this helps.

    ReplyDelete
  4. Right, I think I understand better. Thanks! I'll see how I get on.

    I think you're one off in your numbering, though. This can be best seen on the Jotunheim map. On ring 30, there are 30 hex widths between the 30 and 90 degree meridians (29 widths on ring 29, etc.). But if ring 1 is the north pole hex, then ring 2 should have one hex width between the meridians (ring 3 has 2 hex widths, etc.), and ring 30 should have 29 hex widths between the meridians.

    ReplyDelete
  5. Possibly. If I made the mistake, I made it a long time ago; and I've perpetrated it throughout the system, so it's been consistent. I can live with that.

    On the other hand, if I went back through my calculations, I might find support for my position. But what good would that do either of us, really? None at all. It works for me if you've got it accurate enough to suit your comfort level. I'm pleased that you're following a pathway similar to my own.

    ReplyDelete
  6. I am having a hard time understanding the jump from ring 1 having 1 hex and ring 2 having 7. That does not seem possible, or am I missing something?

    ReplyDelete
  7. Keltoi,

    gilgamec was figuring out the circumference of a circle that's a radius of 20 miles around the pole, or a 40 mile diameter, which multiplied by pi = 125.68 miles ... which at 20 miles a hex works out to 6.284 hexes; not really 7, but sort of.

    At least, that's how I interpreted it. My second ring has 6 hexes.

    ReplyDelete
  8. I would love to hear more about your workflow for getting elevations from Fallingrain onto your maps. Do you go through all the alphabetical sub-entries for a given area and plot each entry onto your map? Or do you know the lat and lon range of each hex, so you can just assign each entry to hex without mapping it? I am considering copying all points from a given area into a spreadsheet and trying to sort them by latitude so I can narrow my geographical range a bit for initial mapping efforts (the Shenandoah River valley in Virginia, USA).

    ReplyDelete
  9. Ah, closer reading has answered at least part of my question. I see that you know the latitude and longitude range of each hex, so you can know within which hex each elevation entry lies. If you have anything else to say on efficiently incorporating the data, I would be interested in hearing it.

    ReplyDelete

If you wish to leave a comment on this blog, contact alexiss1@telus.net with a direct message. Comments, agreed upon by reader and author, are published every Saturday.

Note: Only a member of this blog may post a comment.