Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Wednesday 09 January 2008 00:24, Adam Dershowitz wrote: On Jan 7, 2008, at 7:15 PM, LeeE wrote: On Monday 07 January 2008 22:28, Curtis Olson wrote: On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. Regards, Curt. Yup - I downloaded lots of SRTM data to play with in GRASS and above/below +/- 60 lat it isn't there. For the SRTM mission the shuttle was at an inclination of 57 degrees, which I believe was the maximum that the shuttle could reach. At that inclination it could not see much higher latitudes. Thanks for the info - I guessed the reason was something like that. Polar orbits are expensive regarding fuel because the Earth's rotation does nothing to help you get there. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 8, 2008 1:22 AM, Frederic Bouvier wrote: I was thinking about the parameter we pass to Terra to simplify the initial grid. IIRC, this parameter is always the same, leaving all *.arr.gz files with the same number of vertices. Yes, that's a good point, and something definitely to think about if we made such a tile layout switch. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 7, 2008, at 7:15 PM, LeeE wrote: On Monday 07 January 2008 22:28, Curtis Olson wrote: On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. Regards, Curt. Yup - I downloaded lots of SRTM data to play with in GRASS and above/below +/- 60 lat it isn't there. For the SRTM mission the shuttle was at an inclination of 57 degrees, which I believe was the maximum that the shuttle could reach. At that inclination it could not see much higher latitudes. There doesn't seem to be any alternative source of suitable data either so I don't see how FG can cover the poles. (the reason I was looking was because I was interested in the Mt Erebus volcano - FG is quite good for looking at volcanos and other large scale geological features from the air - at some point I'll get together a list of volcanos and astroblemes for the 'places to fly' section of the FG docs/wiki) LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
Hi again!
Thinking a bit more about it, the grid could be made consistent if we
would define that 180W and 180E are tile borders instead of enforcing
the Greenwich Meridian to be a tile border at all ranges of latitude.
Find attached my proposed patch.
That would change the arrangement of tiles between 88 and 89 degrees
latitude, fix the inconsistency above 89 degrees latitude, but would
leave the rest of the tile numbers as they are (due to the fact that
tile widths there are divisors of 180) and give us the following benefits:
1) calculation of base longitude would be much easier:
base_lat=(int)((int)((lat+180)/span)*span)-180
with rounding:
base_lat=(int)((int)((lat+SG_EPSILON+180)/span)*span)-180
2) The tiles at 180W/E between 88 and 89 degrees of latitude would not
overlap with their neighbours anymore and have 8 degrees width, as all
the other tiles at that latitude.
3) The calculation above would always lead to 0 as base longitude for
the tiles above latitudes of 89 degrees instead of the flipping of -180
vs 0 depending on the sign of the longitude.
The fact that people seldomly fly north or south of 88 degrees latitude
might be seen as an argument in favour or against this change.
This is a bug that has not created serious problems in FlightGear
itself, but formally, it is a bug and it _has_ created problems in at
least two scenery-related applications, one of them being TerraGear.
Therefore I would vote in favour of such a change.
Any other comments or votes?
Cheers,
Ralf
From 4462aa3518b65ed76b6fc8a4cabae730fcd160fa Mon Sep 17 00:00:00 2001
From: Ralf Gerlich [EMAIL PROTECTED]
Date: Mon, 7 Jan 2008 12:03:44 +0100
Subject: [PATCH] Make the tile grid consistent.
This changes the actual tile numbering only in the range above 88 degrees latitude and fixes inconsistencies in other areas.
---
simgear/bucket/newbucket.cxx | 46 -
1 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/simgear/bucket/newbucket.cxx b/simgear/bucket/newbucket.cxx
index 71c0ac2..9135f24 100644
--- a/simgear/bucket/newbucket.cxx
+++ b/simgear/bucket/newbucket.cxx
@@ -88,48 +88,12 @@ void SGBucket::set_bucket( double dlon, double dlat ) {
// latitude first
//
double span = sg_bucket_span( dlat );
-double diff = dlon - (double)(int)dlon;
-
-// cout diff = diffspan = span endl;
-
-if ( (dlon = 0) || (fabs(diff) SG_EPSILON) ) {
- lon = (int)dlon;
-} else {
- lon = (int)dlon - 1;
-}
-
-// find subdivision or super lon if needed
-if ( span SG_EPSILON ) {
- // polar cap
- lon = 0;
- x = 0;
-} else if ( span = 1.0 ) {
- x = (int)((dlon - lon) / span);
-} else {
- if ( (dlon = 0) || (fabs(diff) SG_EPSILON) ) {
- lon = (int)( (int)(lon / span) * span);
- } else {
- // cout lon = lon
- // tmp = (int)((lon-1) / span) endl;
- lon = (int)( (int)((lon + 1) / span) * span - span);
- if ( lon -180 ) {
- lon = -180;
- }
- }
- x = 0;
-}
-
-//
-// then latitude
-//
-diff = dlat - (double)(int)dlat;
+
+lon=(int)((int)((dlon+180+SG_EPSILON)/span)*span)-180;
+x=(int)((dlon-lon)/span);
-if ( (dlat = 0) || (fabs(diff) SG_EPSILON) ) {
- lat = (int)dlat;
-} else {
- lat = (int)dlat - 1;
-}
-y = (int)((dlat - lat) * 8);
+lat=(int)((int)((dlat+90+SG_EPSILON)/SG_BUCKET_SPAN)*SG_BUCKET_SPAN)-90;
+y=(int)((dlat-lat)/SG_BUCKET_SPAN);
}
--
1.5.3.4
-
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] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 7, 2008 5:10 AM, Ralf Gerlich [EMAIL PROTECTED] wrote: Thinking a bit more about it, the grid could be made consistent if we would define that 180W and 180E are tile borders instead of enforcing the Greenwich Meridian to be a tile border at all ranges of latitude. Find attached my proposed patch. That would change the arrangement of tiles between 88 and 89 degrees latitude, fix the inconsistency above 89 degrees latitude, but would leave the rest of the tile numbers as they are (due to the fact that tile widths there are divisors of 180) and give us the following benefits: 1) calculation of base longitude would be much easier: base_lat=(int)((int)((lat+180)/span)*span)-180 with rounding: base_lat=(int)((int)((lat+SG_EPSILON+180)/span)*span)-180 2) The tiles at 180W/E between 88 and 89 degrees of latitude would not overlap with their neighbours anymore and have 8 degrees width, as all the other tiles at that latitude. 3) The calculation above would always lead to 0 as base longitude for the tiles above latitudes of 89 degrees instead of the flipping of -180 vs 0 depending on the sign of the longitude. The fact that people seldomly fly north or south of 88 degrees latitude might be seen as an argument in favour or against this change. This is a bug that has not created serious problems in FlightGear itself, but formally, it is a bug and it _has_ created problems in at least two scenery-related applications, one of them being TerraGear. Therefore I would vote in favour of such a change. Any other comments or votes? Hi Ralf, My one comment about your patch is that with the original code I can sit down and read through it and roughly see what's going on. The replacement code is all packed into a line or two and it is much less clear (at least to me) what is going on. Perhaps you could also include some comments explaining the computation you are doing. I realize not everyone agrees with me, but I really like understandable code ... even though the definition of understandable is very tricky and hard to nail down and is different from person to person. I'm not intending to be nitpicky here. The flightgear tile system is pretty crucial to many areas, so I don't want the math to be obfuscated too much in case someone has to go in later and debug it or update it. In fact I have a proposal for a modification to the flightgear tiling arrangement, but I was leaving that for some future day when I had more time to think about it. The big problem with the current system is that at every latitude boundary where the number of tile subdivisions changes per degree, we have ugly gaps because the tile edge matching code simply can't account for 2 tiles matching up to 1 tile ... an oversight in the original scheme. I've been wondering about dispensing with the variable subdivision scheme and just having a fixed number of divisions per 1 degree of longitude. Perhaps having 4 subdivisions. This would double the tile width at the equator, but would preserve the same tile widths in the sweet spot that covers the bulk of the USA/Europe, and would half the width at the northern latitudes. Then things would get really skinny up towards the poles, but perhaps our system would handle that just fine. Originally the tile pager needed approximately even tile widths because it could only load a fixed 3x3 or 5x5 square grid of tiles. Now we can vary the grid dimension in X and Y to cover the current visibility so the original scheme isn't needed and we can live with tiles that are skinny or fat, and as our graphics power and library sophistication has increased over the years, I don't think that would be an issue either. What do you think about that? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
Selon Curtis Olson : I've been wondering about dispensing with the variable subdivision scheme and just having a fixed number of divisions per 1 degree of longitude. Perhaps having 4 subdivisions. This would double the tile width at the equator, but would preserve the same tile widths in the sweet spot that covers the bulk of the USA/Europe, and would half the width at the northern latitudes. Then things would get really skinny up towards the poles, but perhaps our system would handle that just fine. If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Monday 07 January 2008 22:28, Curtis Olson wrote: On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. Regards, Curt. Yup - I downloaded lots of SRTM data to play with in GRASS and above/below +/- 60 lat it isn't there. There doesn't seem to be any alternative source of suitable data either so I don't see how FG can cover the poles. (the reason I was looking was because I was interested in the Mt Erebus volcano - FG is quite good for looking at volcanos and other large scale geological features from the air - at some point I'll get together a list of volcanos and astroblemes for the 'places to fly' section of the FG docs/wiki) LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
Selon Curtis Olson : On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. I was thinking about the parameter we pass to Terra to simplify the initial grid. IIRC, this parameter is always the same, leaving all *.arr.gz files with the same number of vertices. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
