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 performance really isn't the goal here.  The existing
metakit stuff performs great.  It's problem is that it's essentially
unmaintainable without regenerating a megabyte of data*.  Replacing
one complicated binary data structure with another really doesn't
address that need.

My point was that a really simple one-file-per-airport scheme (you
basically can't get any more maintainable than that) would work with
adequate performance for typical usage.  The airports in the current
tile set could be kept in memory easily; arbitrary airports could be
looked up quickly (under the UI definition of "quick") by their ID;
and the set of all airports would still be trivially searchable in a
linear walk (looking for a match by name, for example) for cases where
that capability was needed.

Andy

* Well, and that it involves a 3rd party C++ library that insists on
  installing itself as a shared library.  My guess is that metakit
  version skew is the single biggest FAQable problem with new
  developers.  It's a very real, very significant barrier to people
  who want to run the cool new stuff in CVS.  This is my peeve,
  anyway.

-- 
Andrew J. Ross                NextBus Information Systems
Senior Software Engineer      Emeryville, CA
[EMAIL PROTECTED]              http://www.nextbus.com
"Men go crazy in conflagrations.  They only get better one by one."
 - Sting (misquoted)


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to