SRTM outside the USA

[Guest vlada stoje]

I noticed new directory North America on the sites JPL NASA SRTM Public Distribution http://www.jpl.nasa.gov/srtm/pub_dist.htmI didn't count or check all the files, but it seems that there are 3arc sec elevation data for whole continent. (Up to the parallel 60 - the limitation of the Endeavour orbits during this famous geographical mission.) Such detailed elevation data are here for free first time for countries outside USA. I was curious and watched one tile N19W099 with the Popocatepetl (5400 m in the SRTM file) in the program Surfer 8 (blue color = missing data). Just beautiful, isn't it? We can look forward for the directories with other continents perhaps in the near future?

[Holger 0]

Hi Vlada:thanks a lot for posting the link! It's not very exciting news for mesh designers in the US, as they already have a much better freeware DEM (see John Childs' note on his http://www.terrainmap.com/ website). But it is very good news for North American designers outside the US. For example, now high-quality meshes of the Canadian Rocky Mountains or the Sierra Madre Oriental seem within reach. I did a quick check for the Rockies - the files are all there and look pretty good (though some small holes might need to be patched with GTOPO30 data or otherwise interpolated). Moreover, the file format can be read directly by MicroDEM and the data don't need to be changed to a different projection. Of course, the final proof (of quality) will be in people actually converting the data into a FS2002 .bgl. It'll be interesting to see what the best LOD will be for these data, as they were deliberately decrased in detail from 1 arcsec (~30m) to 3 arcsec (~90m).Cheers, Holger

[rhumbaflappy 113]

Hi Holger.I'll bet the 3 arcsec data will translate to LOD9 the best. And as it is derived from 1 arcsec data, it should be very nice, and at LOD9 still framerate-friendly.If you look under the GDPSUS folder, there appears to be a full set of 1 arcsec data up to 60* lat!Dick

[Holger 0]

Hi Dick:thanks for the pointer. Unfortunately, all the files above 48N are for the Alaska areas only. Then again, I'm not sure if I really would want to deal with these massive files anyway; the 1-arcsec files are ~25MB unzipped each!As for Canada and Mexico, I bet there's a race going on now between payware developers trying to be the first to issue a complete set of terrain meshes based on SRMT ;-)Don't worry guys, I wont compete :-)Cheers, Holger

[Guest]

Hi Dick,I have tried LOD 8 and 9 with Canadian Rockies data. Both look pretty good, given that the point spacing appears to be about 120 m at this lattitude, Half way between LOD 8 and 9.Just a quick note that the 1 arcsec data for "north of 53" appears to cover only Alaska and the Alaskan panhandle, with some necessary overlap into B.C.Best,Gary

[Guest]

Hey Holger!The issue is not the generating of the BGLs, its how to get the BGLs to the users ;-)I have generated all the BGLS for the 3-arc-second data after patching the 'holes' using simple Delaunay and averaging. Each BGL covers one square degree (at LOD 9). But there's so many of the blasted things (about 650) and they are all reasonably big (400-700KB each), I have no idea how I would make them available.I'm fairly sure avsim doesn't want to handle that big a problem ;-)-david-

[Holger 0]

Hi David:that's a very good point about the number and size of files. Gary's comment about using LOD8 instead of 9 is one interesting option for cutting down file size, and it would still result in better mesh for Canada than is currently available. The other options are to go payware and start burning disks ;-) or to enjoy your own work and let others buy the disks from the payware vendors that are racing to be the first to offer complete sets of the SRTM data.My approach/suggestion (based on using FS2002 mostly for VFR flying) would be to consider quality more important than quantity. Why do I need all of Canada/USA/Mexico, etc., when I can only explore a few areas anyway? I'd rather have a few great-looking places than the entire country with lots of visual problems (I realize, of course, that everyone has different favorite places to fly) .With quality I refer to the "post-production" process, such as adjusting lake elevations or dealing with the positional discrepancies between the mesh and the FS default scenery, which appears to be a bigger problem in B.C. and southeast Alaska. Below is a screen shot comparison of an area north of Prince Rupert; the upper panel shows the SRTM LOD9 data as is and the lower panel the same area after I measured and corrected for positional discrepancies (like I did in my LOD7 and LOD9 BC mesh packages). BTW, this offset is the same problem that plagues Ed Denney's meshes of Alaska.My intention is to slowly update and extend my B.C. LOD9 mesh series, using 2x2 or 3x3 degree sections (4-6 SRTM tiles), complete with flatten switches for all offending lakes and airports as well as positional corrections where necessary. Each package will be less than 10MB and I don't have any intention to cover the entire province. On the contrary, I hope to inspire other people to do the same for other areas and upload the packages as freeware to AVSIM or elsewhere.Cheers, Holger

