Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi! LeeE wrote: I think I mentioned earlier, but first problem - there's no SRTM data for the poles. Second problem is that calculations that assume a quad (trapezoidal) area fail at the poles because they have to deal with a tri area and not a quad area. The problem is not that tiles are interpreted as rectangular in the latitude-longitude system if interpreted cartesic, but instead that the tile grid is inconsistent even without the problems of representing spherical coordinates in a planar system. While what you describe are problems (e.g. I had to remove an airport located at one of the poles because it gave TerraGear a hard time wrapping it around the world), they do not apply for the specific bug mentioned here. BTW: The .btg.gz-files use geocentric cartesian coordinates, so that the earth is actually round and closed in the scenery. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
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/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi again! Ralf Gerlich wrote: 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(). The problem only occurs for latitudes north of 83N or south of 83S western longitudes. Only here the longitudinal span of buckets is above 1.0 and always divisible by 2, so that the center of a bucket always lies on an integral longitude. This leads to the fabs(diff)SG_EPSILON condition in newbucket.cxx:109 to evaluate to true and therefore activates the wrong calculation. Casting to (int) always rounds towards zero, which in this case leads to the base longitude being shifted eastwards by one span. In case of latitudes north of 89N or south of 89S non-western longitudes (=0) will lead to a base longitude of 0, while western longitudes will lead to a base longitude of -180. This means that the single tiles surrounding the polar caps (width 360 degree, height 1/8 degree) essentially have different tile numbers depending on whether one is coming from an eastern or a western latitude. This might also explain the missing northpole-problem reported by Torsten Dreyer some time ago. Another possibility would be that Curt's last build failed in a similar way as ours did and there are not northpole tiles ;-) Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
On Sunday 06 January 2008 21:05, Ralf Gerlich wrote: Hi again! Ralf Gerlich wrote: 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(). The problem only occurs for latitudes north of 83N or south of 83S western longitudes. Only here the longitudinal span of buckets is above 1.0 and always divisible by 2, so that the center of a bucket always lies on an integral longitude. This leads to the fabs(diff)SG_EPSILON condition in newbucket.cxx:109 to evaluate to true and therefore activates the wrong calculation. Casting to (int) always rounds towards zero, which in this case leads to the base longitude being shifted eastwards by one span. In case of latitudes north of 89N or south of 89S non-western longitudes (=0) will lead to a base longitude of 0, while western longitudes will lead to a base longitude of -180. This means that the single tiles surrounding the polar caps (width 360 degree, height 1/8 degree) essentially have different tile numbers depending on whether one is coming from an eastern or a western latitude. This might also explain the missing northpole-problem reported by Torsten Dreyer some time ago. Another possibility would be that Curt's last build failed in a similar way as ours did and there are not northpole tiles ;-) Cheers, Ralf I think I mentioned earlier, but first problem - there's no SRTM data for the poles. Second problem is that calculations that assume a quad (trapezoidal) area fail at the poles because they have to deal with a tri area and not a quad area. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
