Discussions on Aviation

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?

Wacky; I would have thought that would have come along for the ride. I'll have to figure out how to rename the automatically-created type views.

Silly me; changing the name is easy if you're logged in as a domain administrator.

Thanks!

I kind of lost interest and time to work on Freebase, but which database is this? Is it the FAA NFDC data, or something different?

Yes. The NFDC data.

If you want to get that data in an extended GPX format, you can get it from my website http://navaid.com/GPX/

I tried to get all this data into Freebase for just that reason back when Freebase was pretty new, and I got told that stuff like the runway designations and lengths and communications frequencies wasn't of general interest, so it probably shouldn't go in. That's basically why I lost interest in freebase.

Sounds good to me. The only thing I'm not sure about (I haven't looked very hard though) is whether the IATA designator is non-unique in that an airline can have more than one or non-unique in that one code is used by more than one airline, as its only the latter which would prevent us using an enumeration.

IATA's non-uniqueness is the bad kind. The codes can be used by multiple carriers in two ways: First, by old codes being reused (if an airline goes out of business, say), which we could probably handle by deciding only to deal with current data; but, Second, IATA also uses something it calls "controlled duplicates", which means that airlines which operate in different regions can have the same codes (e.g., ATA and Air-taxi Europe both have the code TZ).

The Spirt of St. Louis has been typed as an Aircraft Model as well. Any progress on a type for instances of an aircraft? Can we get the name of /aviation/aircraft_model changed from 'Aircraft' to 'Aircraft Model' so that people know they're choosing the wrong type?

+1 To a new aircraft type (== aircraft instance), and renaming aircraft to aircraft model.

I can't think of a good reason for this; I'll open a JIRA task to get the permissions changed.

Took care of it - happy editing!

yes, on that note, this type should not have a fatalitites property, as disaster models that

This is a really good point; the puddle-jumper airlines that are actually operated by multiple carriers break the model. Perhaps an airline should be operated by one or more companies; in some cases, they may have the same name, but it would also make sale of airlines easier to model.

tfmorris - Check out the Delta connection page and see that it is indeed "operated by multiple carriers."  If you can find the legal entity for Delta Connections, by all means do. I've checked D&B and I can't find it (same with some others). 

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?

+1.

I think an airport is really composed of structures (Terminals, hangers, etc.) infrastructure (roads, airstrips, light-rail people movers, etc.).

Maybe it should be typed as a new type, facility, of which a property could list structures. That could have many of the properties in common with structures plus some locational ones like area, containing, etc.

While I agree that there are multiple structures that comprise an airport, I think the structure that most people are interested in and have information for is the airport terminal itself. Perhaps airport could better be expanded with properties for number of hangers, etc.

It seems to me that the Airport type itself should have opening and closing dates, since these are unrelated to the opening and closing dates of the terminals themselves (some of which are already typed as structures: http://www.freebase.com/view/guid/9202a8c04000641f80000000045b2256). Adding a "Terminals" property (and corresponding "Airport Terminal" type) might be the way to go.

Until someone more knowledgeable about data modeling/aviation can answer, here's my two cents. I think the properties you have on your Runway Supplemental type should really be added to the Runway type itself...after all, what does it mean for something to be typed as a Runway Supplemental? Especially if all runways have the properties you want to extend runways to have... If, on the other hand, there is something special about these properties, perhaps the type name should be changed (I've looked at the type and it doesn't appear so).

In any case, since Runway is a published type, I believe the domain administrators should will have something to say about this. Also, if I understand the problem correctly, I think this is your only hurdle in adding data, and it seems like the issue can be solved simply by a domain admin extending the Runway type directly.

Speaking of types and properties outside of this context, it's interesting that cvt's can't be added as cotypes. For instance, if I wanted to create a type of film performance called "Academy award-nominated film performance" (dumb but for the sake of argument...) I wouldn't be able to include Film Performance properties. It's been a while since I read the documentation or Jamie's dev blog post, so maybe someone take pity and explain why this is so?

So how *does* one get the administrators to add properties to a published type? I'd really like to add width (in metres), beginning geolocation, beginning elevation, end geolocation, end elevation to the runway definition type.

Robert seems to be the only Aviation domain admin currently. I suggest you make a request right here to become one as well, if you want to take things into your own hands (which you seem to want, for sure :-) ) The powers above will heed your call in some form or another.

