Menu
▾
▴
flightgear-devel
|
From: Melchior F. <mf...@ao...> - 2006-03-25 17:01:36
|
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. |
|
From: David M. <dav...@gm...> - 2006-03-25 17:48:19
|
On 25/03/06, Melchior FRANZ <mf...@ao...> 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/ |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 07:47:16
|
* 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. |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 15:00:45
|
* 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. |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 16:51:13
|
* 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. |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 17:53:57
|
* 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. |
|
From: Melchior F. <mf...@ao...> - 2006-03-31 10:39:13
|
* 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. |
|
From: Paul S. <su...@te...> - 2006-03-26 09:26:25
|
On Saturday 25 March 2006 19:48, David Megginson wrote: > On 25/03/06, Melchior FRANZ <mf...@ao...> 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 |
|
From: David M. <dav...@gm...> - 2006-03-26 11:49:30
|
On 26/03/06, Paul Surgeon <su...@te...> 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/ |
|
From: Paul S. <su...@te...> - 2006-03-26 12:40:28
|
On Sunday 26 March 2006 13:49, David Megginson wrote: > On 26/03/06, Paul Surgeon <su...@te...> 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 |
|
From: Chris M. <cme...@sp...> - 2006-03-27 02:31:59
Attachments:
signature.asc
|
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 cme...@sp... (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 |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 13:11:48
|
* 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. |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 13:18:31
|
* 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. |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 13:19:51
|
* Melchior FRANZ -- Sunday 26 March 2006 15:11: > (K ... almost all US airports ... with IACO codes, that is. :-} m. |
|
From: David M. <dav...@gm...> - 2006-03-26 13:27:20
|
On 26/03/06, Melchior FRANZ <mf...@ao...> 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/ |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 13:34:42
|
* David Megginson -- Sunday 26 March 2006 15:27: > On 26/03/06, Melchior FRANZ <mf...@ao...> 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. |
|
From: David M. <dav...@gm...> - 2006-03-26 13:44:22
|
On 26/03/06, Melchior FRANZ <mf...@ao...> 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/ |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 13:50:48
|
* 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. |
|
From: Buchanan, S. <stu...@ya...> - 2006-03-26 16:01:48
|
--- 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/ |
|
From: Melchior F. <mf...@ao...> - 2006-03-26 17:55:08
|
* 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. |
|
From: Lee E. <le...@sp...> - 2006-03-27 16:45:48
|
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 <mf...@ao...> 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 |
|
From: Paul S. <su...@te...> - 2006-03-27 18:28:20
|
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 |
|
From: Lee E. <le...@sp...> - 2006-03-28 21:54:53
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X