Hi Christian! Christian Buchner wrote: > I found another slight discrepancy when converting back each tile's > geodetic center coordinate to a bucket - this function might be slightly > buggy: In a few cases it returns a different bucket number than given by > the original file name of the tile. I can work around this problem, but > I wonder if other parts of FlightGear might be affected by this bug.
I was just about to write a bug report about the same thing when I found and reread your mail. I came across this problem with the current scenery rebuild. Interestingy the first run went without mostly no problem, but the second run - initiated as Curt was missing some "settlements" - brought up many failing tiles in the pole regions, due to faulty tile indices used for location of shared edge elevation data. I investigated further and there might be a connection to the "missing poles" problem Torsten reported some time ago. The set_bucket()-function will calculate different tile numbers for the poles - even though the pole (180W,89N to 180E,90N) should be one tile - depending on whether you are on the western or the eastern hemisphere. This has to do mostly with the special cases introduced for rounding (regarding SG_EPSILON) and for covering the difference between (int) cast rounding towards zero and the desired behaviour more similar to a floor(). Also the westmost tile on the tiles between 88 and 89 deg latitude is 8 degrees wide according to sg_bucket_span(), but starts at -180, which is not divisible by 8. This means that e.g. 176W, 88.5N is both on a tile starting at 180W and at 174W. I was able to correct most of the inconsistencies without regression (tested using random testing and 1.000.000 testcases, but verifiable formally as well, I think), and I even introduced special-case handling for the 180W-tile at 88-89 deg latitude. Regression here means that for the positions tested both the old and the new code report the same tile index. The part for the poles (above 89 deg latitude) cannot be fixed without "regression", as depending on the longitude (western or eastern) the old code reports different tile numbers, while it should not. This might affect several applications, among them reading of scenery and placement of objects, due to the differing tile numbers. This is grid system has been in existence since at least September 2002, as this is the date when the CVS for SimGear 0.3 started. We will not get rid of that problem without lots of special case handling or some flag day after which the old tile numbers will not be valid anymore. Cheers, Ralf ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
