Board index FlightGear Support Tools OpenRadar

Issues with data

OpenRadar is a standalone radar screen which connects to the FlightGear multiplayer servers. It is currently being developed.

Re: Issues with data

Postby jomo » Wed Aug 14, 2013 10:41 am

Somehow I do not understand any more what that is all about in this forum. As far as I understand the mentioned problems base on:

1) Combining real external data with FGFS-internal data
    As a fact there is (and will always be) the problem:
      the real (professional) world works with daily updated changes/infos/advises etc (which cost a lot of money for professionals or their company!)
      OpenRadar is based on freely available (not always the newest) data which are on a slightly newer level than FGFS
      the big and complex FGFS data cannot follow all those changes as fast
    Thus we do have to deal with NOT ALWAYS THE NEWEST IN ALL AREAS. And thus we need to compromise in defining the LEADING/BASE data -- for me that are the FGFS data which are used by all FGFS-users -- while the more professionals (like FGFS-ATC's) may be using different data. That is not bad - as long as those people are aware of that and are able to compromise! e.g. we must be able to adapt a new SID from the real world to the FGFS (and/or Open Radar) environment - so all FGFS-users can follow it. Already that is work enough in a daily changing world! See e.g. EDDF with its added 4th runway and thus new routs and new navigation-facilities - even the real world has still problems with it. And for FGFS you should consider all the Non-Professional users with their very different FGFS-versions, skills, and willingness to comply!
    In addition those "FGFS-professionals" should be careful about what data they use or promote to be used! e.g.: The referenced "jeppesen release 3.7.2.1" data on http://www.fly-sea.com/charts/EGKK.pdf are 6 to 10 years old (see the dates in the header!). And be careful to use copied versions: There is something like "copyright" - and even if only you use them - how do you make them available for all users in FGFS? (That is also one of the reasons why we cannot always use the newest data!)
2) The data may change constantly
    I guess everybody is aware that human beings are changing the world (especially the technical and even more the electronic-world) on a daily base (see above). But also the world/earth is changing every day - a good explanation for e.g. the magnetic problems you find in http://en.wikipedia.org/wiki/North_Magnetic_Pole. Also see e.g. http://skyvector.com/files/tpp/1308/pdf/05591AD.PDF : In the upper right corner you find (on all good airport maps) the vector showing the difference between the magnetic and geographic north-pol and the predicted annual rate of change! Another reason why we as Non-Professionals need to compromise!
3) "True" or "Magnetic Heading"
    I am not sure why someone means all professional pilots navigate by "true heading"! To my knowledge it all began with just a magnetic compass. Then when the "Directional Gyros" were used every pilot had to readjust that gyro from time to time according to the magnetic compass (and he could go to jail if he forgot that - see the pilot training manuals). As of today modern navigation may change to GPS and similar and thus get headings from that! But e.g. all VORs still use magnetic headings! Yes: In Europe that difference is small and thus just about neglectable but:
    see at http://skyvector.com/?ll=51.148055556,- ... 301&zoom=3 the "0-arrows" inside the VOR's point practically to north (You do not see a 1° difference)
    see at http://skyvector.com/?ll=37.619105028,- ... 127&zoom=3 you see a very significant difference
    But definitely you see that they show the magnetic heading! And thus on all charts you see the magnetic headings used!
    And please: I do not want to be the guy telling a new pilot coming VFR in a c172p to convert my given headings into the magnetic headings in his gyro!!!
4) Split FGFS from "Real Life" -- Do we need daily updates to compare to the daily changes and NOTAMS etc?
    I cannot see why "GAMERS" should need the very newest data as in real life. But even the growing group of "SIMULATORS" do not need it. Even the Flying Simulators in the real world do not constantly update to the newest data - and they do not need to (for most applications).
