On 09/16/2011 04:47 AM, HB-GRAL wrote: > I provide a ESRI Shapefile on my server of the airports of > ourairports.com database > http://maptest.fgx.ch/data/ourairports.zip > > There is a column "type", and some airports have value "closed". All > this data is in public domain, if someone wants to play around with it > or want to check something.
Thanks, that's interesting. For some purposes, the ESRI files may or not be the most useful or transparent representation; for some purposes it may be more useful to look at http://www.ourairports.com/data/airports.csv http://www.ourairports.com/data/runways.csv http://www.ourairports.com/data/airport-frequencies.csv and other files as described at http://www.ourairports.com/data/ The data from ourairports is in some ways more sophisticated than from apt.dat. For example, it gives the elevation of *each end* of each runway, rather than simply field elevation. In some parts of the world this is valuable information for pilots. AFAICT the ourairports data could be used to provide useful information for airports that are missing from apt.dat ... maybe not ideal but way better than nothing. Somebody could write a script to do the translation ... or we could just read the ourairports files directly. OTOH apt.dat has taxiway information for some airports, whereas I don't know of any such information at ourairports.com. If I have overlooked something, please let me know. FWIW I have a prog that reads apt.dat and writes kml, which can then be imported into your favorite GIS such as GRASS or google-earth. The idea is to make it easy to compare apt.dat to the ground truth. I haven't taught it how to read ourairports databases, but that wouldn't be hard. Here is another way in which the ourairports database can be put to very good use: It provides ISO region codes -- which apt.dat does not. These codes provide the basis for a very good way of predicting which runway numbers will have a leading zero. Compared to guessing "always leading zero" or "never leading zero" this reduces the error rate by at least two orders of magnitude. Doing a join on the two databases is easy. As for the reliability, comparing ourairports to apt.dat on fields that they both provide, it appears we have a Venn diagram with all five possibilities: -- Airports where they are both correct. -- Airports where apt.dat is right and ourairports is wrong. -- Vice versa. -- Airports where they are both wrong in different ways. -- Last but not best, airports where they are both wrong in the same way, so we don't learn anything by cross-checking. For example, there are some airports that were wiped out and replaced with condos many years ago, but still show up in both databases. FWIW here are the fields in some of the ourairports files: Airports: "id","ident","type","name","latitude_deg","longitude_deg","elevation_ft","continent","iso_country","iso_region","municipality","scheduled_service","gps_code","iata_code","local_code","home_link","wikipedia_link","keywords" Runways: "id","airport_ref","airport_ident","length_ft","width_ft","surface","lighted","closed","le_ident","le_latitude_deg","le_longitude_deg","le_elevation_ft","le_head ing_degT","le_displaced_threshold_ft","he_ident","he_latitude_deg","he_longitude_deg","he_elevation_ft","he_heading_degT","he_displaced_threshold_ft", Frequencies: "id","airport_ref","airport_ident","type","description","frequency_mhz" ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
