Power Toolkit problem in map making

[TDR]

I decided to redo an old map of mine. So I followed the tutorial that drunkrussion posted on this site. I also used the ATF tutorial for making maps.

After I have filled in the Map Production Information dialog in the ATF Power toolkit and press the OK button I get the big gray scale map, preview map, and the correct green rectangle box.
On the Preview Map dialog when I press OK I get a dialog that says “Seek Failed on unnamed file”

Now I only get this “Seek Failed on unnamed file” message when the ALPHA value in the 'Map Production Information' dialog is negative. With the map I am working on the angle True North to Grid North is anti clockwise. Hence it is negative.

This happens with both the ATF and TSATC Power tool Kits.

Is there some way around this little problem?
Everything works Ok so long as the ALPHA value is equal to or greater than zero.

 

[Pat Proctor]

Is the ATF map you are trying to make near the left edge of the map data? It sounds like the top left corner of your square is off of the left edge of the map data.

Try regenerating the source map data (the USGS DEM) with the left edge of the map about 15 minutes further to the west.

 

[TDR]

Thanks, I had been thinking along this line but was not sure.

 

[TDR]

That cleaned up the problem.

Also with maps is there a logical process to take a graphic of a map on a 1:1 ratio to shrink it to fit a generated map in the ATF/AATF series of games?
Or is all a trial and error?
Maps have a “stretch” relationship of meters /second for the horizontal is there some similar relation for the vertical distance?
I have a graphic of the map area and want to utilise this if possible.

 

[Pat Proctor]

Ideally, you have taken the bottom left coordinates for the UTM grid from the convergence of a UTM and lat-long grid on your paper map. If you haven't, it is really hard to line them up.

In latitude, there are always 30.84 meters per arcsecond.

 

[TDR]

Thanks for that. It explains some things I am seeing.

One thing I don’t follow is the interpretation of the UTM values that come out on the generated map. As a couple of examples:

Easting and Northing taken on the bottom left corner of the map, same location as the Lat and Long values.
Test 1
X __ Easting off paper map ___ 3356 __ 4digit UTM
Y __ Northing off paper map ___ 4592 __ 4digit UTM
X __ Resulting Easting on TSATC map ____ 3360 __ 4digit UTM
Y __ Resulting Northing on TSATC map ____ 4605 __ 4digit UTM

Test 2
X __ Easting off paper map (rounded) __ 3350 __ 4digit UTM
Y __ Northing off paper map (rounded) __ 4590 __ 4digit UTM
X __ Easting on TSATC map __ 3360 __ 4digit UTM
Y __ Northing on TSATC map __ 4603 __ 4digit UTM

All other values were kept the same between the two tests.

This rounding up makes it a bit difficult to line up a graphic of the paper map to the game set of grid values.

Out of interest was this resolved with AATF?

 

[TDR]

Just trying to work out the map issues as I have a 24K by 49K map that has been scanned and I want to run it in AATF, well that is when the postal service gets it to me. Also the map is too fiddly with terrain to try to draw it in the colour and contour maps that are generated hence need to include the scanned graphic as accurately as possible.

 

[Pat Proctor]

This rounding up makes it a bit difficult to line up a graphic of the paper map to the game set of grid values.

Out of interest was this resolved with AATF?

If I think I understand what you are seeing, which is that the contour lines are a bit off from the paper map, the answer is no. Unfortunately, there is not a good solution that will preserve the integrity of the elevation data. It has to do with the resolution of the USGS DEM data and the ability to approximate a 3 arc-second resolution matrix to a 100m resolution matrix. The paper map is made with much higher resolution elevation data. You are going to get some deviation between the paper map and the ATF map.

 

[Pat Proctor]

Reading your question again, you actually ENTER the X and Y values for the bottom left corner of the map. Are you saying that they change after the map is produced by the power toolkit?

 

[TDR]

Reading your question again, you actually ENTER the X and Y values for the bottom left corner of the map. Are you saying that they change after the map is produced by the power toolkit?

That is what was saying. If you look at the test results I posted above this shows what happens.
In fact to get the correct engine grid coordinates I have to enter vales that are actually off the map.

The correct coordinates for the bottom left corner are:
X (easting) 3356
Y (northing) 4592

BUT to get this to come out correctly I have to actually enter the following XY values which are actually off the map:
X (easting) 3348
Y (northing) 4582
These above values give me an in game map grid set of values close to the correct values as derived from the paper map, ie X value in the range of 3354to 3358, similar with the the Y value.

I can not round the XY values like 3350 or 4590 as these still give the wrong end grid result.
I just wondered if this has soemthing to do with the negative alpha value?
Also the m/s value is rounded, though I am using a value of 26 it is actually closer to 25.97

 

[Pat Proctor]

I've honestly never seen this behavior before, though I must admit I never really check it, either. I would ultimately say that the test is whether the terrain features line up correctly (approximately) with the contour map you are using. If so, I would use the correct UTM grid for the give lat long of the bottom left of the map, and then just clip your map image to match the UTM corrdinates that the Power Toolkit produces. The differences you are observing are in the range of 50 to 140 meters. I don't think you are going to miss this space on a 20-40km map.

 