[rhumbaflappy 113]

Hi Holger.I'm hoping MS will give us lakes and shorelines with better positioning in FS2004... but I'm not going to hold my breath. :)Microsoft does have access to much better georeferenced line and poly data than they had when FS2002 was being deeveloped, as evidenced by MS's MapPoint program. Who knows if they will use it.If they do chose to use a better set of data for coasts, lakes, streams, and roads, the size of FS2004's data will increase substantially... FS2004 would probably need to be delivered on 6-12 CD's instead of 3. Not that the cost of the CD's is much ( pennies in bulk ), but the packaging would be more costly. Also, I wonder if this "forced" early release is actually going to suppress any attempt to improve the data set.. just not enough time.============The reason I bring this up, is that your mesh could be positioned correctly, with the right datum and projection, but still look wrong due to the positioning of the lakes, etc... I'm sure you're aware of that. But other, less experienced mesh-makers might not have thought of that.Personally, I would rather replace the LWM and VTP files to correct the problem. ( Move the roads and lakes to wheere they should be ).We can usually find better GIS data for lines and polys than what MS used ( in fact their data is about the worst you can freely get ). But we don't have the full understanding of some of the VTP line structures, and we'd need an automated process to create the BGLs from the GIS data. That could put it beyond the finances of most of us.Your idea to alter the mesh positioning might be the best solution if FS2004 doesn't use a better data set.Dick

[Holger 0]

