Re: [Flightgear-devel] FGNavList searching
On Saturday, January 25, 2003, at 09:55 pm, Curtis L. Olson wrote: I made some changes to the FGNavList class, take a look and see if it will work better for your needs. Thanks, I already saw this and picked it up, it works great! I'd done the research (okay, 2 minutes with grep) to see who the users of the NavList code were, but obviously that hadn't made me realize they were all doing their own range checks. Anyway, thanks again. H&H James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGNavList searching
James, I made some changes to the FGNavList class, take a look and see if it will work better for your needs. Regards, Curt. Curtis L. Olson writes: > I'll take a look ... > > James Turner writes: > > Hey, > > > > I've hit a slight problem trying to use FGNavList::findByIdent, in that > > it's calling onto the helper function findNavFromList, which does VOR > > range calculations to cut-off results. For what I need, I'm perfectly > > happy to deal navaids which are out of range of the supplied position, > > but because of this logic I get back a 'not found'. > > > > So, I think the range-based cut-off logic needs to be factored out and > > either enabled / disabled with an extra boolean argument to findByIdent > > , or (my preferred choice), pushed up to a slightly higher level. I > > really need the Navlist to work like a database, without implicit > > assumptions about the way in which the data is being used (eg for radio > > reception). > > > > So, which approach (or others) is preferable? I'm happy to do up > > patches. > > > > On a related node, FGNavList's internal storage could be made simpler > > if I could switch it to use multimap<> instead of map<>s of vector<>s. > > Are multimaps okay or do they have IRIX / MSVC issues? > > > > H&H > > James > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGNavList searching
I'll take a look ... James Turner writes: > Hey, > > I've hit a slight problem trying to use FGNavList::findByIdent, in that > it's calling onto the helper function findNavFromList, which does VOR > range calculations to cut-off results. For what I need, I'm perfectly > happy to deal navaids which are out of range of the supplied position, > but because of this logic I get back a 'not found'. > > So, I think the range-based cut-off logic needs to be factored out and > either enabled / disabled with an extra boolean argument to findByIdent > , or (my preferred choice), pushed up to a slightly higher level. I > really need the Navlist to work like a database, without implicit > assumptions about the way in which the data is being used (eg for radio > reception). > > So, which approach (or others) is preferable? I'm happy to do up > patches. > > On a related node, FGNavList's internal storage could be made simpler > if I could switch it to use multimap<> instead of map<>s of vector<>s. > Are multimaps okay or do they have IRIX / MSVC issues? > > H&H > James > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGNavList searching
Hey, I've hit a slight problem trying to use FGNavList::findByIdent, in that it's calling onto the helper function findNavFromList, which does VOR range calculations to cut-off results. For what I need, I'm perfectly happy to deal navaids which are out of range of the supplied position, but because of this logic I get back a 'not found'. So, I think the range-based cut-off logic needs to be factored out and either enabled / disabled with an extra boolean argument to findByIdent , or (my preferred choice), pushed up to a slightly higher level. I really need the Navlist to work like a database, without implicit assumptions about the way in which the data is being used (eg for radio reception). So, which approach (or others) is preferable? I'm happy to do up patches. On a related node, FGNavList's internal storage could be made simpler if I could switch it to use multimap<> instead of map<>s of vector<>s. Are multimaps okay or do they have IRIX / MSVC issues? H&H James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
