Jim Wilson writes: > > Norman Vine <[EMAIL PROTECTED]> said: > > > David Megginson writes: > > > > > > Julian Foad writes: > > > > > > > It seems *awfully* redundant given that there is already the Id > > > > *and* the geographical location. > > > > > > The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, > > > but it would get very expensive if we had to store polygons for all > > > country and region boundaries and do point-inside tests for every > > > airport. On balance, I think that this is a reasonable optimization. > > > > I hope that this data base is stored in XYZ form and not lat lon > > else any optimizations you make by spatial partitioning will be > > nullified by the trig calls required to get distances > > If changing the format, another consideration would be anything that might > help the implementation of modern flight system emulation. I'm thinking about > "get nearest airport", "list nearby airports with runways over x ft/m length", > etc. For some reason I was thinking that lat+lon would be easier for that > sort of function.
Any ordering by distance is *exactly* the computation that you *don't* want todo in lat lon space as this is a trivial sgDistanceSquared() call in XYZ Cheers Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
