Board index FlightGear Support Tools OpenRadar

An idea/request

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

An idea/request

Postby morlanius » Fri Apr 29, 2016 11:34 pm

Hi,
I would like to request a feature or two. I think these would be really cool, some people may use them some may not. What do you guys think and Mr OpenRadar dev would this be possible?

Completion log:
This feature should be enabled from the start-up dialogue using a single checkbox.
The feature should behave in this manner.
When a FP is closed and the FP source and destination are both populated the flightplan should be saved to an XML file located in OpenRadar/ContactLogs/<date>-<time>.xml
The xml should be along the lines of
<log airport="EGSS">
<contact>
<callsign="xx-xxx">
<aircraft="777-ER">
<source="EDDF">
<destination="EGSS">
<notes="some notes">
<time=23:41>
</contact>
<contact>
...
</contact>
</log>


It would also be nice if we could have a couple of characters added to the username length.

The ability to open more than one radar would be a bonus, or even just a basic one (with fixes and everything except ground net disabled) that just shows the ground for those of us that do our own ground. I guess that more of a "would be nice" kind of feature.

The AssVFR/AssIFR/REvSqw buttons
Increased spacing. make the bar taller and use 2 line like
Ass
VFR

A cloud overlay viewable by a toggle button on the right edge of the screen level with the METAR information.
Using either a scan of METAR stations within the render radius of the AP or by using a weather station server from the internet gathering cloud (and rain) data
to draw polygons onto the map. This could also be done by querying all the METAR location in range and drawing a circle on the map around that station. they should eventually add up to a rough map of weather. (draw them all at the same layer and draw them in blend mode).

What do you guys think?


Jay
User avatar
morlanius
 
Posts: 36
Joined: Mon Jan 25, 2016 1:29 am

Re: An idea/request

Postby a-v-o » Sat Jul 09, 2016 4:45 am

some thoughts/questions to the completion log:

<log airport="EGSS">

The airport could be put into the logfile name:
<airport>-<date>-<time>.xml
Which date-time should appear in the filename?

<source="EDDF">

-> <departure="EDDF"/>

<notes="some notes">

There are 2 notes fields: one is public the other private. Which one should be logged?

<time=23:41>

Which time should be logged?
Would it be of interest to log departure and arrival time time?

If the logfile should be processed by other programs to create statistics or graphs, then the xml format might not be very handy. The csv format is a simple table format. Advantage:
The xml file must have </log> at the end to be valid. In case of an unexpected program termination that would be missing. In a csv file there's just a line to append for each contact and the file is valid after each correct written line. It's smaller than a similar xml file, can be imported in applications like LibreOffice Calc, There's no need to create a separate file for each session, because the file can be closed and next time there's just a new line to be appended.

It would also be nice if we could have a couple of characters added to the username length.

As far as I know this is a limitation of the data interchange protocol. It would affect flightgear, multiplayer, maps and statistics servers besides OpenRadar. Possible to do, but a lot of work.

The ability to open more than one radar would be a bonus, or even just a basic one (with fixes and everything except ground net disabled) that just shows the ground for those of us that do our own ground. I guess that more of a "would be nice" kind of feature.

Additional free positionable windows within the same instance of OpenRadar with different zoom levels and views could be implemented, but that would like double (add one for each window) the CPU usage. I'm not sure about the effect on the memory consumption.

The AssVFR/AssIFR/REvSqw buttons
Increased spacing. make the bar taller and use 2 line like
Ass
VFR

I'm not sure about this one. As monitors are now mostly widescreen, why do you want to spend an extra line for these buttons?

A cloud overlay viewable by a toggle button on the right edge of the screen level with the METAR information.

Sounds great. I hope you can program and join the developer team to add this feature.
a-v-o
 
Posts: 22
Joined: Wed Jan 20, 2016 12:34 am

Re: An idea/request

Postby jomo » Sat Jul 09, 2016 10:04 am

I guess one of the biggest problems of these modern times with ALL data of the whole world available in sub-seconds everywhere in the world in different formats -- and trying to see/know them all at once on one screen -- means that you may get problems to concentrate on what your job is. A second big problem is, that whenever you add (nice) features to a program you decrease the stability of a program -- especially if those data depend on different, not directly related programs! Somehow I missed a reasoning for those add-ons to the unique OpenRadar screen! We should not try to pack all the worldwide available data in one single program. I guess none of today’s ATC's do work with only OpenRadar being active - so all ATC's do have the possibility to switch any time between different applications to get the best additional Infos from any source they want - rather than double all that infos into OpenRadar. See just a small reminder to what is available/suggested with a Browser open in parallel:

FGFS: Is based on 7 digits UIDS - we should stick to that. It is already difficult to keep track of different UIDS in FGFS and MPmap and MP-FGFS-recorders, and MUMBLE, and Pilots with CoPilots, etc.

Flight-plan: I do not suggest that the controlling ATC has to fill in all the data of a FP - and thus double the data of http://flightgear-atc.alwaysdata.net/ - that FP-server once was a great idea and even has a functional bridge into the OpenRadar. See e.g. http://wiki.flightgear.org/OpenRadarGui ... Management . Sorry enough the usage of that tool by pilots is constantly decreasing. And quite frankly I do not want to TYPE all the time FlightPlans for all the pilots in the area (most of them probably will even resist to give you proper data!)! But I do add the ATC-important data like, Departure-ICAO, Destination-ICAO, planned Cruising Alt, planned SID/STAR, etc for Pilots under my control (plus those just reporting in while passing my area). All other data would be nice - but not really needed (and seldom supplied by pilots!).

Weather-Data: Every ATC should be able to interpret the displayed ATIS infos on the screen. If more details are needed/wanted I suggest (e.g. for Europe http://radar.wetterdienst.de/m/) for an excellent graphical display of all the actual Weather-data and Forecast. If you want to see the actual Weather at your port I suggest you open an additional FGFS-session with a look from the Tower - and stay aware that not all pilots are using the actual weathers! (I usually do not care what weather they have set!)
And why would an ATC need to know all the Weather-data and locations of all weather-stations around?

Being able to switch to an extra Radar-Picture if some ATC uses an own GND-map does not make sense to me - because then the ATC sees something different than the pilot! And switching would not be possible all the time if you have many targets at once (how would you know which client needs what charts? The problem is already big enough due to some pilots using old sceneries - e.g. still flying with FGFS 1.9! Not to speak of constant changes by TerraSync)

I do not have the need for an extra log of who was in the area -- or do you mean just arriving/departing, not considering also "Just passing through your area" (that might be difficult to separate!). Anyhow I am not sure what that should indicate! Most people are flying without a FlightPlan, they may even enter/exit MP several times - and would the log be separate for landing/starting, etc? I am not sure what that would be used for! If done it should not be an ongoing log - but just contain one session (expressed in date and time and location). It could be formatted as the ERROR-logs..

I strongly suggest not to overload the existing OpenRadar with "nice to have" data! The program is already very much loaded with features and linked to other programs - so that we might expect problems in the future when other programs change their data and/or structure! Let us be glad that OpenRader is as stable as it is - and hopefully stays that stable in future!
jomo / ATCjomo
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: 823
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 17.10


Return to OpenRadar

Who is online

Users browsing this forum: No registered users and 1 guest