Paul -- I'm definitely not a domain expert in this case. However, I am a pretty seasoned data modeler. I can work with you to extend the existing types to your satisfaction. (By the way, we will introducing a new kind of admin called a "domain expert", which will have powers and responsibilities different from the data modeling that an admin must do.)

Was your intention that the properties on Aerodrome be added to the Airport type?

What is the property on Aerodrome "Instrument Approach" used for? Could you populate it with some examples (this is a normal part of the data modeling process - we create examples before making them official.)

What is "Communications Frequency" used for? In your example, you have two instances with only "Ground" and "Tower". The type "Communications Frequency" is a compound value type. Is your intention that these should be visible in your "Aerodrome type"?

Robert, I have a type "AviationWaypoint" that is basically a "base class" for aviation things that have a location and an identifier. The identifier can be either an ICAO id or a local (ie FAA) id, but it has to have one id to key off of. Then the subclasses of that type are Aerodrome, Navaid, and Fix. These types encapsulate information that is useful for flight planning and inflight use, rather than people looking for interesting facts about the airport. Pilots planning a flight to an airport don't care if Delta runs flights there or not, but they sure care whether the tower frequency is 118.3MHz. I can see arguments for keeping the properties of the Aerodrome separate from Airport, or for combining them.

- I intend to just list the names of available instrument approaches in the "Instrument Approach" property. Later on, they might be linked to the FAA/NACO PDFs of the approach plates. The name of an instrument approach tells you what type of approach it is, and what runway it approaches, so a pilot might be interested to see if an airport has a precision approach or GPS approach and whether it approaches a runway that would be in use based on today's wind conditions. I haven't entered any example data because I left my approach plates in the plane and I was too lazy to look them up on airnav.com.

- "Communications Frequency" are the frequencies used for air to ground and air to air communications at that aerodrome. They use a short code for the frequency type ("CTAF", "GND", "TWR"), the frequency in MHz, and a longer name.

- The biggest change I want to add to the existing data types is that I could really use some new properties in the "Airport runway" type:
- width (metres)
- start location (geolocation)
- start elevation (metres)
- end location (geolocation)
- end elevation

Paul -- I haven't forgotten you -- I've been juggling a lot of things. I'll take these on either tomorrow or over the weekend. Sorry for being a bottleneck.

Paul -- I've created "Aviation Waypoint" in the official Aviation domain. I made a few modeling changes, however:

- I made the Aviation ID of type "string" rather than text -- this ensures that it has machine readable characters only. This is typically what we do for IDs of this sort

- I removed the location-based properties and added the included type "location". This will ensure that all waypoints can have as much location information as you want -- which country, city, etc, and geolocations.

- I recreated your Waypoint type here, but didn't repopulate it with the enumerations yet.

Let me know what you think:

http://www.freebase.com/view/filter/aviation/aviation_waypoint

http://www.freebase.com/view/schema/aviation/aviation_waypoint

Paul, also, airports already have two ids, the IATA designation and the ICAO designation. Is the Waypoint ID supposed to be the same as one of these?

Paul -- I extended the runway type to include width.

Regarding the start and end locations of the runway, how would these normally be encoded? Are they geolocations or some other kind of representation?

http://www.freebase.com/view/schema/aviation/airport_runway

I added in placeholders for those locations, but I didn't make them visible in the UI from the airport type (they are not disambiguators) because they would appear as long hex strings because they would be unnamed. We may have to create a fix for this. Understanding your goal here will help us out a lot.

Thanks Robert. Let's see if I can answer all your questions and ask a few of my own:

- You took out state/province and country. Is it your intention that those would go in the "Contained By"?

