Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-09 Thread LeeE
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 d

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-08 Thread Adam Dershowitz
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 real

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme

2008-01-08 Thread Ralf Gerlich
Frederic Bouvier wrote: > Selon Ralf Gerlich : > > >> The alternative would be to scale the number of vertices passed to >> TerraFit by cos(lat)... > > I was thinking of this solution : regular lon/lat tile scheme but variable > number of resulting vertices per tile. That's what I meant ;-) --

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme

2008-01-08 Thread Ralf Gerlich
Ralf Gerlich wrote: > Currently we have tile borders that are representable as polygon - more > strictly as rectangles - which makes clipping easy. The new tile borders > could not be well-approximated using polygons. We could try creating > clipping polygons that approximate the borders down to an

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme

2008-01-08 Thread Frederic Bouvier
Selon Ralf Gerlich : > The alternative would be to scale the number of vertices passed to > TerraFit by cos(lat)... I was thinking of this solution : regular lon/lat tile scheme but variable number of resulting vertices per tile. -Fred -- Frédéric Bouvier http://frfoto.free.fr

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme

2008-01-08 Thread Ralf Gerlich
Hi! Curtis Olson wrote: > 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

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-08 Thread Curtis Olson
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 definite

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme

2008-01-08 Thread Ralf Gerlich
LeeE wrote: > 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. FG can cover the poles - and has been doing so for years

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme

2008-01-08 Thread Ralf Gerlich
Hi! Frederic Bouvier wrote: > Selon Curtis Olson : >> 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 o

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-07 Thread Frederic Bouvier
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

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-07 Thread LeeE
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

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme

2008-01-07 Thread AnMaster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Curtis Olson wrote: > 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 > a

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-07 Thread 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

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-07 Thread Frederic Bouvier
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

Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-07 Thread Curtis Olson
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

[Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)

2008-01-07 Thread Ralf Gerlich
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