FlightGear - Flight Simulator

On 25/03/06, Melchior FRANZ <mfranz@...> wrote:

> The airports list is barely usable: there are so many entries
> in it that you don't easily find anything. And the slider resolution
> is much too high for finding an entry with it alone. Move it
> just one pixel, and you jumped over oodles of airports. The arrow
> buttons have no repeat function, so they are of limited help, too.
> I've now hacked the airports widget to allow filtered lists:
>
>   http://members.aon.at/mfranz/airports.jpg  [30 kB]

We need to get geopolitical information into our airport list, at
least at the country and region (state/province/etc.) levels -- that
could make the filtering much more useful.  Proximity filtering might
also be nice, but that's a much bigger job.


All the best,


David

--
http://www.megginson.com/

* Melchior FRANZ -- Saturday 25 March 2006 18:01:
> [...] the slider resolution is much too high for finding an entry [...]

Too low, of course.  :-)



> I've now hacked the airports widget to allow filtered lists:
> 
>   http://members.aon.at/mfranz/airports.jpg  [30 kB]

BTW: this is not in CVS because of the feature freeze *and* a
necessary change in fg_command.cxx:

  @@ -1127,6 +1128,6 @@ do_dialog_apply (const SGPropertyNode *
               dialog->applyValue(name);
  -            dialog->updateValue(name);
  +            //dialog->updateValue(name);
           } else {
               dialog->applyValues();
  -            dialog->updateValues();
  +            //dialog->updateValues();
           }

These two lines break the whole concept of "dialog-apply" (copy
data from widget to property) and "dialog-update" (copy data from
property to widget). The log message for this paranoid addition
was:

| Do an update after apply to see what really got into FlightGear.

But that's what update is for. In the case of the airport list
we need two-way communication: getValue() returns the selected
entry, but setValue() sets the filter rule. Copying the filter
rule back as "selected entry" does no good. I'm still investigating
if this change works with all our dialogs. Maybe one would have
to add a "dialog-update" on some places. Should be trivial, though.

If someone wants to test this, then I can post the patches.

m.

On Saturday 25 March 2006 19:48, David Megginson wrote:
> On 25/03/06, Melchior FRANZ <mfranz@...> wrote:
> > The airports list is barely usable: there are so many entries
> > in it that you don't easily find anything. And the slider resolution
> > is much too high for finding an entry with it alone. Move it
> > just one pixel, and you jumped over oodles of airports. The arrow
> > buttons have no repeat function, so they are of limited help, too.
> > I've now hacked the airports widget to allow filtered lists:
> >
> >   http://members.aon.at/mfranz/airports.jpg  [30 kB]
>
> We need to get geopolitical information into our airport list, at
> least at the country and region (state/province/etc.) levels -- that
> could make the filtering much more useful.  Proximity filtering might
> also be nice, but that's a much bigger job.
>
>
> All the best,
>
>
> David


I did do some work on that a long time ago using the ICAO codes to break up 
the data by country but ran into a couple of problems.

1. There is no state/province field in the airports db and it can't be deduced 
from ICAO codes.
2. There are a couple of areas in the world that share the same ICAO code even 
though they belong to different countries so using the ICAO code isn't a 100% 
accurate method.

The best would be to have a country and state/province field in the airport DB 
and that would need to come from Robin Peel unless we want to have a 
different DB again.

Regards
Paul

On 26/03/06, Paul Surgeon <surgpub@...> wrote:

> I did do some work on that a long time ago using the ICAO codes to break =
up
> the data by country but ran into a couple of problems.
>
> 1. There is no state/province field in the airports db and it can't be de=
duced
> from ICAO codes.
> 2. There are a couple of areas in the world that share the same ICAO code=
 even
> though they belong to different countries so using the ICAO code isn't a =
100%
> accurate method.

3. Smaller airports sometimes don't use ICAO codes (though most of
those are in the U.S.).


All the best,


David

--
http://www.megginson.com/

