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
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
> e
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 yo
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 represe
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 th
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, w
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 Grea
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.flight
> 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 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... ;
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
>
___
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]
htt
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.
--- Begin Message ---
Let me try again. This time I'll remember the file links and one other change
that I made added to the list. :-)
Hi David and Curt,
The
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 JSBSi
> 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 po
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
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 proper
On Thu, 2003-02-06 at 01:09, James Turner wrote:
> 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?
>
>
>
>
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 th
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 < TowerPlane
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 (rath
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
cl
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 tel
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 coul
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
altogethe
25 matches
Mail list logo