Hello Dick:very well said - I agree with all your points and really don't think that we'll see much of an improvement with terrain or hydrography in FS2004 (though I wouldn't bet my (non-existing) farm on it). Since most users seem to crave detailed airports and big iron there's not enough public pressure on MS to hire Slartibartfast, the famous coastline/fjord-maker of Douglas Adams' Hitchhikers Guide to the Galaxy ;-)"... your mesh could be positioned correctly, with the right datum and projection, but still look wrong due to the positioning of the lakes, etc... I'm sure you're aware of that. ..."That's exactly my point! I had to move my BC mesh tiles away from their true location to match them up with the default hydrographic features. Since the offset is quite consistent in direction and extent, I suspect that someone goofed when transforming the source vector data from one geographic projection/datum to another.I thought about creating a new set of roads and hydrography instead of moving the mesh, since I have much better digital linework of most of BC. However, the steep learning curve (not to mention the missing knowledge that you mention) seemed too difficult to master at the time. Instead I set up my own EXCEL spreadsheet to help me with measuring and calculating those pesky offsets.Even if FS2004 comes with better linework, all I'd have to do is recompile my mesh tiles with the original (accurate) coordinates and re-upload a new version.Moving right along....Cheers, Holger

[jkanold 0]

Can you explain exactly how, and by how much you shifted the DEM?http://members.rogers.com/jkanold/jimlogo.gif

[Guest Cazador]

Dear All:The scenery offset is due to the SRTM projection = WGS84, while the scenery vector data has other projection.I have solved that problem creating both Phototerrain scenery and Mesh terrain scenery with the WGS84 data projection.ThanksAlfredo Mendiola LoyolaLima Peru

[rhumbaflappy 113]

Hi Alfredo.The scenery ( roads, lakes, streams ) is supposed to be = WGS84... but who knows what it really is. :)The FS World is WGS84 datum, equiangular projection. By equiangular, I mean all lines of latitude meet all lines of longitude at 90 degrees. A 1x1 degree map is square. A 45x45 degree map is square. This is sometimes refered to as "raw latitude-longitude", or "simple cylindrical", or "lat/lon" or "Plate-Caree" or "Equatorial Cylindrical Equidistant (ECE)" . It is even refered to as unprojected! ;) I think it's great when scientists and mathematicians can't agree on simple terminology.The FS World:http://www.colorado.edu/geography/gcraft/n.../gif/unproj.gifWhen the sim re-projects our lines and polys and mesh back onto the spherical FS World, the distortions are removed. http://nsidc.org/data/psq/grids/ece_grids.htmlTMFViewer from Microsoft shows the DEM data from the BGLs, as well as LWM and VTP and Landclass... all in "unprojected" projection.It's unfortunate thet MS didn't release a TMFEditor! The closest thing we have now is Ground2K... which we can use to grab georeferenced screenshots from TMFViewer ( or any properly "unprojected" bitmap ). I used TMFViewer, and Ground2K to recreate Prince Edward Island's landmass.An ideal program would be able to translate DXF CAD files ( that are georeferenced and "unprojected" ) to LWM and VTP BGLs. There are programs that can translate various GIS formats to DXF. Then some freeware CAD programs can be used to manipulate the data.Even Gmax has DXF file import capability as an addon. Who knows, maybe there will be a Gmax script to export BGLC code someday. Then we could correct the world's roads, streams, and polys in systematic ways using Gmax.As far as what MS used for the scenery lines and polys, I think it is based on the old Digital Chart of the World dataset ( in turn based on OLD US CIA data ). As I mentioned, MS has access to a much improved dataset via the MS MapPoint data they already own.I'm assuming they won't use it for FS2004... they certainly did not access this set for the horrible CFS3.============Holger's solution to simply offset the mesh points is a good quick solution. Ultimately, it's not the DEM data, but the roads, streams, and lakes that are not right in the sim. And there is no easy way for us to fix that. Dick

[Holger 0]

