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 current database. Splitting on first
> letter only, the largest is (no surprise) 'K', with 2161 airports. On
> a lark, I created such a directory containing all the US airports.
> The creation process was relatively slow -- 20 seconds or so. But
> once the files are there, access to them is very fast (a few tenths of
> a second). This was true even after I was careful to flush the buffer
> cache by cat'ing a different disk to /dev/null, if the stuff is in the
> cache, of course, access is milliseconds at most. If you think about
> it, 2000 is about the same number as the number of device files in
> /dev, and no is complaining about performance issues there.
>
> 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.
>
> > Also, consider that with zillions of tiny files, much space
> > is wasted on the file system which hits people in the windows land the
> > hardest it seems because they often have a very large minimum file
> > size.
>
> 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. Still, though, 4k per airport is still a tiny fraction of
> the size of the scenery. Remember that with a file per airport, there
> is no need to have the whole airport database in the base package.
> You can download the airports along with the scenery.
>
> The windows issue is, I think, true only on very old FAT32 variants.
> I'm pretty sure the block size limitation went away at the same time
> the 2G limit did, no? Everything from Win98SE on should be fine, I
> believe. Any windows users want to comment? Certainly anyone running
> XP won't have this problem.
For the Index I reccomend making a single trie on the airport name
that stores the bucket of the actual airport data file which lives in the
same spot as it currently does. Then In each 10x10 degree directory
I propose that we have a KD-tree spatial index of the positions of each
airport in that block. This 2 tiered approach should give lighning fast
lookups to both airport by name and what airports are near by.
The indexes should be binary and we should distribute the tools that
rebuild them when they change which won't be that often nor take
very long. The indexes chould be able to dump themselves as XML
files to facilitate rebuilding them and for easy inspection.
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 >
Regards
Norman
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