On Sunday 26 March 2006 13:49, David Megginson wrote:
> On 26/03/06, Paul Surgeon <surgpub@...> wrote:
> > I did do some work on that a long time ago using the ICAO codes to break
> > up the data by country but ran into a couple of problems.
> >
> > 1. There is no state/province field in the airports db and it can't be
> > deduced from ICAO codes.
> > 2. There are a couple of areas in the world that share the same ICAO code
> > even though they belong to different countries so using the ICAO code
> > isn't a 100% accurate method.
>
> 3. Smaller airports sometimes don't use ICAO codes (though most of
> those are in the U.S.).


4. There are lots of smaller airports and airfields with no identifier code 
whatsoever (although we don't have any of those in FG).
I added about 300 missing airfields with no identifier codes to Southern 
Germany for Silent Wings. Lots of glider strips and airfields with grass/turf 
or gravel runways.

Paul

* Melchior FRANZ -- Sunday 26 March 2006 09:47:
> If someone wants to test this, then I can post the patches.

And if nobody wants (which seems to be the case :-), I can post the
patches, too:

  http://members.aon.at/mfranz/airports.tar.gz  [2 kB]

You need to comment out the two silly lines in Main/fg_command.cxx,
and to apply GUI.diff in src/GUI/ and airports.diff in $FG_ROOT/gui/dialogs/.
Note that the filter pattern is case sensitive and only searched in all
entries as they are. If there's demand for shell style wildcards (*?) or 
regular expressions, then I'll implement that. It's good enough already,
though. Enter ...

  (LO     ... for all Austrian airports
  (LOW    ... all international Austrian airports
  (LOX    ... for all Austrian military airports (except LOXL which
              is also known as LOWL and only used as such in Robin's db)
  (LOL    ... all airports in the Province of Upper Austria (except LOWL,
              as it's international)
  (K      ... almost all US airports 

etc. etc.  (see http://en.wikipedia.org/wiki/ICAO_Airport_Code)

m.

* Melchior FRANZ -- Sunday 26 March 2006 15:11:
> Note that the filter pattern is case sensitive [...]

Also not that the [Search] button is only for newbies. Hardcore
fgfs users know that <Tab> validates input fields, too.

m.

* Melchior FRANZ -- Sunday 26 March 2006 15:11:
>   (K      ... almost all US airports 

... with IACO codes, that is.  :-}

m.

On 26/03/06, Melchior FRANZ <mfranz@...> wrote:

>   (K      ... almost all US airports

Except P for Hawaii (PH), Alaska (PA), and former and current U.S.
territories.  Additionally, individual states use three- or
four-letter designators for very large number of airports that do not
have ICAO codes.  For example, from our current database, NY17, NY28,
NY55, NY82, NY87, etc.


All the best,


David

--
http://www.megginson.com/

* David Megginson -- Sunday 26 March 2006 15:27:
> On 26/03/06, Melchior FRANZ <mfranz@...> wrote:
> >   (K      ... almost all US airports
> 
> Except P for Hawaii (PH), Alaska (PA), and former and current U.S.
> territories.  Additionally, individual states use three- or
> four-letter designators 

Yeah, whatever. I'm fixing an absolutely crappy and useless
implementation, and the fix is already infinitely better. I never
said it's perfect already.

m.

On 26/03/06, Melchior FRANZ <mfranz@...> wrote:

> Yeah, whatever. I'm fixing an absolutely crappy and useless
> implementation, and the fix is already infinitely better. I never
> said it's perfect already.

Thank you very much for that, Melchior.  None of this is intended as a
criticism of your work, only of the bizarre complexity of airport
codes in the first place.


All the best,


David

--
http://www.megginson.com/

* David Megginson -- Sunday 26 March 2006 15:44:
> None of this is intended as a criticism of your work, only of
> the bizarre complexity of airport codes in the first place.

OK. :-)   Of course, more fine-grained selections would be nice.
A combobox with predefined search expressions for all countries
could do that now. More can be added once we have the data in our
DB, which isn't the case now as Paul has pointed out. Let's start
with a first step.

m.

* Melchior FRANZ -- Sunday 26 March 2006 09:47:
> I'm still investigating if this change works with all our dialogs.
> Maybe one would have to add a "dialog-update" on some places.

Yes, indeed. Comboboxes need a "dialog-update", as well as the
frequency swapper buttons in the radio dialog, and probably a few
more. Alternatively one could add a <no-update> tag for the that
prevents auto-update.

m.

--- Melchior FRANZ wrote:
> The airports list is barely usable: there are so many entries
> in it that you don't easily find anything. And the slider resolution
> is much too high for finding an entry with it alone. Move it
> just one pixel, and you jumped over oodles of airports. The arrow
> buttons have no repeat function, so they are of limited help, too.
> I've now hacked the airports widget to allow filtered lists:
> 
>   http://members.aon.at/mfranz/airports.jpg  [30 kB]
> 
> m.

That's a great improvement. It makes the airport list way more useful.
While filters by area would be nice, just allowing users to search for
their local airport is going to make things much easier for newbies.

BTW, I have a text file with the mapping from ICAO prefixes to country
names that I wrote a while ago for a mission generator project if you want
it. Might save you some time if you're thinking of enhancing it further.

-Stuart


		
___________________________________________________________ 
NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/

* Melchior FRANZ -- Sunday 26 March 2006 17:00:
> * Melchior FRANZ -- Sunday 26 March 2006 09:47:
> > I'm still investigating if this change works with all our dialogs.
> > Maybe one would have to add a "dialog-update" on some places.
> 
> Yes, indeed. Comboboxes need a "dialog-update", as well as [...]

Um, no. I take that back. They work fine.  :-)

m.

* Melchior FRANZ -- Sunday 26 March 2006 17:00:
> Yes, indeed. Comboboxes need a "dialog-update", as well as the
> frequency swapper buttons in the radio dialog, [...]

No. This was caused by updating plib to CVS/HEAD, which seems to be
broken. Works with  $ cvs up -D'2 weeks ago'.

I haven't found any problems with other dialogs so far, and I'd
suggest to consider that for inclusion before the 0.9.10 release.

I've fixed a minor bug in the airports.xml dialog file:

  http://members.aon.at/mfranz/airports.tar.gz  [2 kB]

m.

* Buchanan, Stuart -- Sunday 26 March 2006 18:01:
> BTW, I have a text file with the mapping from ICAO prefixes to country
> names that I wrote a while ago for a mission generator project if you want
> it. Might save you some time if you're thinking of enhancing it further.

I have such a file, too (country.nas), but it can't hurt to compare that with
your version and the Wikipedia page. Yes, please send it to me. Thanks.

m.

On Sun, 26 Mar 2006 11:26:41 +0200
Paul Surgeon wrote:
>
> The best would be to have a country and state/province field in the
> airport DB and that would need to come from Robin Peel unless we want
> to have a different DB again.

We could straddle the fence and have a second file which maps
airport identifier to some sort of geopolitical info, and we
maintain just that.

Not that that won't be a pain in the butt itself.

-c

--=20
Chris Metzler			cmetzler@...
		(remove "snip-me." to email)

"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear

On Sunday 26 March 2006 10:26, Paul Surgeon wrote:
> On Saturday 25 March 2006 19:48, David Megginson wrote:
> > On 25/03/06, Melchior FRANZ <mfranz@...> wrote:
> > > The airports list is barely usable: there are so many
> > > entries in it that you don't easily find anything. And the
> > > slider resolution is much too high for finding an entry
> > > with it alone. Move it just one pixel, and you jumped over
> > > oodles of airports. The arrow buttons have no repeat
> > > function, so they are of limited help, too. I've now
> > > hacked the airports widget to allow filtered lists:
> > >
> > >   http://members.aon.at/mfranz/airports.jpg  [30 kB]
> >
> > We need to get geopolitical information into our airport
> > list, at least at the country and region
> > (state/province/etc.) levels -- that could make the
> > filtering much more useful.  Proximity filtering might also
> > be nice, but that's a much bigger job.
> >
> >
> > All the best,
> >
> >
> > David
>
> I did do some work on that a long time ago using the ICAO
> codes to break up the data by country but ran into a couple of
> problems.
>
> 1. There is no state/province field in the airports db and it
> can't be deduced from ICAO codes.
> 2. There are a couple of areas in the world that share the
> same ICAO code even though they belong to different countries
> so using the ICAO code isn't a 100% accurate method.
>
> The best would be to have a country and state/province field
> in the airport DB and that would need to come from Robin Peel
> unless we want to have a different DB again.
>
> Regards
> Paul

I think we could identify the appropriate countries accurately 
using the geometric stuff in postgres (dunno if other dbms have 
the functions and datatypes).

Basically, I believe we would have to take the country outlines 
and use them to define geometrical shapes that can then be used 
in a query to see, from the lat/lon which shape (country) an 
airfield is in.

That doesn't address how we would use results though - they'd 
either have to be used as an additional index/look-up file or to 
be merged in to the existing airports file, breaking 
compatibility.

LeeE

On Monday 27 March 2006 18:45, Lee Elliott wrote:
> I think we could identify the appropriate countries accurately
> using the geometric stuff in postgres (dunno if other dbms have
> the functions and datatypes).
>
> Basically, I believe we would have to take the country outlines
> and use them to define geometrical shapes that can then be used
> in a query to see, from the lat/lon which shape (country) an
> airfield is in.
>
> That doesn't address how we would use results though - they'd
> either have to be used as an additional index/look-up file or to
> be merged in to the existing airports file, breaking
> compatibility.

Now that would be a really cool way to do it!
We could easily go down the the state/province level and even take it furthur 
and have a function that does a "fetch all airports within X miles of this 
city/town".

Why have a separate look-up file or a merged airports db? Why not just add a 
PostgreSQL driver and shapefile driver to FG with a directory of shapefiles 
and do the calculations in real time with a map interface?  :D

Paul

On Monday 27 March 2006 19:28, Paul Surgeon wrote:
> On Monday 27 March 2006 18:45, Lee Elliott wrote:
> > I think we could identify the appropriate countries
> > accurately using the geometric stuff in postgres (dunno if
> > other dbms have the functions and datatypes).
> >
> > Basically, I believe we would have to take the country
> > outlines and use them to define geometrical shapes that can
> > then be used in a query to see, from the lat/lon which shape
> > (country) an airfield is in.
> >
> > That doesn't address how we would use results though -
> > they'd either have to be used as an additional index/look-up
> > file or to be merged in to the existing airports file,
> > breaking compatibility.
>
> Now that would be a really cool way to do it!
> We could easily go down the the state/province level and even
> take it furthur and have a function that does a "fetch all
> airports within X miles of this city/town".

Heh :)  you can already do this using the lat/lon co-ordinates - 
I put the airfield and ils lists in to a db just to mess about 
with this sort of stuff.

>
> Why have a separate look-up file or a merged airports db? Why
> not just add a PostgreSQL driver and shapefile driver to FG
> with a directory of shapefiles and do the calculations in real
> time with a map interface?  :D
>
> Paul

Perhaps, in the longer term, it would be a good idea to 
incorporate a db engine into FG but in the shorter term I think  
the developers are probably pretty busy enough as it is.

A look-up table might be feasible though.  It shouldn't take too 
much space but would have to be re-generated every time Robin 
Peel updated.  Dunno what options are available re run-time 
access of the file or how long it would take to search (assuming 
that we don't want to hold the entire thing in mem)

Hmm... perhaps a background script could monitor the current 
situation and manage the info...

LeeE

* Melchior FRANZ -- Sunday 26 March 2006 09:47:
> BTW: this is not in CVS because of the feature freeze *and* a
> necessary change in fg_command.cxx

I've now committed that along with other changes to the gui/dialogs,
despite these reasons. It has a very limited range of possible side
effects (GUI only, and this is well tested), it's a great usability
improvement (IMHO) ... and I fixed four(?) old, unrelated crash bugs
in the last days, so I should be allowed to introduce new bugs. ;-)
Just kidding, of course it's bugfree ...

m.