Hi Jim:sure, just send me a cheque and I consider it...Just kidding! It's no rocket science and basically only means changing the Lat/Lon values in the .inf file. For the example screen shots in my previous post, I altered the original lines:Lat = 55.950000Lon = -131.999720toLat = 55.943750Lon = -131.994720And here's how I come up with these values:1. Start a flight in the area of interest at a time and season that highlights the topography and hydrology (for the screen shots below I used Feb 1, approx. 22:20 GMT), and go into top-down view.2. Find an area that shows obvious and consistent signs of a positional mismatch. I have attached two screen shots that should give you an idea of what I mean by this. Other good areas are valleys with streams (and don't use roads as indicators; they are all over the place).3. In the images, I use RED arrows to indicate the direction and distance the FS2002 default scenery would have to be moved to better fit with the mesh. Since that is not feasible, we'll have to move the mesh to fit with the scenery, i.e., the inverse direction, which I indicate with WHITE arrows. 4. Press Shift-Z to display coordinates on the screen.5. The measurements involve taking pairs of coordinate readings at the places where the mesh should be and where it currently is (i.e., the bases and tips of the arrows in the images). I tend to get confused about which direction to move so I suggest to write down the general direction (i.e., southeast) right away. 6. I then type the number pairs into an EXCEL spreadsheet that computes the difference between each pair, gives me an average offset, and transforms that value from decimal minutes (the FS2002 screen readings) into decimal degrees, as required by the .inf file7. Subtract from or add to your original NW corner coordinates the average offset and recompile the mesh tile.8. Check the result in FS2002 and repeat as necessary (keep the previous version to be able to switch back and forth).It sounds tedious but once you get the hang of it and have your own little setup it's quite fast. I usually take only a few readings per tile (and my BC LOD7 mesh tiles were 3x6 degrees) in different corners.Be aware, however, that this procedure only works where a consistent offset exists, and that it won't solve all the problems with high-res mesh data, such as incorrect lake elevations, airport placement, etc.Also, if the offset differs between neighbouring tiles (such as in the two example images below) you might end up with visible seams where they join. Not very nice but, in my opinion, still better to have a few seams than the whole tile area out of whack.Hope this helps.Cheers, Holger

[Guest Cazador]

Dear Dick:The default FS2002 Mesh terrain GSTOPO30 has an offset, for example when i place my roads and river made with ASD over the default Fs2002 scenery, the rivers don't were in the valley bottom else 200 meters at the north of the bottom.I think the microsoft offset the Vector data to match the GSTOPO30 data.When i edit my GSTOPO30 data with the correct elevations from topographic maps using the DEM editor in MD-TBII, i see the default river outside the valleys bottom.

[rhumbaflappy 113]

Hi Alfredo.Assuming MS used Gotopo30 Data, and depending on their resample LOD ( probably LOD5 ), it would be no wonder the mesh is not quite right. MS used free data, and in 1998-99 that was Gotopo30 elevational data and DCW vector data. And that vector data doesn't match any known mesh. I could also find lots of examples of the streams lakes and roads not being anywhere near where they exist in reality... and that's why lakes and coasts need LWM flattening. Streams still run uphill, just like they did in FS2000.I doubt MS would offset vector data to match that mesh, or vice versa. That would be a huge task, and MS didn't spend much time or effort on the mesh or vector data.If streams or roads "fit" the mesh in FS2002, it's just by chance that the resampling of their DEMS matched the roads or streams in a small area. I have installed more accurate mesh sets to the sim, and then the default lakes and streams generally fit better. That would indicate the crude MS vector data was not altered.If they had used good vector data and good DEMs, we wouldn't even be having this discussion. :)Here's the sourcedata for Gotopo30 DEMS:http://edcdaac.usgs.gov/gtopo30/gifs/gt30src.gifSo much for accuracy... it's not even a consistant set, but a compilation of varying sources, datums, projections....================Concerning the vector data, from the DCW docs:"The U.S. Defense Mapping Agency Operational Navigation Chart (ONC) series and the Jet Navigation Charts (JNCs) for the region of Antarctica were the primary sources for the Digital Chart of the World database. The ONCs have a scale of 1:1,000,000, and they are the largest scale, unclassified map series produced by the DMA that provides consistent, continuous global coverage of essential basemap features."As far as the Datum for the DCW vector data.. the docs state several different datums were used... but that's not the main problem:"It should be noted that the difference between the possible datum values is relatively insignificant when compared to the potential error induced simply by the scale of the data and other sources of error."So it is the scale of the data that causes major errors. The scale is 1 millimeter = 1 kilometer! A lot of room for error. I think the scale of the Gotopo30 data is also the major cause of errors in the default mesh. And I know the landclass MS used could not be the correct projection ( for the same above reasons ), but because of the crudeness of the data, the scale, and the way resample resolves averaging, it really didn't matter. That's why some mid-to-small sized cites are not even in the sim. They existed in the data, but resample doesn't have a "weighting" for city types of data when resampling ( to give them priority ). I think Justin Tyme is having these same problems with his US landclass set, and had to do some hand-altering to include these smaller cities.================In CFS2, MS abandonded creating most of the LWM lakes and rivers and VTP BGLs. The VTP BGL structures were cruder than in FS2002... they are at least 4 times larger than FS2004's VTP BGLs. Financially, it didn't make sense to put in the crude DCW data in that sim, as it would have taken many CD's to include it. For FS2002, they invented a more concise code for VTPs ( VTP2 ) and that allowed the crude set to be included into the sim. There was also a change in the way landclass water designation is used that reduced the need for LWM watermasking in the oceans, unlike CFS2.For FS2004, if design team wanted more detailed vector data sets, that would increase the size of the software by at least a factor of 4, just to get the major vector data positioned right. I don't think they want to deliver FS2004 on 6-8 CDs, so I imagine the same vector data will be used. I don't expect a change with the DEMs either, for the same reasons.Dick