Pigeon,
Glad to hear you're working on a v3 update. Let me know what's required
and when you have something ready. I'd be more than happy to put the map
up on my server.
cheers,
Rob
On Sat, May 25, 2013 at 9:44 PM, Pigeon wrote:
>
> > I guess no one is maintain the mpmap anymore..
> >
> >
> I guess no one is maintain the mpmap anymore..
>
> and I had a good look a pigeons code..
>
> and it runs perl and google maps v2..
>
> so google maps v3 is outta the question )too complicated to drop in)
> but also also been playing with osm
>
> So is there a plan to move forward with mpmap
On Wed, 2012-05-16 at 01:31 +0100, Peter Morgan wrote:
> I think maybe we need to also invite the fgms team into this discussion
>
> The only way really to get a position sat on webserver atmo
> is to poll a fgms telnet server.. upon its admin port..
>
> eg telnet
> telnet mpserver01.flightgear.o
I think maybe we need to also invite the fgms team into this discussion
The only way really to get a position sat on webserver atmo
is to poll a fgms telnet server.. upon its admin port..
eg telnet
telnet mpserver01.flightgear.org 5001
return lines..
which are then "parsed" into various formats..
On Wed, May 16, 2012 at 12:15 AM, Curtis Olson wrote:
> Locally I've been playing around with open layers a bit. Also web sockets.
> The idea that I think would be interesting to try would be to build a
> websocket interface into flightgear, then serve out the map data locally
> rather than from
Locally I've been playing around with open layers a bit. Also web
sockets. The idea that I think would be interesting to try would be to
build a websocket interface into flightgear, then serve out the map data
locally rather than from a server.
Essentially if you are running FlightGear with MP t
I guess no one is maintain the mpmap anymore..
and I had a good look a pigeons code..
and it runs perl and google maps v2..
so google maps v3 is outta the question )too complicated to drop in)
but also also been playing with osm
So is there a plan to move forward with mpmap.. ?
I have clear id
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
21 matches
Mail list logo
