What is Map Scale That Thou Art Mindful of It?

[Martin_Goliath]

As some of you may have noticed, I am working on some tools useful for generating hex grids. This made me think a bit on what is actually meant by map scale when dealing with a map consisting of hexagons.

To illustrate what I am getting at, see the attached image taken from EA. Now, in my board-game mind the distance between two hexes is given by taking the shortest path between the hexes. Hence, the distance between Saarbrücken and Mainz is four hexes, as is the distance between Saarbrücken and Koblenz. If the hex size is defined by the green line indicated in the pic, the geometrical distance to Koblenz is indeed four hex sizes. However, the geometrical distance to Mainz is only 3.46 hex sizes. The two examples are the extremes, and taking the distance between randomly chosen hexes, the distance per hex is found to be 0.93 hex sizes, with a 7% spread around that value.

So: what is the map scale? Is it the hex size, is it 0.93 times the hex size, or something else? Maybe this is a non-issue, or you experienced scenario designers out there have ways to take this into account?

As another example, I took some 20 locations from the map of EA, read off the TOAW map coordinates, looked up the corresponding long/lat coordinates elsewhere, and calculated distances both in hexes and in kilometers. The mean distance per hex turned out to be 31.45 +- 1.81 km/hex. Note that the spread is nearly 7%, in line with the above discussion.

[noxious]

As I've always understood it, the hex scale is not the size of a side, but the distance between two opposing sides going through that hexagon's center, aka that green line traversing the hexagon in the upper left of your picture.
Choosing hexagons is a way to give six movement possibilities without incurring the massive movement discrepancies brought on by the diagonals in a square based grid.
With squares, you only get 4, or 8, but then, the diagonals bring too much discrepancy unless you keep track of movement and distances on a sub-grid scale, as in keeping track of "scale units" travelled, which is easily possible with a computer doing the number crunching, but rather difficult with a boardgame without burdening the players unduly with extra bookeeping.
Don't know that TOAW tracks the exact distances or not.

Your example shows a case where hexagons fail to reproduce distances with any exactitude.
A square grid has other problems : it's your usual tradeoffs

[Curtis Lemay]

ORIGINAL: MarGol

As some of you may have noticed, I am working on some tools useful for generating hex grids. This made me think a bit on what is actually meant by map scale when dealing with a map consisting of hexagons.

To illustrate what I am getting at, see the attached image taken from EA. Now, in my board-game mind the distance between two hexes is given by taking the shortest path between the hexes. Hence, the distance between Saarbrücken and Mainz is four hexes, as is the distance between Saarbrücken and Koblenz. If the hex size is defined by the green line indicated in the pic, the geometrical distance to Koblenz is indeed four hex sizes. However, the geometrical distance to Mainz is only 3.46 hex sizes. The two examples are the extremes, and taking the distance between randomly chosen hexes, the distance per hex is found to be 0.93 hex sizes, with a 7% spread around that value.

So: what is the map scale? Is it the hex size, is it 0.93 times the hex size, or something else? Maybe this is a non-issue, or you experienced scenario designers out there have ways to take this into account?

As another example, I took some 20 locations from the map of EA, read off the TOAW map coordinates, looked up the corresponding long/lat coordinates elsewhere, and calculated distances both in hexes and in kilometers. The mean distance per hex turned out to be 31.45 +- 1.81 km/hex. Note that the spread is nearly 7%, in line with the above discussion.

You simply have to make a choice. Nothing will change the fact that the distance to Koblenz and Mainz is the same in hexes. You can only make one of the paths correct. My choice, with my Latlong program, was to make the east-west path correct, along with the north-south path. That means that the diagonal paths are off a bit. Methods that superimpose a hex grid over a digital map, may get the diagonals correct, instead.

[ColinWright]

ORIGINAL: Curtis Lemay



