FSDEM 1.0 bug report

[asquel 2]

Hi Emerson !Thanks for your nice little program. I wanted to report you a couple of bugs I discovered when using FSDEM.I am building a LOD9 mesh, following a round-the-world flight, using SRTM data. For my own convenience, I wanted to make bgl files corresponding to adjacent tiles of 5

[Guest roto5]

Hi!>I wanted to make bgl>files corresponding to adjacent tiles of 5

[asquel 2]

Hi !The answers to your questions :>How did you check the 9.48' boundary? Using TMF Viewer?I checked with TMFViewer, but as you can see on the attached image in my first post, it is also visible on the FS9 map ; the "boundary" is also visible on the "real" landscape.>Is your mesh a single BGL, or multiple "adjacent" BGLs?In this case, I used the same philosophy as before : BGLs corresponding to tiles of 5

[Guest DanVickers]

I have also experienced the PROGRESS BAR OUT OF RANGE error. It only occurs to me when building multiple HGT files and I select the INTERPOLATE VOID operation. Loading multiple files and creating BGL files with out interpolation seems to work okay for me???Excellent program by the way!Cheers,

[Guest sgreenwood]

Hi Alain,"But I discovered that at tiles boundaries, there remained bands at FS default resolution."That's due to the way Resample & FS work together. I describe this issue in the context of GTOPO30 data, but it applies to the use of Resample in general:http://www.fs-traveler.com/mesh-gaps.shtmlThis should help."the result was a real improvement over the default mesh";-) Upon further relection, while it's not clear what source data MS used, they may well have used GTOPO30 data in some areas. This would explain the sometimes only subtle improvements I see (due to differences in LOD?). As you have seen, other areas can benefit quite a bit from mesh constructed from 30 arcsec data. Since this data was available to MS, we can only speculate as to how they decided what source data to use for their default mesh. Unfortunately, I know of no way to identify those areas that can be improved this way without actually creating new mesh and comparing it with the default. Steve

[asquel 2]

Hi Steve,I read your analysis on your site, and I decided to load tiles of 6

[Guest sgreenwood]

Hi,I agree, the solution is not elegant, but it does demonstrate the issue. It is an ineffecient approach to development because it requires a bit more administrative effort and more time, especially for the conversion process. There is another annoyance as well; if there is a problem that needs repairing in the area of overlap, it has to be repaired twice. :-(The overlapping mesh will not take up more memory when using it in FS, however. The sim only loads small segments of a bgl file at a time, after calculating the appropriate offset into the file. I'm not sure what you are referring to when you say you "don't want to do it manually every time I create a flight." The overlapping mesh causes no problems, any more than when we have as many as five different resolutions of mesh active for the same area at one time. So go ahead and continue creating mesh and enjoy it while waiting for better development tools. You may decide it is not worthwhile to go back and rebuild the areas where you had to overlap the data the first time around.Steve

[asquel 2]

Hi SteveThanks again for your illuminating explanations !>I'm not sure what you are referring to when you say>you "don't want to do it manually every time I create a>flight." I was just thinking of converting the needed HGT files to binary sequential files, and using "manually" a software to cut that matrix and keep the right number of rows and columns. But I'm not sure of what kind a software to use ; however, I saw that MicroDEM has the capability to edit that kind of matrices ; but anyway, I think it becomes too cumbersome to do that before every flight !!CheersAlain