[TDR]

I've honestly never seen this behavior before, though I must admit I never really check it, either. I would ultimately say that the test is whether the terrain features line up correctly (approximately) with the contour map you are using. If so, I would use the correct UTM grid for the give lat long of the bottom left of the map, and then just clip your map image to match the UTM corrdinates that the Power Toolkit produces. The differences you are observing are in the range of 50 to 140 meters. I don't think you are going to miss this space on a 20-40km map.

Actually I can not remember seeing this before on a few maps I had been working on in the past. I can not go back an check as I lost a lot of work earlier this year. I am starting from scratch again. New install and all the basic agro.

In relation to the UTM grid and terrain:

The attached is a screen shot of the test map I am working with.
The terrain elevations generated by the underlying DEM map out relatively well on to the topo map, scale 1:50,000.

The dark contour lines are from the created contour map by the Power Tool kit. The topo map grid lines area bit faint.
The Eastings of both maps match well enough considering, but the Northings are all out by the same amount about 15-17 m. I am not sure if this is some thing to do with a slight variance in the BMP file, about 1 pixel difference in size between the original contour BMP and the combined BMP, the combined BMP is 1 pixel shorter than the original contour BMP.

One odd thing that occurred when doing the “New DX” build part the resulting tiles sets fro the colour and the contour map did not match and were very odd in size.
EG:
Colour map
Tile width 235
Tile height 2
No Tiles 3455

Contour map
Tile width 590
Tile height 1
No Tiles 2762

This may be due to the two original BMPs not being the same exact size, ie Width x Height; though I am guessing here. This is not a big issue but I have had several maps develop with widths of 1 - 2 pixels when tiled so i just wondered if thsi was an oddity.

 

[Pat Proctor]

When you do the DX convert on the scan of the paper map, it MUST be clipped to exact same dimensions (pixel height and width) as the export bitmap generated by the Power Toolkit FIRST. This could be the problem.

 

[TDR]

When you do the DX convert on the scan of the paper map, it MUST be clipped to exact same dimensions (pixel height and width) as the export bitmap generated by the Power Toolkit FIRST. This could be the problem.

In the above example it had not been clipped correctly. I have redone it and both the colour and contour maps now have the same tile structure.

I am still getting a level of abnormality with the 2 sets of grids, teh game generated one and the scanned map. This may be caused when shrinking the scanned map down to the game grid. At present the bottom of the map seems to be ok and the difference between the grids eastings and northings is at worst 20m. Near the top the eastings difference is still about 20 m at worst but the northings are closer to a 200m difference.

In the power tool kit generation I am using a magnification of 1 as the original map is a 1:50000 scale. this should give me about a 50 pixel sided grid. Its a bit vague on the scanned map on the pixel size of a grid is, some where about 160 pixels +/- 3 pixels.

At present I am trying to sort out these little bits before dealing with the 24 x 49 Km map.

I will do a few more test and post the results for comment/hint for correction.

 

[TDR]

One other small question:
In the Map production Information Dialog the m/s value, how accurate should this be?

With the map I am working with I calculate that the value should be 25.97m/s. In the work so far I have rounded this to 26m/s. Though it is not a big variance how significant is this in terms of stretching. The width is 2345 m in 10s of m

 

[Pat Proctor]

Over the entire length of the map, this comes to a 1 arc-second difference, which is 1/3rd of a data point, meaning that it might or might not "squish" one extra column of elevation data into the map, depending on how the engine does its rounding. For both m/s and the alpha value, it is always best to use the most accurate number you can (at least down to the hundredths) because errors in these numbers get propagated throughout the entire map when it is generated.

 

[TDR]

Thanks. I was no sure if the alpha value and the m/s were simple integers or a decimal value. Having the m/s defined to a few dec places helps.
Shrinking the scanned map is a bit of a bother as the program only runs with integer values when using % reduction. I have to do a calculation on the actual pixel size on width and height to then shrink based on absolute values to get it as close as possible.

I was getting worried I might be a bit to pedantic with the needed outcomes, though things seem to be coming together.

 

[Pat Proctor]

If it is possible, it would be great if you could share the map with the rest of the community. I understand if you can't, though.

 

[TDR]

If it is possible, it would be great if you could share the map with the rest of the community. I understand if you can't, though.

Depends on a few issues.

As it is there is a long way to go, like Terrain Type definitions and the concepts of vision, Movement restrictions and the concept of height.

Simle example below:

Now most of the example escarpment is only allows movement by foot/dismounts. Few places may permit movement by all wheel drive wheeled vehicles or tracked ones. The local "tracks" on the escarpment MAY permit movement by most vehicles in most locations. Certain wheeled vehicles will not beable to travel on some of the tracks.

Hence after finishing basic map be prepeared for lost of "Terrain Type" questions.