Re: [Flightgear-devel] mpmap
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 pig...@pigeond.net wrote: 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 idea what I want to do which is make it osm compatible for a start.. and then take it from there.. So anyone else playing with this idea? anyone else done and development ? where can we share these new ideas as a repo ? Hi, and sorry, I'm a little late. Since google map v2 api is being deprecated, I've been working on a v3 port. It's almost ready for testing. I will also welcome any other alternative that doesn't use google map, since I know some people are more comfortable with other more opened things. Though it is not something that I have been looking at. Meanwhile, a few people has noted that mpmap01 is down. http://www.flightgear.org/forums/viewtopic.php?f=27t=20029 Any ideas? Pigeon. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Rob -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap
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 idea what I want to do which is make it osm compatible for a start.. and then take it from there.. So anyone else playing with this idea? anyone else done and development ? where can we share these new ideas as a repo ? Hi, and sorry, I'm a little late. Since google map v2 api is being deprecated, I've been working on a v3 port. It's almost ready for testing. I will also welcome any other alternative that doesn't use google map, since I know some people are more comfortable with other more opened things. Though it is not something that I have been looking at. Meanwhile, a few people has noted that mpmap01 is down. http://www.flightgear.org/forums/viewtopic.php?f=27t=20029 Any ideas? Pigeon. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 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.org 5001 return lines.. which are then parsed into various formats.. so we need to cover this scenario across anyones installation.. to make it usable.. another thought.. pete Hi Pete, We have discussed this off list, but to repeat some of my ideas, which of course can be 'corrected' by others... 1. I do not think it is good to bash one or each public FG server on their telnet 'admin' port every few seconds, to get current online pilot information... The present fgms code drives a new process (originally a fork(), but now a pthread in later code if configured) into existence to reply to each 'telnet' query... quite a load... 2. I agree and LIKE the idea of a NEW world 'map' of all FG pilots online... that would be GREAT, in addition to the existing 'pigeons code' ;=)) As suggested off list, my idea to achieve this is to host a NEW fgms server... and get all other current FG mp servers to relay packets to it... And that means applying to Curt to get a DNS record - mpserver[NN].flightgear.org... Now this new server would be - (a) serving the FG community, and (b) you can either 'bash' its telnet port, it is your server to treat as you like ;=)) or (c) as provided in the fgms code, connect another server to it to provide data in any form required. The fgms code already has a 'crossfeed' config parameter, so can feed every packet received to that connected 'crossfeed'... with the header set to RELAY_MAGIC... even before 'Blacklisted' or 'Invalid' packet rejection... That 'crossfeed' data can then be accessed ANY way you desire, and produce pilot information in ANY form needed... on a private or public ports... without impacting the FG community mp servers... As I have stated I would assist to develop this 'crossfeed', which in essence is just another fgms server, given some desired specifications... And that could perhaps include providing say a pilot's historical 'track', and perhaps even some 'predicted' track... to show on the 'map'... But the FIRST step is housing and setting up a new mp server, and getting all others to relay to it... But as usual, this is just my 10 cents ;=)) Maybe everyone is happy with telnet 5001 server 'bashing' as the source of the 'map' data... Regards, Geoff. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap
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 turned on and running the mpmap in your browser, you burn your bandwidth twice to ship the same information down your internet pipe to two separate applications. If you served the map from FlightGear directly, you could draw the nearby MP traffic, local AI traffic, and not double burn your internet bandwidth at the same time. I have a basic websocket interface, but I haven't tried to integrate it into FlightGear yet. Also we'd need to expand FlightGear's httpd interface to also be able to serve .html and .js files -- probably from a single authorized subdirectory for security reasons. On May 15, 2012 5:58 PM, Peter Morgan p...@daffodil.uk.com wrote: 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 idea what I want to do which is make it osm compatible for a start.. and then take it from there.. So anyone else playing with this idea? anyone else done and development ? where can we share these new ideas as a repo ? pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap
On Wed, May 16, 2012 at 12:15 AM, Curtis Olson curtol...@gmail.com 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 a server. Well nowadays websockets is a good idea.. BUT still a bit unstsable... but definately its more the way to go and am very happy you mention that.. so this is cool.. and an idea from before https://github.com/ac001/FlightGear-MP-tools/blob/master/MP_monitor.py So the above script chek for DNS servers.. with mpserve*.. and then polls via telnet.. Essentially if you are running FlightGear with MP turned on and running the mpmap in your browser, you burn your bandwidth twice to ship the same information down your internet pipe to two separate applications. If you served the map from FlightGear directly, you could draw the nearby MP traffic, local AI traffic, and not double burn your internet bandwidth at the same time. Which leads to the conclusion that maybe the best maybe might be to slave a local app eg in qt client local that queries the local isntance of fg for data.. of position etc.. I have a basic websocket interface, but I haven't tried to integrate it into FlightGear yet. Also we'd need to expand FlightGear's httpd interface to also be able to serve .html and .js files -- probably from a single authorized subdirectory for security reasons. Well thats fine.. But at #1 there are a few issues.. 1) we need to replace current map and == telnet mpserver 2) we need to be it work with different reliable and selectable maps (osm api does that mainly) and 3) we need to overlay on the map .. .. a) flight positions and .. b). nav data.. So indeed its a complex problem.. However I think if we split up the stuff cleverly.. by a load of us having a go at it.. I think it woul be straight forwad.. I think the main issue is actually the capacity of the server.. for example a current mpmap install requires a postgres db and perl and telnet access.. Wheraes the reality is we want anyone with an account and internet facing ISP machine to be able to host.. eg with php virtual host or AWS, djano.. python instance.. etc.. google app engine... (which only spreeks port 80 in and out) or behind an nginx and port forwarding as in my case with fgx.ch.. Also the database of navdata is an issue.. But these are many issues.. So my suggestion is we start at #1 at ksfo.. and set up a new map system/ So I am prepared to lead this project.. but I must stress that we need to make it user friendly and amenable for end installers etc.. eg I dont want a new keen fligthgear player to give up in installing it on his prvate server.. because fo postgres, or no mysql etc.. I want them to be able to install and maybe even set some limits on range and be able to rely on navdata and etc from upstream.. somewhere.. ALSO ALSO the mainissue is a destop replacement for atlas.. and that is clear to me with marble.. which is a kde project.. and then maybe we can overlay this http://map.fgx.ch/ BUt BUT.. even beter.. If we use websockect we can be clever also.. eg we can send queries and get results of stuff. kinda IRC like and MAYBE eg /metar ksfo even /msg foobar descend and maintain 200ft /vor BNN return data on BNN we can even replicate aircraft systems So .. Where do we go from here..?? I think we need a little bit of a plan first.. before any of us ding down a wrong path .. But we also need to recognise a proper new project and team to support.. (maybe next year GSOC we have plan for this project even... ) pete On May 15, 2012 5:58 PM, Peter Morgan p...@daffodil.uk.com wrote: 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 idea what I want to do which is make it osm compatible for a start.. and then take it from there.. So anyone else playing with this idea? anyone else done and development ? where can we share these new ideas as a repo ? pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference
Re: [Flightgear-devel] mpmap
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.. so we need to cover this scenario across anyones installation.. to make it usable.. another thought.. pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
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 headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. KJFK, runway 31L - mpmap ILS course; 301 degrees Flightaware ILS approach plate; 315 degrees. I have not looked at the 850 airport format, but is there a way in any of the apt.dat or nav data to specify ILS approach data accurately? Or is this a question for Pigeon, to see about using a different data list? Currently the heading data is misleading - it would be better to not have it shown than have it incorrect in my opinion. I didn't even know MPMap had this feature, but the problem is *not* the data in apt.dat or nav.dat - the localizers (excluding installations with an offset localizer, like the old Kai-Tek approach) are aligned with the true runway centreline, and don't know anything about the published or magnetic runway heading. I guess (having just written similar code for the Map dialog ILS display) that the issue is with a numerical heading value displayed for the ILS, on the MPMap - which as you should probably should account for magnetic variation - but I'm pretty sure this has to be fixed in the mpmap code. All of the above is with the caveat that I didn't know this feature existed in MPMap - it's also not what I would recommend to shoot an ILS - I mean, you'd *never* fly an ILS approach without the correct plate to hand, right? Right? :) Regards, James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown smoothwater...@adelphia.net 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 headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. I'm not familiar with mpmap, but that's not a problem for FlightGear itself - the localizer directions are all specified in Navaids/nav.dat.gz in degrees true, independently of any runways they might be associated with (not all localizers are attached to a runway, and even when they are, the direction might be 10 degrees off from the runway). Here's the example for BTV (where I've flown the localizer in real life as well as in FlightGear): 12 44.4652 -073.14009400342 11030 18 0.000 IVOE KBTV 33 DME-ILS But then, the vast majority of runways don't have localizers. Perhaps the map is just trying to show an extended runway centreline, and the person who designed the app mixed up magentic and true heading. The Airports/apt.dat.gz file does give runway headings in degrees true, not degrees magentic, so there's no need to mess around with magnetic deviation. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 8:08 AM, David Megginson wrote: On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown smoothwater...@adelphia.net 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 headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. I'm not familiar with mpmap, but that's not a problem for FlightGear itself - the localizer directions are all specified in Navaids/nav.dat.gz in degrees true, independently of any runways they might be associated with (not all localizers are attached to a runway, and even when they are, the direction might be 10 degrees off from the runway). Here's the example for BTV (where I've flown the localizer in real life as well as in FlightGear): 12 44.4652 -073.14009400342 11030 18 0.000 IVOE KBTV 33 DME-ILS But then, the vast majority of runways don't have localizers. Perhaps the map is just trying to show an extended runway centreline, and the person who designed the app mixed up magentic and true heading. The Airports/apt.dat.gz file does give runway headings in degrees true, not degrees magentic, so there's no need to mess around with magnetic deviation. All the best, David 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 what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) I believe James is correct in that it's probably a question for Pigeon, whom I believe created and maintains the mpmap data. James, You are correct as well, in real life you don't shoot an approach without the plate. (Okay..., you shouldn't...) :) ButFG does have to walk that thin line between sim and reality, and until users get to the point of full reality immersion, they will use the data presented to them for ease of use (if nothing else). While I enjoy FG immensely due to all of the developers work, I doubt I'll be strapping on an approach plate until I'm sitting in a full blown simulator cockpit with the door shut. :) So, I guess I'll see if Pigeon responds about perhaps re-formatting the mpmap code to use actual approach headings instead of runway headings. For anyone that isn't aware of the data presented, I recommend you take a look. It has more info than you may realize, and it helps the user find airports, navaids, and more. Airport data includes the degree of GS (for those rare abnormally high approaches), localizer frequency, and if a CAT 1,2, or 3 approach. For most of the users this is a wealth of information. A side benefit is from an ATC point of view for FG events, you can visually see how well the pilots are flying the localizer. Peter :) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown smoothwater...@adelphia.net 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 what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) The plates give the heading in degrees magnetic; the data file gives it in degrees true. That's still a degree off (BTV is 15W, IIRC), but it's pretty close, and nav.data.gz may be based on old data. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 1:29 PM, David Megginson wrote: On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown smoothwater...@adelphia.net 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 what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) The plates give the heading in degrees magnetic; the data file gives it in degrees true. That's still a degree off (BTV is 15W, IIRC), but it's pretty close, and nav.data.gz may be based on old data. All the best, David 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 data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Thanks, Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
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 file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. They are certainly going to keep the true heading in the navaid file, because the magnetic heading is changing permanently and therefore is a moving target. The navaids collection is meant to place the navaids at their proper location in an unambiguous way - which obviously is the true heading. BTW, feel free to use this service if your're looking for slightly more complete airfield data: http://mapserver.flightgear.org/ms?Service=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter still processing. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
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=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter BTW, the figures for magnetic declination are based on: http://www.ngdc.noaa.gov/geomag/WMM/DoDWMM.shtml Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
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 from the navaids. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. They are certainly going to keep the true heading in the navaid file, because the magnetic heading is changing permanently and therefore is a moving target. The navaids collection is meant to place the navaids at their proper location in an unambiguous way - which obviously is the true heading. BTW, feel free to use this service if your're looking for slightly more complete airfield data: http://mapserver.flightgear.org/ms?Service=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter still processing. Cheers, Martin. -- I have no reason to take it out, but I see no reason to not compile a list of approach plate data that the mpmap can retrieve usable data from either, if you don't want to add it to the navaids file. Is there any reason not to? Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown smoothwater...@adelphia.net 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 data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Again, I haven't used mpmap, but are you certain it is trying to display an ILS localizer, and not just an extended runway centreline? You're right, of course, that it might have messed up true vs. magnetic (especially if the developer was working somewhere with very little magvar, and wouldn't have noticed during testing). Our files list actual runway headings in degrees true as well, so the only thing I can think is that the developer just took the runway *number* and converted it to a heading. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 4:58 PM, David Megginson wrote: On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown smoothwater...@adelphia.net 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 data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Again, I haven't used mpmap, but are you certain it is trying to display an ILS localizer, and not just an extended runway centreline? You're right, of course, that it might have messed up true vs. magnetic (especially if the developer was working somewhere with very little magvar, and wouldn't have noticed during testing). Our files list actual runway headings in degrees true as well, so the only thing I can think is that the developer just took the runway *number* and converted it to a heading. All the best, David No, I'm not sure of any of it. I was thinking I had posed it as a question whose answer was readily available - I wasn't trying to debate it if that's how it came across. I like functionality that the majority of users find useful, since I classify myself as one of those. :) My guess is that as Martin said, he/she probably is grabbing data from the navaids file. To show you what mpmap provides, here's a few links. Note the two heading info boxes when you have the ILS beam on - as if to display Runway heading and Approach heading, since the first info box also lists the runway number, ILS CAT #, and GS degrees. http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50447PM.png http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50447PM.png http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50518PM.png Thanks, Peter-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
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=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter I have no reason to take it out, but I see no reason to not compile a list of approach plate data that the mpmap can retrieve usable data from either, if you don't want to add it to the navaids file. Is there any reason not to? Yup, as already said, the navaid file is meant to carry unambiguous data (by design), while magnetic heading depends on the date and is therefore unsuitable for the given purpose. This is not about personal preferences, this is about the design of a file format, a written spec is available here: http://data.x-plane.com/file_specs/XP%20NAV810%20Spec.pdf If you see no reason to not compile a list of approach plate data that the mpmap can retrieve usable data from, feel free to go ahead ;-) In fact, my primary target is to maintain this database of airfield-, navaid- and a lot of other datasets in a 'generic' representation which is suitable for automated processing, but my domain is not to provide neat user interfaces (others are, apparently, more skilled to do that). People, including those who are running MPMap servers, are invited to use it, if it fits their needs, various formats are available (GML, GeoJSON and the like). If you're in need of a human-readable one-shot database table dump, please let me know. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
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, and therefore all the course headings are incorrect. That is the wrong way to think about the problem. This is basically a geodesy problem. It should be worked using true headings, true lat/lon, et cetera. The question of magnetic variation should never come up in this context. I have not looked at the 850 airport format, but is there a way in any of the apt.dat or nav data to specify ILS approach data accurately? The navaid data is accurate. The 830 and 850 formats are equivalently accurate. Or is this a question for Pigeon, to see about using a different data list? There is no need for that. The existing nav.dat data is plenty good enough. The existing FGFS code handles this correctly, except in the case of reversible ILS installations. Perhaps mpmap could just clone this code. Also, the code to handle reversible ILSs in a reasonable way exists in the sport model. It has been available for many months, as previously discussed. Let me know if you are interested. Or take a look at http://gitorious.org/~jsd/fg/sport-model/commits/sport This is an issue for more than 20% of all ILS installations in the US and UK ... and more than 10% worldwide. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
