Some problems with satellite data for maps

[nix]

I have just tried to make my first map  using satellite elevations and Brucepos ver3 method to produce an accurate terrain for the battlefield (Ocana 1809 spain 10km). I finally succeded but had a couple of problems which others may face when trying to make a historical scenario on an accurate terrain:

Firstly the spot heights in the data sets are at about 80m intervals so this tends to smooth out any steap slopes and impassable terraine: the rough places are made smooth...

Secondly in google earth ver5.2.1.1588 I find many of the data sets for elevation are easily available to download as 5deg tiles (with 6001x6001 data cells) but only some now seem to be available as 1deg tiles (1200x 1200 data cells). For Ocana I could not find the 1 deg tiles to download. This is a problem since the data set is 25times larger for the 5deg tile and notepad would not open it (wordpad would though so it is possible to edit the data). The SciLab program also could not load the 5deg set (rather I waited 30 mins while it tried at CPU 100% before I abandoned the task!). Does anyone know if the 1deg data sets are being phased out?

Luckily Ocana is located near the top of one of the 5deg tiles so i calculated the data i needed was in the first 106 of the 6001 rows so by using wordpad to copy the 106x6001 cells i had a file which could then be processed by SciLab a la Brucepos and produced a nice terrain in fair agreement with a contour map. (I will put the map on the depot when i have finished it)

This by hand extraction of data can only work if the site you want is near the top or bottom edge of the 5deg tile  as you loose track of row numbers very quickly! ( I tried opening the file in Excell to assist in this but without success!)

[Alfiere]

Firstly the spot heights in the data sets are at about 80m intervals so this tends to smooth out any steap slopes and impassable terraine: the rough places are made smooth...

Sorry , i have not understood.

Secondly in google earth ver5.2.1.1588 I find many of the data sets for elevation are easily available to download as 5deg tiles (with 6001x6001 data cells) but only some now seem to be available as 1deg tiles (1200x 1200 data cells). For Ocana I could not find the 1 deg tiles to download. This is a problem since the data set is 25times larger for the 5deg tile and notepad would not open it (wordpad would though so it is possible to edit the data). The SciLab program also could not load the 5deg set (rather I waited 30 mins while it tried at CPU 100% before I abandoned the task!). Does anyone know if the 1deg data sets are being phased out?

I heard of subtiles,but for now I always worked only with 5deg (6001x6001)
Aniway ,you have only to wait , for me i wait only 5-10 minutes (more or less) for Scilab.
Long time when i have to delete the headers and save how txt file with notepad. (also 15 minutes)

Luckily Ocana is located near the top of one of the 5deg tiles so i calculated the data i needed was in the first 106 of the 6001 rows so by using wordpad to copy the 106x6001 cells i had a file which could then be processed by SciLab a la Brucepos and produced a nice terrain in fair agreement with a contour map. (I will put the map on the depot when i have finished it)

Strange,Scilab use a formulas for top,bottom,lft,right to calculate data having 6001x6001 matrix.
You,cannot change this matrix in imput at 106x6001.You are sure that work right?

[nix]

Perhaps my computer is a bit underpowered as it is a few years old.! (Pentium4 2Ghz 1Gb ram windows XP SE) It handles the 1deg data files fine but goes into a tizzy with the larger 5 deg data files.

The method I used to reduce the size of the data matrix worked correctly, i compared the terrain map that Histwar generated using the HighV4.hgh file, with a proper contour map for the region!

Sci lab doesnot have to read only square matrices. However if you remove data by hand you must ensure that you remove whole rows of data and not just part of a row and you need to be aware of the lattitude associated with the rows which remain. If you do that you can use scilab to strip out the data for the area of the HistWar map using the same proceedure outlined by brucepos. (remember that each row of data in the matrix is associated with a particular latitude (= yll + 0.00083333333 x number of rows up from bottom of original matrix) and each column is associated with a particular longitude (= xll + 0.000833333 x number of columns along from bottom  left corner of original matrix).

[Alfiere]

Perhaps my computer is a bit underpowered as it is a few years old.! (Pentium4 2Ghz 1Gb ram windows XP SE)

The method I used worked correctly, i compared the terrain map that Histwar generated using the HighV4.hgh file, with a proper contour map for the region!

Sci lab doesnot have to read only square matrices. However if you remove data by hand you must ensure that you remove whole rows of data and not just part of a row and you need to be aware of the lattitude associated with the rows which remain. If you do that you can use scilab to strip out the data for the area of the HistWar map using the same proceedure outlined by brucepos.

Ok,good to know.

[nix]

NB dont just blindly use brucepos formula to calculate top , bottom, left ,right of the box of data you want if you remove data from the original square matrix. Think about the lattitude and logitude of the first entry in the top left corner of your smaller matrix and the lat and log of the four corners of the box of data corresponding to your map area. then you can calculate the top bottom left and right values for use in scilab. (these values are just the row number and column number of the entries corresponding to the corners of the block of data corresponding to your map, taking the top left of your data matrix as origin. Each step from row to row  or column to column corresponds to a change of 0.000833333 degrees in logitude or latitude).

see picture and example:

http://www.keepandshare.com/doc/2645081/satellite-470k?da=y

hope this helps anyone else having the problem opening large files!

Also as an example about the smoothing:

if the terrain had say an 80m high cliff it would appear in the histwar map as a steep 45deg slope not as a cliff due to the fact that the data is only sampled at 80m intervals. This is only a problem for sharp features with resolution of less than 80m. Hence 'the rough places are made smooth'...