- As well as ICAO and IATA ids, aviation waypoints can also have "local" ids such as those assigned by the FAA or even by private enterprises (for instance, small airports in the UK don't have official ids, but a publication called "Pooles" evidently assigns ids), and there are also military and "UNcode" ids but I'm not sure if anything but FMSes use them. I thought I'd eliminate the need to do lots of "OR" queries by making one unified id, but maybe just an additional "localID" field as well as the ICAO and IATA ids. Oh, and dual use (miltary/civil) airports can have multiple ids. Horrible, isn't it?

- The start and end locations are geolocations. One of the applications I support uses the end points (and widths) to draw a simple airport diagram. The "Direction" field is quite good enough for disambiguation.

I hope this helps.

>- You took out state/province and country. Is it your intention that those would go in the "Contained By"?

Yes. By co-typing as a location it means that you can query these more easily. Also state/province is not an international concept.

The location properties allow you to give as much precision as you want down to specific geo-coordinates or 'contained by' something as large as a city, state or country.

>- As well as ICAO and IATA ids, aviation waypoints can also have "local" ids such as those assigned by the FAA or
> even by private enterprises (for instance, small airports in the UK don't have official ids, but a publication called
> "Pooles" evidently assigns ids), and there are also military and "UNcode" ids but I'm not sure if anything but FMSes
> use them. I thought I'd eliminate the need to do lots of "OR" queries by making one unified id, but maybe just an
> additional "localID" field as well as the ICAO and IATA ids. Oh, and dual use (miltary/civil) airports can have multiple
> ids. Horrible, isn't it?

Yes, a bit scary. Normally, we're careful to tease apart 'namespaces'. That is, and ID property should map to only one type of IDs. That's why they are separated in the Airport type. I'm not sure if I undertand exactly, but are you saying that waypoints have an additional ID system?

> - The start and end locations are geolocations. One of the applications I support uses the end points (and widths) to
> draw a simple airport diagram. The "Direction" field is quite good enough for disambiguation.

The way the UI currently works makes locations as part of a "compound value" difficult. I'll talk with some people here to see what might be possible.

>Also state/province is not an international concept.

Yeah, I know, you call it "Administrative Division". But since I only use it for the US and Canada, I refer to it as "State/Province" even if it has a type of "Administrative Division". Speaking of which, my type "AviationWaypoint" had a property called "State/Province" which *had* a type of "Administrative Division" last time I looked, but now it appears to have a type of "Topic" and I can't change it back without deleting them all. How did that happen? (Also, the geolocations of one of my test points lost its latitude - I know it's alpha, but is this sort of thing going to happen a lot?)

>are you saying that waypoints have an additional ID system?

Several, if you really want to tease things apart. You could merge the FAA and other non-ICAO/IATA ids into something like "local id" (and allow more than one). But I sure don't relish the thought of coding all those "OR" queries trying to find a waypoint by id.

>>Also state/province is not an international concept.

> Yeah, I know, you call it "Administrative Division". But since I only use it for the US and Canada, I refer to it as
> "State/Province" even if it has a type of "Administrative Division". Speaking of which, my type "AviationWaypoint" had
> a property called "State/Province" which *had* a type of "Administrative Division" last time I looked, but now it
> appears to have a type of "Topic" and I can't change it back without deleting them all. How did that happen? (Also,
>the geolocations of one of my test points lost its latitude - I know it's alpha, but is this sort of thing going to happen a
> lot?)

For something like Aviation particularly, it is really necessary to support international users. Co-typing with "location" will still allow you to show what you want but in a more normalized way that's easier to query in all circumstances.

As far as the "topic" instead of "administrative division", I suspect this is because the schema builder interface is a bit touchy. There are still a couple of known bugs around this, and they'll be worked out.

As for the other problem with apparent data loss -- could you revisit the geolocation? There was a bug introduced this last cycle that makes data look like it's disappearing when you enter it, visit another page and then use the browser back arrow to visit the page you edited. The changed you made aren't visible, but if you hit refresh they appear (and are stored in Freebase.)