You simply have to make a choice. Nothing will change the fact that the distance to Koblenz and Mainz is the same in hexes. You can only make one of the paths correct. My choice, with my Latlong program, was to make the east-west path correct, along with the north-south path. That means that the diagonal paths are off a bit. Methods that superimpose a hex grid over a digital map, may get the diagonals correct, instead.

I've gone round on this with 'Curtis' before, and he has a good argument. His approach yields more accurate average distances between randomly selected hexes.

However, I retain a visceral fondness for a system that simply lays a grid over a valid map without altering the contours of that map. That said, the hex size would be the distance between any two opposite sides of any hex. Of course, this means that all travel along a horizontal line covers more than the straight line distance, as the trucks, tanks, foot soldiers, and artillery shells all are prevented from traveling in a straight line, and have to jig up and down. Mainz and Coblentz are not the same distance; it's just that the hex grid won't let you travel in a straight line to Mainz.

[Curtis Lemay]

ORIGINAL: ColinWright
Of course, this means that all travel along a horizontal line covers more than the straight line distance, as the trucks, tanks, foot soldiers, and artillery shells all are prevented from traveling in a straight line, and have to jig up and down. Mainz and Coblentz are not the same distance; it's just that the hex grid won't let you travel in a straight line to Mainz.

I'll just point out that this same argument could be used to rationalize the distortion imposed by a checkerboard as well: "Units and shells can only travel north-south and east-west." I prefer to simply accept that both impose a certain level of distortion - the hexgrid less than the checkerboard, of course, but distortion nevertheless.

[Martin_Goliath]

Thanks as always for valuable comments!

To give a concrete example, I can relate my attempts on a map for Colin's Orient scenario idea:

The grid subdivision we discussed earlier (see this link, post 10 - ...) is implemented, which gives more flexibility to the method I am working on. Colin's scenario idea is intended for a map from Tunisia to Iran @ 10 km/hex. One possibility I can produce now is 9.99 km/hex - at least that is what the DGGRID software I am using claims. Now, calculating the distances to neighbours for a sample of hexes on that map, I actually found the hex size to be 10.00 km with a 0.43 km spread. In other words the grid size is as claimed, but with a 5% spread (probably due to slight asymmetry) that averages out. On the other hand, if I calculate the distances - both in km and in hexes - between some key places on the map, I find that the distance per hex is 9.16 km/hex with a 0.62 km/hex spread. The lower value here is to be expected, as discussed previously in this thread.

Another possibility that happens to be available is to generate a grid with 10.53 km hex size. Calculating distances as for the previous case, the hex size 10.52 +-0.39 km is found, whereas the distances between key places give a distance per hex of 9.65 +-0.56 km/hex. In other words, the hex size is slightly above the desired one, but the distance per hex is slightly below.

So, which choice (if any) would you prefer?

For those interested in more details on the distance calculations, I have attached the full output from my distance calculation tool for the two cases.

[ColinWright]

ORIGINAL: MarGol

Thanks as always for valuable comments!

To give a concrete example, I can relate my attempts on a map for Colin's Orient scenario idea:

The grid subdivision we discussed earlier (see this link, post 10 - ...) is implemented, which gives more flexibility to the method I am working on. Colin's scenario idea is intended for a map from Tunisia to Iran @ 10 km/hex. One possibility I can produce now is 9.99 km/hex - at least that is what the DGGRID software I am using claims. Now, calculating the distances to neighbours for a sample of hexes on that map, I actually found the hex size to be 10.00 km with a 0.43 km spread. In other words the grid size is as claimed, but with a 5% spread (probably due to slight asymmetry) that averages out. On the other hand, if I calculate the distances - both in km and in hexes - between some key places on the map, I find that the distance per hex is 9.16 km/hex with a 0.62 km/hex spread. The lower value here is to be expected, as discussed previously in this thread.

Another possibility that happens to be available is to generate a grid with 10.53 km hex size. Calculating distances as for the previous case, the hex size 10.52 +-0.39 km is found, whereas the distances between key places give a distance per hex of 9.65 +-0.56 km/hex. In other words, the hex size is slightly above the desired one, but the distance per hex is slightly below.

