Discussions on Airport
Start a New Discussion
-
-
I think this would help with the auto-complete.
-
Some of the ones which are in common use (e.g. LAX) are already listed as aliases. It certainly wouldn't be very hard to add them all programatically, but I wonder how often they'd really get used. Where do you see this as being useful?
-
Hi,
I think it would help with auto-complete. Many locals most likely call their airport by the airport code. Correct me if I wrong since I'm new to freebase, but if someone types in an IATA code when it is not an alias then it won't show up in the auto-complete drop-down box.
-
The search index used for autocomplete is drawn from multiple sources. In addition to names and aliases, it includes alternate Wikipedia names, link anchor text from the articles, etc. For example, CDG will bring up de Gaulle airport even though CDG isn't an alias.
Personally, I don't use the codes for any of my local airports, but do for some remote ones, particularly if they're famous or it's a multi-airport city. Having said that, there are enough included already that I doubt people would object if you wanted to add them all. If you'd like to pursue this and don't have the programming skill/resources, feel free to contact me off-line (same name on gmail).
-
-
-
I think it should because it has a iata code.
-
Yes, you're right. Feel free to just go ahead and make changes like this.
I added the Airport type, but the IATA code is already in use by the Whale Pass airport topic that you added. If you flag it for merger, the two topics will be merged immediately (because you're the creator of the new one and no one else has edited it yet).
-
-
-
Typically, Wikipedia has two articles for airports which have both civilian and military users (see for example McGhee Tyson Airport vs McGhee Tyson Air National Guard Base). What should we do with these, and if the answer is "keep separate", which one should get the IATA/ICAO code?
-
I'd follow OurAirports.com lead. They're the domain experts here.
In this case, they've only got an entry for the airport and not the airbase. I don't see a problem with having a separate topic/article for the National Guard base since it's a distinct entity resident at the airport.
-
Kind of like a Starbucks? ;)
-
In this case, I think we can say that McGhee Tyson Airport is an airport (with both civilian and military use), and McGhee Tyson Air National Guard Base is a military base.
-
Done, and I may do a few others this way as well.
-
-
-
While browsing the Airport Coder, I have stumbled on several cases where the IATA code of an airport is already in use by anoter airport. Normally, this would not be a reason to post it here, but this seems to be a pretty regular case:
The Wikipedia description claims that the IATA code of an US airport is the same as that of a non-US airport. In most - if not all! - cases, it seems like someone just stripped a leading "K" of the ICAO code. To me it seems like if that the IATA code is correct for the non-US airport in most cases, and the "ICAO-K" code matches some code by some organization called FAA.
Example case: - Talhar Airport - World Airport Database - Bend Municipal Airport - World Airport Database
I wonder whether there is a more reliable source than Wikipedia, which could help to fix some seemingly incorrect IATA codes on US airports automatically.
-
The FAA code is not the same thing as the IATA code. Sometimes they correspond, but not always. The data we've been collecting at http://www.ourairports.com/ is probably more accurate.
-
Yep, FAA codes and IATA codes do not have a strict relation. I just thought it might be good to find out those invalid ones in Wikipedia and Freebase and either add the correct IATA code or set it to something similar to None - if something like that exists. That would reduce probably incorrect information and the risk of someone trying to merge some not related topics by using the Airport Coder.
-
Personally, I'm not too concerned if a pair of airports gets inappropriately flagged for merge: that will go into the review queue, where I'm confident someone will spot the problem and vote it down. The more difficult area is where the correctly coded airport doesn't exist in Freebase yet, in which case we end up with incorrect data.
-
Yes, reconciling directly with airports.csv from http://www.ourairports.com/data/ and/or the official UN location code database would probably produce better (or at least more traceable) results, but we'd still have the issue of reconciling back to Wikipedia articles and figuring out which code was correct in the case where they differ.
I don't think adding "None" to things is a good idea, since it's hard to prove a negative. Better just to leave it blank.
-
-
-
There is data available from FAA that I could inject that has a column for : CustomsAirportOfEntry E79 Facility has been designated by the U.S. Treasury as an international airport of entry for customs (ex. Y - yes, N - no)
There is also plenty of data for Airport Facilities that could be injected such as : http://www.faa.gov/airports/airport_safety/airportdata_5010/nfdcfacilitiesdictionary.cfm
I'd be happy to help. Regards, Thad
-
That does sound like useful data - perhaps you could model some properties that are not on the current commons airport type in a personal airport type and we can promote from there?
-
Sure thing, Bryan. I'm still researching the FAA guidelines and other generalities, but once done, then I'll model the extended properties in my personal type.
-
-
-
Shouldn't the airport database carry a "aircraft parking stands" field?
-
We can add a property for aircraft parking stands, but I can't seem to find any good datasource for loading this information. Is there a specific application or use that you need this data for?
-
I would be in favour of having this property with a type and a quantity, so that you could record that a particular airport had X tie-downs, Y t-hangars, Z regular hangar spaces, etc.
This data might be available from the data from the FAA National Flight Data Center, however my project to start updating Freebase from that data got shelved as work and home life got in the way. I hope to pick it up again soon.
-
Hi,
my goal was to have data about free space and the amount of flights to get a average rotation number and copare with best pratice on other airports.
-
We can certainly add properties for this data; if you can direct me as to what specific properties you would like to be added, ptomblin or I can add them to the proper schema.
I did look up a couple of airports on the FAA NFDC and wasn't able to find data about aircraft parking stands or tie-downs, or hangars. Advice on where else to look?
-
-
-
Currently there is no way to document start and end dates for hubs. For example, American Airlines had a hub at RDU from 1987 to 1996. Hubs change somewhat often so treating hubs as a dynamic airport property with start and end dates would be more appropriate than just documenting whether or not an airport is currently a hub.
-
Ed - this brings up a bigger thing I've been thinking through. So many properties in Freebase could be time-series. Right now I'm working on US Congress information and I keep coming back to the dichotomy between the current information (who is in Congress right now) and the historical information (who has been in congress). These represent distinct use cases, but as data modelers we would like to use the same representation for both. Unfortunately, this often adds complexity to the typical case (show me what airlines are currently at SFO) in support of the rarer case (show me all of the airlines that have been at SFO).
I think that in this case the property should be renamed to "current airlines" with a simple (non CVT) relationship between the airport and the airline. If historical information is important, we could add a "airlines (historical)" property that uses a CVT for each item to encode start and end times.
The danger of data modeling is that we (myself especially included) are beguiled by the representation power of our models. I think our goal should be to support the practical case first even if it makes the more general case harder.
-
I agree with all of this. My primary concern is that good data will be erased when the property is updated, which will happen if it is not static and not maintained as a dated value that is not restricted to a single entry (triple negative!).
Also, dated information would be very useful for timelines as someone else recently brought up. Is the purpose of Freebase only to hold the most recent of all data? Currently, I could list the current hub and have the "date established" in hand but nowhere to put it. True, not many people will be interested in studying the dynamics of hub distributions since the advent of commercial airlines but why restrict them from being able to do so just because it isn't a popular activity.
The parsimonious approach would be an unrestricted dated property where the most recent value does not have an end date. This would be relatively easy to query conceptually (although maybe not progammatically), especially to find "no data" entries such as missing congressional entries within the period 1860-1865. What if I'm writing a history report and want to know about all the Congressmen from North Carolina during the civil war. Is such a case so impractical as to not be supported? Is the goal practicality or simple flexibility?
An historical property could work just as well for storage but add unnecessary complexity IMO, especially when updating the information. If the hub changes hands or leaves, the user would need to modify the current hub property, fill in the historic hub name which was already associated in the current hub property, look up the established date to fill in that part of the historical property, and add the end date. With a single dated property the user would only need to add the end date to the existing hub and possibly start a new entry with the same date.
Devil's advocate: If it isn't a static description, why not make a time-series description by default?
-
-
-
OK, I had to look it up, and according to Wikipedia: "In the airline industry, a focus city is a location that is not a hub, but from which the airline has non-stop flights to several destinations other than its hubs." So, a focus city is basically anywhere an airline flies direct that's not also its hub? Is that basically the working definition in Freebase?
Either way, I'd like to see it documented. :)
-
I started filling out my local airport and realized that the "Destination city" of airlines should be replaced with "Destination airport". The airlines fly between airports, not between airports to cities. This change will also allow reciprocation of focus airports (not cities) through the airline's "Destination cities" property, which in my opinion is redundant with "Focus city". Some really interesting networking applications could be built if the airport data model was changed in these ways. Currently, airport to airport queries need to go through an unnecessary query from airport from city to airport to make these connections.
-
Hi Ed, where are you seeing the "Destination city" property? I didn't see it in the Airport schema. Otherwise I agree with what you said.
-
Faye, I believe Ed is talking about the Cities Served property of Airline, which he followed from his local airport. This part of the discussion should probably move over there if it continues.
-
Faye, "Destination city" comes in through the Airline Airport Presence CVT under the Airlines property expected type. That would probably be the best place to move this discussion.
-
Ah, OK. And amazingly enough, after looking over the correct schema, I still agree. :)
-
-
