Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote: If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? This is a good discussion to start. I'm inclined to eliminate tying altogether and have every module set properties explicitly; what does everyone else think? Couldn't agree more, but I think this is likely to be unpopular. We can keep tying if we have an efficient 'notifyTiedValueChanged' method, which should be a no-op if there are no change-listeners registered on the property, and otherwise should run through them. Tony Peden wrote, I'd really like to see tying stay in. I'm not sure we ever would have incorporated the property tree into JSBSim without it. I don't understand why xPosNode.setFloatValue( x ) is so much worse than my_tied_xPos_float = apart from being a bit verbose. And the advantage is, it forces you to appreciate (when you do the set) that some extra working is going to get done (listeners being invoked for now, who knows what else in the future) Jim Wilson wrote, Ummm...it's not polling, it's just updating the data. Same as many of the subsystems do every frame. Polling is a contious loop that waits for something to happen. Like I said, if we're not displaying the prop_picker then it should not be updated. Well, I take polling to mean, going and looking at a value over and over again (one 'look' per frame). That works fine, and I'm *not* trying to argue an efficiency point (sorry if my original email came across that way, since that's how most people seem to have taken it). It's an issue of dataflow in the program : should it be driven by the people updating the values, or by people reading them? Basically, I can envisage lots of things the ChangeListener API is perfect for, whether you're observing a value that changes one a week or 50 times a second, but right now those things won't work because some % of the properties don't tell you they've changed. Now, we could always flag some properties as 'immediate' I suppose, but that seems like a hack. There's nothing wrong with the current API, we just ought to make all the property nodes meet the contract it defines, or we need to remove change listeners from the API and have everyone poll / update as you suggest. HH James -- That which does not kill me has poor aim
Re: [Flightgear-devel] Live property picker
James Turner wrote: Basically, I can envisage lots of things the ChangeListener API is perfect for, whether you're observing a value that changes one a week or 50 times a second, but right now those things won't work because some % of the properties don't tell you they've changed. Now, we could always flag some properties as 'immediate' I suppose, but that seems like a hack. There's nothing wrong with the current API, we just ought to make all the property nodes meet the contract it defines, or we need to remove change listeners from the API and have everyone poll / update as you suggest. Aren't the C++ opperators the perfect place to add this kind of action to tied properties? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
Erik Hofman wrote :
James Turner wrote:
Basically, I can envisage lots of things the ChangeListener API is
perfect for, whether you're observing a value that changes one a week or
50 times a second, but right now those things won't work because some %
of the properties don't tell you they've changed. Now, we could always
flag some properties as 'immediate' I suppose, but that seems like a
hack. There's nothing wrong with the current API, we just ought to make
all the property nodes meet the contract it defines, or we need to
remove change listeners from the API and have everyone poll / update as
you suggest.
Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?
I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :
template class T
class tied_value
{
public:
tied_value() : node( 0 ) {}
~tied_value() : { untie(); }
tie( SGPropertyNode_ptr n ) { node = n; n-tie( val ); }
untie() { node = 0; n-untie( val ); }
T operator=( const T v ) { val = v; if (node) node-fireChangeListeners(); return
*this; }
operator T() { return val; }
private:
T val;
SGPropertyNode_ptr node;
}
Then replace every tied values with that template :
change :
double xPos;
into :
tied_valuedouble xPos;
You get the picture ?
One can use xPos as usual and when the data is changed, listeners are advertised.
( disclaimer : all the above is written from memory and is presumably
incomplete )
Cheers,
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 10:16 am, Frederic BOUVIER wrote:
Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?
I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :
template class T
class tied_value
{
snip quite reasonable template idea
}
Then replace every tied values with that template :
change :
double xPos;
into :
tied_valuedouble xPos;
You get the picture ?
I do, but this is not the problem (as I understand it). The tie-ing
system is 'low-invasion' for existing code / code which may not be part
of FG, and works well with existing state variables. Your template /
operator overloading fix the syntax, but I sort of think that's worse,
because people may not realize what they're doing will be more
expensive than assigning to a double. But the main problem is people
now need to pull in your template and the property node headers into
places they don't want to.
The impression I have is that a bunch of code uses 'tieing' to expose
lots of internal variables directly. I'd prefer an explicit
'publishing' phase, i.e calls to setValue. Of course your template
works fine too, if you're prefer the syntactic sugar.
HH
James
--
That which does not kill me has poor aim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner wrote : The impression I have is that a bunch of code uses 'tieing' to expose lots of internal variables directly. I'd prefer an explicit 'publishing' phase, i.e calls to setValue. Of course your template works fine too, if you're prefer the syntactic sugar. I see your (rather dogmatic) point but I also see here people that are not prepared to follow you. My main point is that if there is an interface, it is supposed to work in all cases and my solution address this point. The SGPropertyNode interface can also be change to forbid tying from outside the template to enforce the rule. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem
These errors are fixed in the latest CVS - change typedef list TowerPlaneRec* tower_plane_rec_list_type; typedef list TowerPlaneRec* ::iterator tower_plane_rec_list_iterator; typedef list TowerPlaneRec* ::const_iterator tower_plane_rec_list_const_iterator; to typedef list TowerPlaneRec* tower_plane_rec_list_type; typedef tower_plane_rec_list_type::iterator tower_plane_rec_list_iterator; typedef tower_plane_rec_list_type::const_iterator tower_plane_rec_list_const_iterator; and do likewise for the error in ATCVoice.cxx *Please* specify compiler, platform and Flightgear code version when submitting bugs! Cheers - Dave On 2/6/03 at 2:36 AM [EMAIL PROTECTED] wrote: typedef list TowerPlaneRec* ::iterator tower_plane_rec_list_iterator; /// c:\hh\flightgear\091\flightgear-0.9.1\src\atc\tower.hxx(72) : error C2653: 'listclass TowerPlaneRec *,class std::allocatorclass TowerPlaneRec * ' : is not a class or namespace name /// why?how to resolve it? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner wrote : I do, but this is not the problem (as I understand it). The tie-ing system is 'low-invasion' for existing code / code which may not be part of FG, and works well with existing state variables. Your template / operator overloading fix the syntax, but I sort of think that's worse, because people may not realize what they're doing will be more expensive than assigning to a double. But the main problem is people now need to pull in your template and the property node headers into places they don't want to. The impression I have is that a bunch of code uses 'tieing' to expose lots of internal variables directly. I'd prefer an explicit 'publishing' phase, i.e calls to setValue. Of course your template works fine too, if you're prefer the syntactic sugar. Frederic BOUVIER wrote : I see your (rather dogmatic) point but I also see here people that are not prepared to follow you. My main point is that if there is an interface, it is supposed to work in all cases and my solution address this point. I realized I may have been more rude than I wanted to be. But I don't think there is a huge penalty here. Classes that are doing tying now must store the SGPropertyNode as a separated pointer for tying and untying. By rewriting the template a little bit, the pointer can be stored only in the template. People that are using tying are JSBsim people and they want their code works standalone. An alternate template without the property connection can do this with no additionnal cost because functions are short and inlined. I don't consider sugar concise syntax that enforce a rule. Look at the SGPropertyNode_ptr class. There are also operator overloading that are counting reference. You could consider it sugar but do you really prefer to increment or decrement values in the code for the sake of seeing what the code is doing. One another benefit of the template/class approach is that the destructor ensure the call to the untie method. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thu, 2003-02-06 at 01:09, James Turner wrote: On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote: excerptexcerptIf so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? /excerpt This is a good discussion to start. I'm inclined to eliminate tying altogether and have every module set properties explicitly; what does everyone else think? /excerpt Couldn't agree more, but I think this is likely to be unpopular. We can keep tying if we have an efficient 'notifyTiedValueChanged' method, which should be a no-op if there are no change-listeners registered on the property, and otherwise should run through them. Tony Peden wrote, excerptI'd really like to see tying stay in. I'm not sure we ever would have incorporated the property tree into JSBSim without it.colorparam,6363,1212/param /color/excerpt I don't understand why The memory vs. cpu cycles trade is appealing to me. For the cost of storing the function pointers needed to make tying work, we get a system that only consumes CPU cycles when a property is actually accessed. The only alternative I see for us(and please tell me if there's something I'm missing) is an explicit copy every frame. In the case of the FG property browser, you may be able to limit the explicit copying to when the property browser is shown, but there is no such opportunity with JSBSim. xPosNode.setFloatValue( x ) is so much worse than my_tied_xPos_float = apart from being a bit verbose. And the advantage is, it forces you to appreciate (when you do the set) that some extra working is going to get done (listeners being invoked for now, who knows what else in the future) Jim Wilson wrote, excerptUmmm...it's not polling, it's just updating the data. Same as many of the subsystems do every frame. Polling is a contious loop that waits for something to happen. Like I said, if we're not displaying the prop_picker then it should not be updated.colorparam,6363,1212/param /color/excerpt Well, I take polling to mean, going and looking at a value over and over again (one 'look' per frame). That works fine, and I'm *not* trying to argue an efficiency point (sorry if my original email came across that way, since that's how most people seem to have taken it). It's an issue of dataflow in the program : should it be driven by the people updating the values, or by people reading them? Basically, I can envisage lots of things the ChangeListener API is perfect for, whether you're observing a value that changes one a week or 50 times a second, but right now those things won't work because some % of the properties don't tell you they've changed. Now, we could always flag some properties as 'immediate' I suppose, but that seems like a hack. There's nothing wrong with the current API, we just ought to make all the property nodes meet the contract it defines, or we need to remove change listeners from the API and have everyone poll / update as you suggest. HH James -- That which does not kill me has poor aim -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
Tony Peden writes: This is a good discussion to start. I'm inclined to eliminate tying altogether and have every module set properties explicitly; what does everyone else think? I'd really like to see tying stay in. I'm not sure we ever would have incorporated the property tree into JSBSim without it. In that case, if we want change events to work, we'll have to do one of the following: 1. Require every module that ties a property to fire an update event whenever the value changes; or 2. Poll tied properties with change listeners attached inside the property system and fire the events when appropriate. I'd be include towards #2, since it would centralize the polling and do it only when actually needed. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
Frederic BOUVIER writes: But I don't think there is a huge penalty here. Classes that are doing tying now must store the SGPropertyNode as a separated pointer for tying and untying. They don't, actually -- the property manager takes care of storing the node. You just do something like fgTie(/foo/bar, this, Foo:getBar, Foo:setBar); at the start, and fgUntie(/foo/bar); and the end, and for the rest of the time you can pretend the property system doesn't exist. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Live property picker
1. Require every module that ties a property to fire an update event whenever the value changes; or 2. Poll tied properties with change listeners attached inside the property system and fire the events when appropriate. I'd be include towards #2, since it would centralize the polling and do it only when actually needed. I'm not really tuned into this discussion at the moment, but I will say it's giving me indigestion just reading this stuff. Let me add that in JSBSim (and for that matter probably any FDM) just offhand I'd say that almost all of our properties will be changing every single frame. Aircraft state and EOM are dynamic things. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Live property picker
Jon Berndt writes: Let me add that in JSBSim (and for that matter probably any FDM) just offhand I'd say that almost all of our properties will be changing every single frame. Aircraft state and EOM are dynamic things. I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] forwarded message from Jim Wilson
I just committed Jim's changes to CVS. This means you'll need to update both the base package cvs and flightgear cvs to stay in sync. ---BeginMessage--- embarrassing-note Let me try again. This time I'll remember the file links and one other change that I made added to the list. :-) /embarrassing-note Hi David and Curt, There are a number of little changes. Tested with current cvs as of 20:30EST 04Feb. Actually been running since the beginning of January with these patches. All changes work without crashing with the current base package cvs, but there are some visual problems with the views (other than pilot view) without changes to the base package. As soon as you can build test and commit I can add in those base package updates that will make it all work nicely. I will also go through all the 3D Aircraft configs to make sure the change in the pitch-offset for cockpit views (see below) are made to maintain current behavior. Here are the files (changes listed below): http://www.spiderbark.com/fgfs/viewerupdate.diffs.gz http://www.spiderbark.com/fgfs/viewerupdate.tar.gz Best, Jim FIXED: The viewer code has a bug in it that screws up the pitch offsets in chase view. This is the offset angle that is typically controlled by the mouse or the hat switch (up or down angle). If you go to chase view and then use the mouse to move the view angle up, and then fly around you'll see what I mean. Added a new set of parameters to the viewer interface. They are called Target offsets (x, y, and z) and work in the Look At views, where there is a target view location, e.g. Chase View. The new offsets will allow the model designer to offset the view origin to midship (or whereever) in order to eliminate unpleasent optical effects as the aircraft rolls and pitches. Roll, Pitch and Heading Offsets are now processed by the view manager like all the other parameters. (Duh) Interface updated accordingly. Certain view configuration data is now copied to a subpath of current-view called config so that property manipulation can be used to reset the view to an original position without knowing which view is the current one. This improves on some recent attempts to accomplish this by introducing duplicate default property entries. Views can be selected by simply modifying the property /sim/current-view/view-number. This has been used to bind the uppercase V key to return to view number 0 (the cockpit). Of course it could also be used for menu selections, etc. Renamed several private functions in viewmgr class (no effect outside viewmgr) so that they are consistant with names used in the viewmgr and viewer interfaces. This is really just a code documentation improvement. On RESET a call is made to viewmgr::reinit() so that viewer settings can be restored to their original state including returning to the cockpit view. This seems to make sense and it does away with some persistant gotchas that have cropped up here and there. ---End Message--- Curt. -- 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] OT: 100 Hours
I passed 100 hours total flying time today, while practicing holds and approaches under the hood in C-FBJO. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: 100 Hours
Wow! Not bad for...what is it? 8 months since you started? Best, Jim David Megginson [EMAIL PROTECTED] said: I passed 100 hours total flying time today, while practicing holds and approaches under the hood in C-FBJO. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: 100 Hours
On Thu, 6 Feb 2003 18:43:43 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I passed 100 hours total flying time today, while practicing holds and approaches under the hood in C-FBJO. ..yehaa! :-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
I couldn't find any good info on what kind of map projection technique to use for the ND. ie. mapping lat/lon to x/y-screen coord. I took a look at the OpenGC source, and as far as I understand, it uses a technique which converts RijksDriehoeks to Hayford. I tried to google a bit on this, but couldn't find much. Basically, RijksDriehoeks seems to be a technique developed specifically for the Netherlands... Did a little more research... (blindly shooting some search requests at google) Something that came up was, the Lambert Conformal Conic Projection. I also had the chance to ask a real airliner pilot. He said that on A340 and B744, a line on the NDs represents the shortest path between two points, ie. a Great Circle route. He also said that on older NDs (A300 or A310, I forgot which he mentioned) the line is not a Great Circle Route. So, could the Lambert Conformal Conic be the projection I am looking for ? Any help or pointers are appreciated. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: 100 Hours
Jim Wilson writes: Wow! Not bad for...what is it? 8 months since you started? Give or take. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
Manuel Bessler I also had the chance to ask a real airliner pilot. He said that on A340 and B744, a line on the NDs represents the shortest path between two points, ie. a Great Circle route. He also said that on older NDs (A300 or A310, I forgot which he mentioned) the line is not a Great Circle Route. So, could the Lambert Conformal Conic be the projection I am looking for ? Any help or pointers are appreciated. google(map projections great circle straight line) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Does SGRoute.distance_off_route() work?
Hello everyone- I was just wondering if the subroutine SGRoute.distance_off_route() calculates accurate results (or even reasonably usable results for navigation in fgfs) for waypoints on a wgs84 system. I've run some tests and it seems okay, but I'm no expert - can someone verify this? Also, what units does it return? I measured two distances, two line segments a and b, forming one line perpendicular to line c, and the total distance came to be .03802. Then I used the SGWaypoint routines to calculate the actual length of line a+b and got 1.92609NM or 3567.11 meters. This makes me suspect that either distance_off_route() is using some strange (large) units, or else it just isn't working correctly. The code says that it assumes that all points are lying on a flat plane, and that it works best with a cartesian system. Thanks, John Gallas __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does SGRoute.distance_off_route() work?
John A. Gallas I was just wondering if the subroutine SGRoute.distance_off_route() calculates accurate results (or even reasonably usable results for navigation in fgfs) for waypoints on a wgs84 system. I've run some tests and it seems okay, but I'm no expert - can someone verify this? This is a *much* better approximation http://williams.best.vwh.net/avform.htm#XTE Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
Manuel Bessler writes: Did a little more research... (blindly shooting some search requests at google) Something that came up was, the Lambert Conformal Conic Projection. I also had the chance to ask a real airliner pilot. He said that on A340 and B744, a line on the NDs represents the shortest path between two points, ie. a Great Circle route. He also said that on older NDs (A300 or A310, I forgot which he mentioned) the line is not a Great Circle Route. So, could the Lambert Conformal Conic be the projection I am looking for ? Any help or pointers are appreciated. You might be thinking too hard about this. The following seems to work really slick for me (assuming you are doing smaller area maps or don't care about some distortion as you get towards the top/bottom of the map. Even if this isn't quite good enough for your needs, it will get you out of the gate running and you can come back later and do something fancier. Pick some ($center_lon, $center_lat) to be the center of your map. Then calculate $xfacter = cos( $center_lat * $deg_to_rad ) Now set $h = height in pixels of your display and $w = width in pixels of your display. You also want a $scale variable that is set to the something like number of pixels per nautical mile. Also note that to convert from a degree of latitude to nm, multiply by 60 (i.e. there are 60 nm for every degree of latitude.) Ok, so you have all that? Now if you want to draw something on your map (i.e. a VOR) at some ($lon, $lat) just use the following formula: $x = $w/2 + ($lon - $center_lon) * $deg_to_nm * $scale * $xfact; $y = $h/2 - ($lat - $center_lat) * $deg_to_nm * $scale; ($x, $y) is the coordinates (in screen space) where you should draw the object. This is known to work pretty well over a local area (assuming my typing is correct, I didn't overlook something, and you can get past the pseudo-perl syntax.) :-) Regards, Curt. -- 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] [more or less OT] Map Projection on Navigation Displays
Curtis L. Olson writes: You might be thinking too hard about this. The following seems to work really slick for me (assuming you are doing smaller area maps or don't care about some distortion as you get towards the top/bottom of the map. Even if this isn't quite good enough for your needs, it will get you out of the gate running and you can come back later and do something fancier. Pick some ($center_lon, $center_lat) to be the center of your map. Then calculate $xfacter = cos( $center_lat * $deg_to_rad ) Now set $h = height in pixels of your display and $w = width in pixels of your display. You also want a $scale variable that is set to the something like number of pixels per nautical mile. Also note that to convert from a degree of latitude to nm, multiply by 60 (i.e. there are 60 nm for every degree of latitude.) Ok, so you have all that? Now if you want to draw something on your map (i.e. a VOR) at some ($lon, $lat) just use the following formula: $x = $w/2 + ($lon - $center_lon) * $deg_to_nm * $scale * $xfact; $y = $h/2 - ($lat - $center_lat) * $deg_to_nm * $scale; ($x, $y) is the coordinates (in screen space) where you should draw the object. This is known to work pretty well over a local area (assuming my typing is correct, I didn't overlook something, and you can get past the pseudo-perl syntax.) :-) This works fine for a 'map' but straight lines will not be great circles which AFAIK is still the standard for *most* aviation 'charts', both paper and electronic versions Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does SGRoute.distance_off_route() work?
John A. Gallas writes: Hello everyone- I was just wondering if the subroutine SGRoute.distance_off_route() calculates accurate results (or even reasonably usable results for navigation in fgfs) for waypoints on a wgs84 system. I've run some tests and it seems okay, but I'm no expert - can someone verify this? Also, what units does it return? I measured two distances, two line segments a and b, forming one line perpendicular to line c, and the total distance came to be .03802. Then I used the SGWaypoint routines to calculate the actual length of line a+b and got 1.92609NM or 3567.11 meters. This makes me suspect that either distance_off_route() is using some strange (large) units, or else it just isn't working correctly. The code says that it assumes that all points are lying on a flat plane, and that it works best with a cartesian system. I don't know if that code is well tested ... it ought to work though. :-) It probably returns distance in meters if I had any sense about me when I wrote it. If you send me a simple test program I'll see if I can find some time to take a look. Regards, Curt. -- 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] [more or less OT] Map Projection on Navigation Displays
Norman Vine writes: This works fine for a 'map' but straight lines will not be great circles which AFAIK is still the standard for *most* aviation 'charts', both paper and electronic versions Fair enough ... I guess it all depends on the needs of the end application. It's about as simple as you can get though and it will get you out of the gate so you can work on making pretty pictures. Once you have something working you could come back and do a fancier projection. Regards, Curt. -- 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
