Re: [Flightgear-devel] FGPositioned refactoring
James Turner wrote: > I'd quite like to move forwards on this tonight, but I'd appreciate a > bit more assent or criticism before I get too much further into the > code. I'd say, if people don't care about responding for several days, they loose their qualification to criticize afterwards well, some might still try to apply criticism but I'd then count this as 'unqualified' So, if I were you and you think your design proposal is really well thought out, then I'd simply put your favorite heat protective suit on and go ahead :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
On 16 Aug 2008, at 03:10, James Turner wrote: > I'm planning to do a slightly intensive re-factoring - creating a > base class where one didn't exist before. The (draft) base class is > attached - it will become a base for the following: I'd quite like to move forwards on this tonight, but I'd appreciate a bit more assent or criticism before I get too much further into the code. People have raised some objections to parts of the idea, and I've responded - I'd be be happy with some 'okay, that satisfies my objections' or 'no, that's not a good enough reason' replies, so I can move forward with the problems I want to solve, or come up with some more-acceptable alternative. Regards, 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
On 17 Aug 2008, at 16:44, James Turner wrote: > Well, there's a motive here: because I'm using consecutive numbers for > the types, I can implement things like 'all airports' or 'all ATC > frequencies' as range compares, by doing lower_bound and upper_bound > queries against appropriate sets and multipmaps. This scheme doesn't > work perfectly for every kind of type-based query, but it handles a > lot of cases pretty well - right now we tend to want everything of a > certain type (airports is the classic example) or just one specific > type. Another thing - there's a couple of 'derived' types that don't need to be C++ subclasses - namely FGFix and currently not-extant (but soon) FGUserWaypoint. Both of these can exist soley has FGPositioned directly, with the type identifier, I think. Not that there's any problem with making an 'empty' derived class of course - but equally it's not necessary. 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
On 16 Aug 2008, at 23:29, Tim Moore wrote:
> I don't find this use of type enums in a base class to be clean at
> all. I have
> nothing against having a type field in a base, but with an enum
> approach the
> base has to have knowledge of all the derived classes, and any time
> you add a
> new one the base has to be modified. I'd prefer to see here a
> singleton type
> object defined in each derived class that compared to in order to
> find the type.
Well, there's a motive here: because I'm using consecutive numbers for
the types, I can implement things like 'all airports' or 'all ATC
frequencies' as range compares, by doing lower_bound and upper_bound
queries against appropriate sets and multipmaps. This scheme doesn't
work perfectly for every kind of type-based query, but it handles a
lot of cases pretty well - right now we tend to want everything of a
certain type (airports is the classic example) or just one specific
type.
Equally, the enum doesn't have to live inside the type - the base
class doesn't really do anything with them, they could just be ints,
so I'd be fine with individual derived classes just claiming chunks of
the numbering space. But being able to write switch statements on type
code, or range-checks (if type >= FOO and type <= FOO2), especially in
a FMS / GPS / flightplan context is very handy.
> Also, your search member functions don't seem to belong to
> "FGPositioned," but
> to the index that stores these things.
Well, that's a personal style thing - my preference is for indexes to
be internal to the class of things they index, i.e implements as class
or file statics. I certainly want to get rid of the 'list' classes
from globals (I have a dream of a future without globals.hxx at all,
but that will take years). I don't think there's a huge difference
between
class FGAirport
{
}
class FGAirportList
{
public:
static FGAirportList* instance(); // or globals->get_airport_list(),
whatever
FGAirport* findByBlah();
}
and
class FGAirport
{
public:
static FGAirport* findByBlah()
}
Semantically, I like the second because at a call site, you can see
that you're dealing with FGAirport - it makes the find method 'self-
naming', but this is very much a personal taste issue.
> Finally, in my own code I've been using the simgear and flightgear
> namespaces
> instead of the SG and FG prefixes, but I won't force anyone else to
> do that :)
I must say a 'flightgear' namespace seems a bit pointless to me, since
FlightGear isn't a library, but by that argument the FG prefix is also
pointless. I'd happily drop it, or use a flightgear namespace if
people felt that was a better approach.
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
James Turner wrote: > 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. I don't find this use of type enums in a base class to be clean at all. I have nothing against having a type field in a base, but with an enum approach the base has to have knowledge of all the derived classes, and any time you add a new one the base has to be modified. I'd prefer to see here a singleton type object defined in each derived class that compared to in order to find the type. Also, your search member functions don't seem to belong to "FGPositioned," but to the index that stores these things. Finally, in my own code I've been using the simgear and flightgear namespaces instead of the SG and FG prefixes, but I won't force anyone else to do that :) Tim - 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
On 16 Aug 2008, at 11:37, Melchior FRANZ wrote: ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/SGHTMMap-20060223/SGHTMMap-first-take.diff Mathias will know more about it. :-) Gave this a quick eyeball and it seems pretty nice - and straightforward to integrate with my proposed base class. So, yes, to re-iterate, spatial indexes good, but what I care about right now is the unified API to talk about such 'things', and make the spatial- and non-spatial queries. If this is added to Simgear, I'd definitely use instead of my SGBucket-hash based approach. I\d be happy to test Mathias' code more closely, and test integrate it with my local tree, where I'm already experimenting with FGPositioned to verify the work involved is approximately consistent with my guesstimates - so far it seems to be. And to re-iterate something else - 'FGPositioned' is an awful name, I'd love a better alternative. FGLocated? yuck. 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
* Thomas Förster -- Saturday 16 August 2008: > As far as I know, Mathias Fröhlich has written a general > templated spatial index for simgear. ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/SGHTMMap-20060223/SGHTMMap-first-take.diff Mathias will know more about it. :-) m. - 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.n
Re: [Flightgear-devel] FGPositioned refactoring
James, 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!!!) 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). 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... Thomas - 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGPositioned refactoring
I'm planning to do a slightly intensive re-factoring - creating a base class where one didn't exist before. The (draft) base class is attached - it will become a base for the following: FGAirport FGRunway FGFix FGNavRecord ATCData The members are pretty uncontroversial, I think. What I'll do is keep the 'old' accessors / members on each derived class, to avoid a massive diff, and clean them up in separate, boring patches. Once the base class is in, and nothing is broken, I'll proceed as follows: - make FGFix, FGRunway and ATCdata be 'pointery', so all these things are living on the heap and do proper virtual calls. I'll actually make them SGReferenced I hope, but I need to see how much more work that will be. (FGNavRecord is already an SGReferenced, for example) - create a centralised, SGBucket-based spatial index of the whole lot, with some query methods: static FGPositionedList FGPositioned::findWithinRangeOfLocation(double lat, double lon, double rangeNm); static FGPositionedList FGPositioned::findWithIdent() static FGPositionedList FGPositioned::findClosestWithIdent() (and of course some variants / overloads to filter by type. I need to check about overloading statics, but ideally FGNavRecord::findWithinRangeOfLocation would be overloaded to only return navaids, etc, etc). - gradually simplify or kill off the various FGblahList classes in favour of unified queries on this (i.e clean up the call sites). This includes removing the 'poor mans' spatial index in navlist, the total *absence* of a spatial DB in airports, the SGBucket-based one in commlist.cxx. At the same time I'd let the derived classes keep their specialised indices and query methods - eg airport idents are unique, navaids and ATCDatas can be indexed by frequency, and so on. (this last step will take some time :) The motivation for this is of course being able to build my NAV display, but it's also the starting point for working on improving the airways code and creating a standard FGFlightPlan class - an airway or flightplan is essentially built out of FGPositioned objects, tagged with some extra data. And indeed that's what Dave Luff's GPS code looks like - just using its own internal waypoint and flightplan classes for these jobs, which is one of the many things I hope to improve. Incidentally, the unified 'type' enum will replace several existing type fields - the FGAirport type member, the FGRunway taxiway flag, the FGNavRecord type, and the ATCData type. There's also scope to add more - I've optimistically included an 'OBSTACLE' type, for example, on the hope that I can add find an existing obstacle DB to import. In any case, adding types is cheap. Comments on, or objections to, this plan, would be greatly appreciated. Note I hate the name 'FGPositioned' but can't think of a better name that accurately reflects what the class does. I'll buy a beer/beer-substitute for anyone who comes up with a shorter, more meaningful class name. Cheers, James positioned.hxx Description: Binary data - 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
