Norman Vine writes:
> FGFS should be able to answer simple flightplan questions
> like "I am leaving from KSFO flying to KLGA show me all airports
> that are large enough to handle a 747 within 100 miles of my flightpath".
>
> Indexing makes this trivial
That's still an out-of-the-main-lo
Andy Ross
>
> Right. But this indexing of "nearby" objects can be done in memory
> (since the set of nearby objects is already available via the tile
> set). There's not need for anything fancy on disk.
FGFS should be able to answer simple flightplan questions
like "I am leaving from KSFO flying
David Megginson wrote:
> Remember Knuth's (?) warnings about premature optimization, though.
Amen. This blog says Knuth got it from Tony Hoare:
"We should forget about small efficiencies, say about 97% of the
time: premature optimization is the root of all evil."
http://www.cookcomputi
Norman Vine writes:
> FWIW IMHO We really should move the entire scennery DB into a
> spherically oriented scheme. It would be quite easy using the
> spherical indexing method in the link that I posted and then we
> wouldn't need any index other then the directory tree
Sounds good.
All the
David Megginson writes:
> Norman Vine writes:
>
> > 2) is a little more complicated but we allready have a good start
> > if we leverage the Scenery directory structure
>
> Agreed.
>
> > I suggested using a quadtree for each 10x10 degree block
> > but there are spherical indexin
Norman Vine writes:
> 2) is a little more complicated but we allready have a good start
> if we leverage the Scenery directory structure
Agreed.
> I suggested using a quadtree for each 10x10 degree block
> but there are spherical indexing methods that might be better
> i
On Fri, 11 Oct 2002 15:04:51 -0700,
Andy Ross <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Arnt Karlsen wrote:
> > ..wee tweak:
> > for i in $( seq 100 ) ; do
..should have been "$( seq 0 1 99 )"
to be precisely like your i/j job.
> > touch $i
> > done
>
> Cute. You lear
Simon Fowler writes:
>
> What about simply putting all the airport files in the scenery, and
> having a script that searched through the scenery directories for
> all the *-apt.xml files and built/updated a set of indexes from
> them? That keeps the files in the right place, and gives the indices
>
On Fri, Oct 11, 2002 at 01:57:17PM -0700, Andy Ross wrote:
> Simon Fowler wrote:
> > Performing well under Linux with ReiserFS is a good advertisement
> > for Linux and ReiserFS, but not so good for FlightGear if that's
> > /all/ we perform well under.
>
> I think you have perhaps misinterpreted.
Arnt Karlsen wrote:
> ..wee tweak:
> for i in $( seq 100 ) ; do
> touch $i
> done
Cute. You learn something new every day. I've never noticed that
utility. I have a vague memory that there is some bash syntax that
does a similar thing, too. And the $(...) syntax was new for me too
-- I wou
On Fri, 11 Oct 2002 13:50:21 -0700,
Andy Ross <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> # Make 100 empty files
> for i in 0 1 2 3 4 5 6 7 8 9; do
> for j in 0 1 2 3 4 5 6 7 8 9; do
> touch $i$j
> done
> done
..wee tweak:
for i in $( seq 100 ) ; do
touch $i
done
Simon Fowler wrote:
> One thing to note here is that all this cache take up RAM, and will
> be dropped on the floor as soon as there's any memory pressure.
Right, which is why I was careful to cite numbers that reflected
actual disk I/O, and not cache performance. Even hitting the disk,
performan
Julian Foad wrote:
> I thought it was the other way around: that most Linux filesystems (by
> which I mean ext2) and NTFS had 1K or 0.5K blocks, and that Windows
> FAT filesystems had big (generally 4K to 16K) blocks.
Nope, 4k. The underlying disks have 512 byte blocks (all IDE and most
SCSI, at
On Thu, Oct 10, 2002 at 01:10:55PM -0700, Andy Ross wrote:
> Curtis L. Olson wrote:
> > Just a couple thoughts to consider. We are looking at 16-20,000
> > airports so we couldn't stuff them all in a single directory. Even
> > splitting them into subdirectories by first letter probably isn't
> >
Julian Foad writes:
> ReiserFS is the default with SUSE 8.1 which I've just installed. Oh yes
> ... hey folks, I've just made the switch from Windows to Linux. Played
> with RedHat and Debian a couple of times in the last few years, but now
> I think it's a permanent switch.
Welcome to
Andy Ross wrote:
> This is a good point, actually. Almost all the Linux filesystems use
> a 4k block as the minimum allocation unit*, and I presume NTFS is
> similar.
I thought it was the other way around: that most Linux filesystems (by
which I mean ext2) and NTFS had 1K or 0.5K blocks, and th
Jon Stockill writes:
> >From a processing point of view this makes sense - you don't need to store
> extra information about the location of the airfields, wher if as was
> suggested before it's broken down by state, then presumably you need to
> store the state for each and every airfield to
Jon Stockill writes:
> Is there any sort of "master" database from which all this can be
> generated? Or should we create one?
No and yes. Note that I'm discussing only the external format, not
the internal format someone might use in a SQL master repository (or
whatever).
That said, these a
Andy Ross writes:
> [* Geeky aside: reiserfs doesn't. It has a unique "tail folding"
>feature where the last sub-block of files gets folded into a single
>block with the tails of other files, so small files take space
>proportional to their actual size. Very cool, although appar
Andy Ross writes:
> Norman wrote:
> > [ ... indexing scheme involving spacial partitions and trees ... ]
> >
> > With such a scheme we should be able to access any airport and
> > determine which airports are within some sane distance in much
> > less then a few tenths of a second < order of mani
Norman wrote:
> [ ... indexing scheme involving spacial partitions and trees ... ]
>
> With such a scheme we should be able to access any airport and
> determine which airports are within some sane distance in much
> less then a few tenths of a second < order of manitude less at least
True, but p
On Thu, 10 Oct 2002, Andy Ross wrote:
> And remember, we can split on the first two bytes ("K/S/KSFO.xml")
> without any more difficulty (one extra line of code) and the whole
> problem goes away.
>From a processing point of view this makes sense - you don't need to store
extra information about
On Thu, 10 Oct 2002, David Luff wrote:
> I personally much prefer the second (embedded example). There's also
> taxiway data needed as well - the thing could get *very* big by the time
> its finished.
Is there any sort of "master" database from which all this can be
generated? Or should we crea
Andy Ross
> Curtis L. Olson wrote:
> > Just a couple thoughts to consider. We are looking at 16-20,000
> > airports so we couldn't stuff them all in a single directory. Even
> > splitting them into subdirectories by first letter probably isn't
> > enough.
>
> There are 17073 airports in the cu
Curtis L. Olson wrote:
> Just a couple thoughts to consider. We are looking at 16-20,000
> airports so we couldn't stuff them all in a single directory. Even
> splitting them into subdirectories by first letter probably isn't
> enough.
There are 17073 airports in the current database. Splittin
Curtis L. Olson writes:
> Just a couple thoughts to consider. We are looking at 16-20,000
> airports so we couldn't stuff them all in a single directory. Even
> splitting them into subdirectories by first letter probably isn't
> enough. Also, consider that with zillions of tiny files, much
David Luff writes:
> I personally much prefer the second (embedded example). There's also
> taxiway data needed as well - the thing could get *very* big by the time
> its finished.
Right. We'll probably want to split it into several files, possibly
with an index as Alex and Andy have sugges
Just a couple thoughts to consider. We are looking at 16-20,000
airports so we couldn't stuff them all in a single directory. Even
splitting them into subdirectories by first letter probably isn't
enough. Also, consider that with zillions of tiny files, much space
is wasted on the file system w
David Megginson wrote:
> Alex Perry writes:
> > Why can't we stick it into the scenery directories, but one directory
> > up from the tiles, so we have one file per 10degx10deg of planet.
> > That should ensure that FGFS doesn't need to load all that many files,
> > and just having the one file in
On 10/10/02 at 1:59 PM David Megginson wrote:
>I've been pulling information out of the DAFIF in different shapes and
>trying to decide how we should model our own airport database. For
>the external representation, we want something flexible enough that we
>can add new types of data easily -- f
Alex Perry writes:
> Why can't we stick it into the scenery directories, but one directory
> up from the tiles, so we have one file per 10degx10deg of planet.
> That should ensure that FGFS doesn't need to load all that many files,
> and just having the one file in the base package will allow
Why can't we stick it into the scenery directories, but one directory
up from the tiles, so we have one file per 10degx10deg of planet.
That should ensure that FGFS doesn't need to load all that many files,
and just having the one file in the base package will allow initial use.
> I've been pulli
I've been pulling information out of the DAFIF in different shapes and
trying to decide how we should model our own airport database. For
the external representation, we want something flexible enough that we
can add new types of data easily -- fixed-length records with
fixed-width fields just do
33 matches
Mail list logo