5) Do we need to update FGFS twice a year or never or ...
    Well there are people that "play" and need a new computer each few month - and there are others that have specialized data which cannot be transferred easily (e.g. many big companies have very very big problems whenever they want to transfer their data to a new program!). But what is the problem in FGFS regarding to that? As good example: If you watch the movies at EDDF (http://www.emmerich-j.de/EDDF/Films/Films.html) you will see that some aircraft taxi with the wheels under the pavement, others do not see the 4th runway or do not use ILS nor VOR or whatever -- but is that a problem? If some FGFS-user wants to use the newest FGFS-version he can do so - if not then he might miss some of the fun. And if he wants to use the daily newest papers and charts from the "professional world" he can pay for them as much money as he can!
      The point is:
    We as ATC's have to be able to serve all FGFS-users (may he fly a c172p or a 747-8) -- and that has a higher priority than trying to always be on the very latest level of the real world! I believe we should be very greatfull to those designers that have brought FGFS to the level we have - and are still updating as good as any unpaid professional can do. Even Microsoft can/could not do better for money!
Can we somehow combine our efforts in the direction to support all FGFS-users in a multiplayer environment - and not just the "want to be professionals"?
jomo / ATCjomo + EDDFjo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 1000
Joined: Thu Feb 12, 2009 7:46 pm
Location: Mainz, Germany
Callsign: jomo EDDFjo1+2
OS: UBUNTU 18.4

Re: Issues with data

Postby Secret_Hamster » Thu Aug 15, 2013 2:19 pm

I think this was part of the point I was trying to make earlier.

We need some standard base that fgfs has. This means fgfs, open radar and whatever can adhere to. It's then up to individual projects if they wish to use custom data and how they interact with others. Hence why the 2006 set of charts, AFAIK these are the closest to the data time that we use or am I wrong?
User avatar
Secret_Hamster
 
Posts: 117
Joined: Thu Jul 05, 2012 9:32 am
Location: UK
Callsign: H-MSTR
Version: Git
OS: Linux

Re: Issues with data

Postby jomo » Thu Aug 15, 2013 6:32 pm

Secret_Hamster wrote in Thu Aug 15, 2013 2:19 pm:We need some standard base that fgfs has. This means fgfs, open radar and whatever can adhere to. It's then up to individual projects if they wish to use custom data and how they interact with others.

Oh yes - standards are always wonderful - everybody in the world would like them for everything -- there is only one little problem: How to achieve them -- and then get everybody to stick to them over "all time time to come"! As an example see metric/inch, left/right hand traffic, only one FAA worldwide, frequencies, maps, etc being all the same worldwide. A wonderful dream!

Seriously for the matter we address here: You especially just talk FGFS and OpenRadar, one on Java the other on Microsoft, Linux, MAC, .. And in addition we are talking about things done by people that do all that in there free time - without payment --> distributed worldwide -- that means you cannot order or force or just agree on anything over a long time.

I guess you need to find solutions that are more flexible! Somehow you seem to propose something similar. But I would formulate it just very harsh: All programs that want to cooperate with FGFS must be based on FGFS as is -- of course everybody may try to find someone inside FGFS that may change something --- but I doubt very much that a standard could be enforced!

So for this general problem I see only one solution for you: Cope with how FGFS is and keep your things flexible enough to change whenever FGFS changes - and have someone who commits himself to support that the next 20 years (or so!)!
jomo / ATCjomo + EDDFjo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 1000
Joined: Thu Feb 12, 2009 7:46 pm
Location: Mainz, Germany
Callsign: jomo EDDFjo1+2
OS: UBUNTU 18.4

Re: Issues with data

Postby wagnerw » Fri Aug 16, 2013 6:53 am

I completely agree with Jomo, all additional tools should be oriented on fgfs way of doing things. But asumed that, fgfs data must contain everything that is needed by the additional tool. Using an existing fgfs installation as data source sound good, but fails, when you consider how many different fgfs versions are being used in real world. So I tend to deliver the data, that have been used to test OpenRadar.

In the case of the variations, I can take over the fgfs model and calculate the 'current' variation at OpenRadar start. Currently I retrieve it from NOAA when a new airport is being downloaded and store it. This call is quite straight forward. See OpenRadar code!
I will leave the current code where it is, to avoid a re-implementation as soon as fgfs changes.

As much as I have seen in my short look, the source data for that model are from 2005.
wagnerw
 
Posts: 283
Joined: Tue Nov 06, 2012 9:35 pm
Callsign: D-W794

Re: Issues with data

Postby Johan G » Fri Aug 16, 2013 12:45 pm

wagnerw wrote in Fri Aug 16, 2013 6:53 am:As much as I have seen in my short look, the source data for that model are from 2005.

Yep, I got that impression as well.* And considering that the models, from what I have gathered from the technical report, seems to be aimed at providing predicted corrections to keep the variation** within 1 degree throughout their five year lifespans, WMM 2005 should probably not be to far off even now.

* See simgear/magvar/coremag.cxx about line 30.
** Called declination in the technical report (huge PDF).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Issues with data

Postby Johan G » Fri Aug 16, 2013 3:03 pm

Sorry all, this is partially going to be way off topic. :roll:


@Secret_Hamster: I'm sorry if I sound a bit harsh at times. I really want this simulator to be close enough to reality in how things work that I can use it as a tool in learning new stuff, mostly from various handbooks, and play around with the newly acquired knowledge. :wink:


@Joomo: Sorry for "ignoring" that longer post. I wanted to give a well thought through answer.

As for points 1, 2 and 4, yes things is not up to date and I share your conclusion that FlightGear most probably will never ever be up to date with real life data. There is really slow changes like magnetic variation, there is the near monthly changes and there are daily changes, not to mention real life traffic. It is completely utterly impossible to keep all that current and up to date in FlightGear for as long as I can imagine.

I think that the magnetic variation could be updated every five years to be current, and that a large portion of the navigation data could possibly, at some point in the future be kept updated on a monthly bases. But weekly and daily base, no way. One could of course get current NOTAMs and simply not use a runway under repairs. :wink:

At one point I was considering using Atlas, Quantum GIS and Inkscape to make VFR charts in order to have charts that are reflecting the data used by FlightGear. That project got inactive due mostly to time constraints. I have another inactive project making vector symbols of ICAO chart symbols, made with the intention to use them in a similar work flow. If I had a Linux box I could probably automate larger parts of that work flow, maybe even to the point that they would be up to date with TerraSync. The biggest hurdle in those projects though is that hand editing the maps (QGIS gives crappy svg output) takes too long time and my scripting skills are rather poor.

Ah, and the copyright issues. I'm not even sure I want to go there, but copyright has to be respected, at least what gets contributed to the FlightGear project. Not using data that have to paid for is a given. Which also put limitations in available data.


As for point 3, which also applies to points 1 and 2: The most important thing for me is not having things up to date with real life, but rather to have them working as in real life. :wink:


And finally about point 5:
jomo wrote in Wed Aug 14, 2013 10:41 am:Can we somehow combine our efforts in the direction to support all FGFS-users in a multiplayer environment - and not just the "want to be professionals"?

Your most important statement, I believe.

For me it is really about getting people interested in learning new things. And there is a lot of skills that can be attained or improved when getting hooked on FlightGear: Flying, navigating, communicating, aerodynamics, programming, 3D-modelling, texturing, vector and raster graphics editing, database management, social skills and a whole lot more.

But to get people hooked, FlightGear must be both a fun, challenging, realistic and, not less important, social experience. A really tricky mix when considering the vastly different skill and knowledge levels, not to mention the different expectations and ambitions people have when trying out FlightGear the first times and/or get in contact with the community. There is also the everlasting problem with hardware limitations and performance versus features.

But most of all it has to be fun, for all, or at least the very most.

And yeah FlightGear is an amazing project, with an amazing community. Sure there have been downright flame wars at times, but mostly things just work. In the three years I have been around here I have seen people come and sometimes go, witnessed many impressive developments and wow I have learned a lot, both in technical areas and, to some extent, in social skills. I would not even have had to do anything, I would still have learned a lot if I had been lurking around only observing, but it is far more rewarding to be a small a part of it. In short, I'm hooked. Thank you all! :D
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Issues with data

Postby Secret_Hamster » Tue Sep 03, 2013 9:22 pm

I think this is pretty much at a close from my first point. There is an element of errors within the system as there no way we can conform to one single standard.

We are going to have differences between various parts of the project, as well as differences to real life. It is something we have to live with, and I have no arguement against that. I think all the points here have been fair.

To which case I think my particular solution is.

1) I get things as close to the charts I have and make some compromises
2) Give pilots abit of leeway on the routes they come in on. (Though I have so say some that come in stick pretty much to the guides I have in OR)
User avatar
Secret_Hamster
 
Posts: 117
Joined: Thu Jul 05, 2012 9:32 am
Location: UK
Callsign: H-MSTR
Version: Git
OS: Linux

Re: Issues with data

Postby wagnerw » Thu Sep 12, 2013 7:07 pm

Hi,
I have ported the fgfs model for the magnetic variance from simgear to OpenRadar. The difference between the downloaded result and the model is small, but I will change OR to use the FGFS one. So we have the same situation in OR as in FGFS. The charts differ, only if we change the reference date of the models to the date of the charts everything would match to the situation described to the charts. But I guess this is not practical...
Wolfram
wagnerw
 
Posts: 283
Joined: Tue Nov 06, 2012 9:35 pm
Callsign: D-W794

Re: Issues with data

Postby stuart » Thu Sep 12, 2013 7:47 pm

Going back to one of the OPs comments regarding VORs : while the VOR radials are magnetic rather than true, I'm 90% sure they are fixed at the point the VOR was built (though I guess they might be updated during maintenance) so dont be surprised if your magnetic heading doesn't quite match the VOR radial your are tracking.

Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Previous

Return to OpenRadar

Who is online

Users browsing this forum: No registered users and 8 guests