On 16 Aug 2008, at 09:50, Thomas Förster wrote: > while I'm pretty much in favour of spatial indices, note that a lot > of work in > that direction has been done already. As far as I know, Mathias > Fröhlich has > written a general templated spatial index for simgear. I've the code > with me, > but haven't found time to look at it yet (Sorry Mathias, PhD becomes > more and > more demanding). > > Using that, it is not necessary to create a new base class (and new > intermodule dependencies, where would FGPositioned be placed?). It > suffices > to implement the required interface (i.e. a few methods) in a class > to make > it usable with that template based index. The static methods can be > placed in > the index too. The signature will be only slightly bigger with one > additional > argument (the "FGPositioned"s position!!!)
Hmm, okay, some slight confusion here I think. While I've proposed this API to help with spatial lookups, it's not the world's greatest spatial implementation - an R-tree or something would be better. What it does aim to do is collect all the different 'find' 'search' and 'query' methods on the FXblahList classes, which are all rather ambiguously named, and overloaded on different sets of pos / distance / ident / frequency / heading / etc. However, the main this is I need to be able to treat a group of these things homogeneously, to get rid of code that currently has to do: given an ident A: - search the airports list - search the navaids list - search the fix list I want to add user waypoints, which would be another case, and for the NAV display, I want to do a spatial query (all within 160nm, let's say) of this nature - the existing call sites that look like this are doing it by ident. (Oh and obstacles, which is another case, and in theory we could show WX-radar-lightning strikes the same way, although I'd probably use a different spatial index scheme internally for movable objects ... hmmm .... actually this could the also support a TCAS displays by having an FGMoveablePositioned entry for each multiplayer and AI plane) Once the abstraction is in place, I'd be delighted to use whatever spatial implementation anyone can propose, mine is just the simplest one I know will work 'well enough'. It's much easier to try different spatial solutions when all the users are collected together. So, I actively *want* the base class. It allows replacing various 'type-testing' code with a single unified enum, which cleans up various other places - right now there's code that is looking at FGNavRecord's type directly (which is a integer code from Robin's DB), we have a string type on airport, plus a 'fg_nav_type' on the navrecords and yet another GPSWaypointType in the KLN-89b. Oh, and unifying the name index also allows me to handle a problem I've encountered cleaning up the KLN-89b code, namely that it uses a different string ordering from ASCII (letters before numbers instead of after). I've written a STL comparator which implements this ordering, and patched the code to use it, but unifying the 'findFirstWithIdent' rules which got added to the various list classes would make dealing with this much simpler. (Incidentally, is this 'letters before numbers' string ordering standard in the aviation world? There was already a comment about something similar next to one of the many 'search' methods) > Note that it is not possible with your interface to find the > nearest "FGPositioned" to an arbitrary geodetic position yet. This is > somewhat critical (e.g. finding things based on the user aircraft). > This is my fault for causing confusion, see below. > Additional methods I'd like to see is an extension of the nearest > neighbor > query to N-nearest neighbors. Examples might be finding the 3(or 5) > nearest > metar stations for weather interpolation, 5 nearest fixes to an > airport for > rough route planning... I'm planning to do methods like the above, I just didn't bother to show them in my sample file - absolutely I do need them, and intend to support them. Once I have the SGBucket-based index, they're simple to implement, and again, once the abstraction is there, changing the underlying spatial index is easy. Sorry, I should have said the list of 'find' methods wasn't supposed to be exhaustive - just to point out 'some spatial queries go here, and non-spatial ones too, go here' James ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
