On 04/07/2010 07:06 PM, Peter Brown wrote:
> Perhaps this has been brought up before, but I see that the ILS
> "beam" data for each airport on the mpmap is derived from the runway
> alignment (as verified in taxidraw).
That sounds like a problem.
> This doesn't allow for magnetic
> deviation, a
On Apr 8, 2010, at 5:23 PM, Martin Spott wrote:
>
> If you're in need of a human-readable one-shot database table dump,
> please let me know.
>
> Cheers,
> Martin.
> --
That'd be great, send it my way.
Peter
-
Peter Brown wrote:
> On Apr 8, 2010, at 4:09 PM, Martin Spott wrote:
>> BTW, feel free to use this service if your're looking for slightly more
>> complete airfield data:
>>
>>
>> http://mapserver.flightgear.org/ms?Service=WFS&Version=1.0.0&request=GetFeature&Typename=apt_airfield&MaxFeatures=1
On Apr 8, 2010, at 4:58 PM, David Megginson wrote:
> On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown
> wrote:
>
>> I see. So that brings us back to magnetic vs true, as I was originally
>> referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is
>> sourcing the data from the
On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown wrote:
> I see. So that brings us back to magnetic vs true, as I was originally
> referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is
> sourcing the data from the actual runway placement. My opinion is there
> should be an d
On Apr 8, 2010, at 4:09 PM, Martin Spott wrote:
> Peter Brown wrote:
>
>> I see. So that brings us back to magnetic vs true, as I was
>> originally referring to. But, that's somewhat irrevelant as it
>> _appears_ the mpmap is sourcing the data from the actual runway
>> placement.
>
> or
Martin Spott wrote:
> BTW, feel free to use this service if your're looking for slightly more
> complete airfield data:
>
>
> http://mapserver.flightgear.org/ms?Service=WFS&Version=1.0.0&request=GetFeature&Typename=apt_airfield&MaxFeatures=1&Filter=icaoKBTV
BTW, the figures for magnetic "decli
Peter Brown wrote:
> I see. So that brings us back to magnetic vs true, as I was
> originally referring to. But, that's somewhat irrevelant as it
> _appears_ the mpmap is sourcing the data from the actual runway
> placement.
or from the navaids.
> My opinion is there should be an data fi
On Apr 8, 2010, at 1:29 PM, David Megginson wrote:
> On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown
> wrote:
>
>> David, yes, as I have as well. The localizer for 33 as you listed above is
>> on a 326 heading per the approach plate, but the mpmap shows ILS data as the
>> runway heading in degr
On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown
wrote:
> David, yes, as I have as well. The localizer for 33 as you listed above is
> on a 326 heading per the approach plate, but the mpmap shows ILS data as the
> runway heading in degrees - as if for users to use as the ILS data. I'm not
> sure
On Apr 8, 2010, at 8:08 AM, David Megginson wrote:
> On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown
> wrote:
>
>> Perhaps this has been brought up before, but I see that the ILS "beam" data
>> for each airport on the mpmap is derived from the runway alignment (as
>> verified in taxidraw). This
On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown
wrote:
> Perhaps this has been brought up before, but I see that the ILS "beam" data
> for each airport on the mpmap is derived from the runway alignment (as
> verified in taxidraw). This doesn't allow for magnetic deviation, and
> therefore all th
On 8 Apr 2010, at 03:06, Peter Brown wrote:
> Perhaps this has been brought up before, but I see that the ILS "beam" data
> for each airport on the mpmap is derived from the runway alignment (as
> verified in taxidraw). This doesn't allow for magnetic deviation, and
> therefore all the course
Perhaps this has been brought up before, but I see that the ILS "beam" data for
each airport on the mpmap is derived from the runway alignment (as verified in
taxidraw). This doesn't allow for magnetic deviation, and therefore all the
course headings are incorrect. Makes it tough to line up wi
14 matches
Mail list logo