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

[Curtis O. <cur...@gm...>]

On Jan 7, 2008 5:10 AM, Ralf Gerlich <rge...@kn...> 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/