So, which choice (if any) would you prefer?

For those interested in more details on the distance calculations, I have attached the full output from my distance calculation tool for the two cases.

Are you counting along straight rows of hexes? If you pick points that don't lie along straight rows of hexes, the results you obtain are simply going to reflect the extent to which the hex grid is forcing you to deviate from a straight line.

That said, I would be inclined to prefer the grid that claims to be at least nominally 9.99 km per hex.

[Martin_Goliath]

ORIGINAL: ColinWright
Are you counting along straight rows of hexes? If you pick points that don't lie along straight rows of hexes, the results you obtain are simply going to reflect the extent to which the hex grid is forcing you to deviate from a straight line.

For the km-distances, I use one of the applications of the GMT software package. It seems to be accurate - some distances that I double-checked did not lead me to think otherwise at least.

The metod for finding the number of hexes between any two hexes is home cooked. It takes even/odd column differences into account, and has always given the correct number when I have double-checked.

ORIGINAL: ColinWright
That said, I would be inclined to prefer the grid that claims to be at least nominally 9.99 km per hex.

Unfortunately, I have not - as yet - found a grid orientation that accomodates both Bizerte and Bushehr within the 300 x 300 limit for the 9.99 km/hex case. If I shave off the map so that these key places are at edges, the closest so far is 308 x 289...

[ColinWright]

ORIGINAL: MarGol

Unfortunately, I have not - as yet - found a grid orientation that accomodates both Bizerte and Bushehr within the 300 x 300 limit for the 9.99 km/hex case. If I shave off the map so that these key places are at edges, the closest so far is 308 x 289...

That is definitely getting there. Can you post or e-mail me with whatever you might have? wrightmoving@sbcglobal.net

Dunno where I will go. Might adopt Bob/Curtis' reasoning about scale, which would have the virtue of getting it all on the map and giving me a little play-room around each point.

[Martin_Goliath]

ORIGINAL: ColinWright
That is definitely getting there. Can you post or e-mail me with whatever you might have? wrightmoving@sbcglobal.net

Colin, you will have mail in a moment!

I prepared a zipped map XML file only to find that it just exceeded the 250 kB limit for attachments (I am still impressed by the art of file compression: 10MB became 270 kB!)

This attempt on the Orient map @ 10 km/hex includes both Bizerte and Bushehr within 300 x 300, but the caveat is that part of the Tunisian coast is truncated so that northern Tunisia is separated from Africa (I would need some 15 additional rows...). Anyway, it gives you some idea of how the map may look. By the way, this is the "raw" output from my map making tool - for instance, the jagged map fringes is a result of the hex subdivision being applied twice.

As I blew the file size limit anyway, I have added the input files used for producing this map, as well as some other output from the tools I use:

Orient-10km.pl : main input file
Orient-places.inp : input file with locations to be added to map
map.mml : the map XML output
distances.dat : the calculated distance output
gridplot.ps : PostScript output showing the grid drawn on a map

[Martin_Goliath]

Another issue related to distances, and that might or might not be of importance:

When distances become large, the fact that the shortest line between two points is a great circle becomes noticable. This can be seen in the attached pic (sorry for the poor quality - I had to lower the resolution), where the lines connecting Bushehr with other places are curved. If your grid uses hex rows aligned for example along lines of constant latitude, the closest route on the grid will in general not coincide with the closest route on the globe. On the other hand, if you taylor the grid to a particular great circle, I belive any other great circle will be modelled just as poorly.

In practice, this might be a non-issue: whether your long-range bombers fly the correct shortest path or not probably matters little...

[ColinWright]

ORIGINAL: MarGol

ORIGINAL: ColinWright
That is definitely getting there. Can you post or e-mail me with whatever you might have? wrightmoving@sbcglobal.net

Colin, you will have mail in a moment!

Thanks. It may need to be allowed to age for a bit: in my life, non-cyber reality is rearing its hideous head with particular vehemence these days.