>>are you saying that waypoints have an additional ID system?

>Several, if you really want to tease things apart. You could merge the FAA and other non-ICAO/IATA ids into
>something like "local id" (and allow more than one). But I sure don't relish the thought of coding all those "OR" queries
>trying to find a waypoint by id.

I could understand that. My worry is that if you combine all of the IDs into a single property they may 'collide'; that is, two from different systems could have the same value.

Ok, this is strange: my home page shows a reply in this thread, but I don't see it when I come here. Is this normal?

Ok, I accept the need for lots of OR queries then.

Can we add "ICAO id" and "IATA id" to Aviation Waypoint without it conflicting with the properties of the same name in Airport? We can rename "AviationID" to something like "Local Aviation Authority id" (or just add that as a description for the field) which can be used for FAA or other local non-ICAO ids. It can accept multiple values, which means it can be used for all the additional systems.

As for ids colliding, that bird has already flown - the ICAO codes for navaids are not unique. There are 14 NDBs with the id "A", for instance. In my applications I go by the id and the country, and even that's not 100% guaranteed. My Garmin GPS, when I enter a waypoint id will often pop up a dialog saying "Do you mean the REEDO in Ontario Canada, or the one in Chile?"

Should I go ahead and populate the Waypoint Types?

Hi Paul -- I'm happy to work with you to add in some of these types to the aviation domain. In fact, if it makes sense, we could promote some of your existing types in your private domain.

Hey, Paul. On Freebase, I'm responsible for helping determine community roles. So I wanted to jump in and note that we're rethinking the administrator role, and I hope to have a draft on new guidelines ready for public review soon. Meantime, any work you do with Robert to improve the domain will, almost by default, help us further figure out the spectrum of rights and responsibilities that community members want and need.

Feel free to provide feedback on this particular issue on the Community Roles page:

http://www.freebase.com/view/discuss/%239202a8c04000641f8000000005b7e586

Thanks!
Sarah

Paul -

Look here: http://www.freebase.com/view/filter/aviation/airport
You should be able to filter by those identifiers on the left hand side.

Hope that's what you were looking for.

Yes, that's somewhat helpful, but I would like to be able to put "KROC" in the keyword search and find Greater Rochester International Airport. Instead all I get is Ray Kroc and a couple of radio stations.

The topic for the ICAO designation is currently the seventh item returned if you enter "KROC" in the search window. In order to have the topic for "Greater Rochester International Airport" itself show up, "KROC" would have to be entered in its "also known as" field.

I just added engine type and maximum speed.

I'm not sure how to model the armaments. Do you have an example someplace you could point to that suggests how the schema might be set up?

I have an armaments model on ship class: http://www.freebase.com/view/schema?id=%2Fuser%2Fpatrick%2Fdefault_domain%2Fship_class_v1_0 the armaments type definition is here: http://www.freebase.com/view/schema?id=%2Fboats%2Fwarship_armament This just combines a quantity with a specific Naval armament. I've noticed a number of systems that aren't specific to naval platforms, so am thinking that there should be a general armaments type that applies to everything from scud launching trucks to ships to aircraft. For example, the Harpoon anti-ship missile can be launched by ship or plane, and many shipborn AA guns are the same as used on land.

I tried a stab at this. I created a mediator with a really bad name "Airline Airport Presence" that may have to be changed. For any airline at an airport, it holds the destination cities and terminals.

Take a look.

Wow, you definitely put a lot of thought into it...I was thinking of literally just adding an Airlines property to Airport and vice versa and be done with it. :)

Is the Destination Cities property supposed to capture all the places an Airline flies to out of that Airport? If so, I think it should be Destination Airports of Type Airport, for symmetry. Airport already has a Serves property of Type Location to capture its service area.

I want to confirm that the semi-permanent associations of airline-destination-terminal implied by the compound value structure of the schema is intentional. I.e. if someone enters United Airlines - Seattle - 23 for the San Francisco International Airport and it's true today, it'd still be true a week later. If so, I'm fine with the compound type design.