Catalog metadata: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Add aerobatic, ultralight, avro tags)
(Replace quotes with text and references.)
Line 2: Line 2:


{{Package Management}}
{{Package Management}}
{{DeQuote}}


== Status / News ==
== Status / News ==
Line 14: Line 12:
* adding metadata tags, for better searching/usability the future  
* adding metadata tags, for better searching/usability the future  


All of these are intended to help users browsing the aircraft, via the launcher or other methods. James's proposal is to post about this on the forum, and ask for volunteers to pick aircraft, and submit patches / updates to myself and some other willing reviewers (Stuart has also volunteered as reviewer, more people are welcome). Aside form ensuring high quality, we also need to ensure that aircraft maintainers are given the opportunity to update their own aircraft. Any co-volunteers to manage the process, and especially suggestions on how to manage this in a way that is friendly towards aircraft maintainers, but also gives a reasonable chance, that 90% of aircraft in FGaddon have up-to-date metatdata by the next release, are welcome. I’m sure we will have the usual debate on subjectivity of ratings, but, that’s another thing the reviewers will have to deal with. (James Turner suggested there’s some criteria on the wiki from the last time we did this?) (There’s a task on me to link the tagging system into the aircraft search, so that searching on ‘fighter’ or ‘glass-cockpit’ brings up appropriate matches. This tends to work out anyway when aircraft have a long-description text, but it’s still very beneficial to the launcher to have some meta-data about how aircraft are used)<ref>{{cite web
All of these are intended to help users browsing the aircraft, via the launcher or other methods. James's proposal is to post about this on the forum, and ask for volunteers to pick aircraft, and submit patches / updates to myself and some other willing reviewers (Stuart has also volunteered as reviewer, more people are welcome). Aside form ensuring high quality, we also need to ensure that aircraft maintainers are given the opportunity to update their own aircraft. Any co-volunteers to manage the process, and especially suggestions on how to manage this in a way that is friendly towards aircraft maintainers, but also gives a reasonable chance, that 90% of aircraft in FGaddon have up-to-date metatdata by the next release, are welcome. I’m sure we will have the usual debate on subjectivity of ratings, but, that’s another thing the reviewers will have to deal with. (James Turner suggested there’s some criteria on the wiki from the last time we did this?) (There’s a task on me to link the tagging system into the aircraft search, so that searching on ‘fighter’ or ‘glass-cockpit’ brings up appropriate matches. This tends to work out anyway when aircraft have a long-description text, but it’s still very beneficial to the launcher to have some meta-data about how aircraft are used)
<ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35688820/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35688820/  
   |title = <nowiki> [Flightgear-devel] Improving FGaddon aircraft meta-data </nowiki>  
   |title = <nowiki>[Flightgear-devel] Improving FGaddon aircraft meta-data </nowiki>
   |author =  <nowiki> James Turner </nowiki>  
   |author =  <nowiki> James Turner </nowiki>  
   |date  =  Feb 26th, 2017  
   |date  =  Feb 26th, 2017  
Line 23: Line 22:
   }}</ref>
   }}</ref>


==Catalogs==


The overall aim is to support a decentralized development system with the only central point being the aircraft package manager for end users. 
<ref>{{cite web
    |url = http://sourceforge.net/p/flightgear/mailman/message/33413096/
    |title = <nowiki>Re: [Flightgear-devel] FGDATA split without Aircraft. Addon in SVN. (re)Suggesting a Submodule approach. (Re)Proposing a</nowiki>
    |author = <nowiki>James Turner</nowiki>
    |date = <nowiki>2015-02-13</nowiki>
}}</ref>.  Users can simply add a hangar URL for FGUK, Lake of Constance or similar, and browse those aircraft within the launcher. 


{{FGCquote
Most importantly we can improve the end-user browsing and discovery experience by enforcing some required meta-data, images and similar in the catalogs, and we can manage the install process so that users don’t get confused about where to move an aircraft file.
  |The tooling I’m working on (slowly) to generate the aircraft-package catalogs will also be able to generate data feeds for the website, and that could be dumped to any format anyone wishes (XML, JSON, CSV). That will certainly be the case for the aircraft pages on the main site (replacing / combining with Curt & Gijs’ existing tooling around that).
<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33586444/
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34127945/
     |title=<nowiki>Re: [Flightgear-devel] FGDATA and Jenkins </nowiki>
     |title=<nowiki>Re: [Flightgear-devel] Aircraft rating - request for review</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |date=<nowiki>2015-05-20</nowiki>
     |date=<nowiki>2015-03-11</nowiki>
  }}
}}</ref>
}}


{{FGCquote
fgmeta contains a 'create_catalog.py' script which runs over fgaddon but could be used against another aircraft store containing multiple aircraft to generate a catalog used by the launcher in combination with a webhost to publish aircraft to users.
  |the goal here is to almost get rid of a centralised aircraft repo anyway, and have a decentralised development system with the only central point being the aircraft package manager for end users. Then 99% of people never care where the aircraft is stored while it’s developed.
<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33550567/
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33413096/
     | title=<nowiki>Re: [Flightgear-devel] FGData size reduction </nowiki>
    |title=<nowiki>Re: [Flightgear-devel] FGDATA split without Aircraft. Addon in SVN.
(re)Suggesting a Submodule approach. (Re)Proposing a per-Aircraft
repository</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-02-13</nowiki>
  }}
}}
 
{{FGCquote
  | The goal is that no one except people working on an individual aircraft should care where it’s developed at all (on GitHub, in a private SVN repo, stored as sheets of paper in a filing cabinet). SCM systems are not distribution/release systems, we’ve simply been using them in that fashion by accident.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33550567/
     |title=<nowiki>Re: [Flightgear-devel] FGData size reduction</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |date=<nowiki>2015-03-06</nowiki>
     |date=<nowiki>2015-03-06</nowiki>
  }}
}}</ref>
}}
 
 
{{FGCquote
  |If you wish to dig into the package system, and create some tooling so it’s easy to publish releases from a Git repo to a web-host, please do. The current script is in fgmeta; see ‘create_catalog.py’ which runs over FGData of course, but you can imagine something similar for any SCM store containing several aircraft. There’s additional features that can be added of course, such as support for ‘beta’ or ‘testing’ versions of aircraft, being able to exist alongside stable versions. That would require some C++ hacking on the client side but pretty straightforward stuff I think.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33550567/
    |title=<nowiki>Re: [Flightgear-devel] FGData size reduction</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-03-06</nowiki>
  }}
}}
 
{{FGCquote
  |For all other aircraft, the intention for both these nightly builds and official releases is to use the aircraft catalog + package system, which is based around HTTP rather than an SCM system. I’m working at the moment on integrating the client parts into the launcher GUI.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33586444/
    |title=<nowiki>Re: [Flightgear-devel] FGDATA and Jenkins</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-03-11</nowiki>
  }}
}}


{{FGCquote
The catalog is just an XML file, and the other files needed are the thumbnail images for each package, and the package .zips themselves; the system is deliberately designed to be host-able statically on any web provider. The ‘create_catalog.py’ gives one example of creating a suitable catalog XML file, but any other approach is also valid.
  |This is the way to decentralise aircraft deployment and discovery - ‘we’ (the project) will provide an official hangar of course but the idea is any end-user can add the hangar URL for FGUK, Lake of Constance or similar, and get those aircraft. Most importantly we can improve the end-user browsing and discovery experience by enforcing some required meta-data, images and similar in the catalogs, and we can manage the install process so that users don’t get confused about where to move an aircraft file.<br/>
<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33586444/
<br/>
(Many end users struggle with the aircraft zips, they’re unsure if they need to extract them or not, and whereabouts to copy them, and what paths to set so the aircraft is usable. The package system is designed to avoid those issues)
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33586444/
     |title=<nowiki>Re: [Flightgear-devel] FGDATA and Jenkins</nowiki>
     |title=<nowiki>Re: [Flightgear-devel] FGDATA and Jenkins</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |author=<nowiki>James Turner</nowiki>
     |date=<nowiki>2015-03-11</nowiki>
     |date=<nowiki>2015-03-11</nowiki>
  }}
}}</ref>
}}
 
{{FGCquote
  |The catalog is just an XML file, and the other files needed are the thumbnail images for each package, and the package .zips themselves; the system is deliberately designed to be host-able statically on any web provider. The ‘create_catalog.py’ gives one example of creating a suitable catalog XML file, but any other approach is also valid.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33586444/
    |title=<nowiki>Re: [Flightgear-devel] FGDATA and Jenkins</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-03-11</nowiki>
  }}
}}
 
{{FGCquote
  |I am extending the meta-data in aircraft -set.xml files for the package system. We can already specify which aircraft are variants of another, and I can add the option to exclude aircraft from being packaged, or otherwise filter according to some criteria.
All of this is designed to make the end-user experience more sane and simple, while avoiding any restructuring on the backend side.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33692055/
    |title=<nowiki>Re: [Flightgear-devel] tu154 vs tu154b</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-04-02</nowiki>
  }}
}}
{{Package Management}}


== Supported Tags ==
== Supported Tags ==

Revision as of 21:58, 28 February 2017

Tags with catalog metadata can be added to aircraft to help searching and filtering them, for example in future versions of the aircraft center, so that a user can quicker find the aircraft of interest.

Status / News

Now that James has merged the preview and splash screen changes, he wants to start a concerted effort to improve the metadata of all the aircraft in FGaddon. This means:

  • ensuring there’s a suitable ‘long' description
  • adding / updating ratings
  • ensuring variant / primary info is correct
  • ideally adapting to the new preview/splash system, (but not required)
  • adding metadata tags, for better searching/usability the future

All of these are intended to help users browsing the aircraft, via the launcher or other methods. James's proposal is to post about this on the forum, and ask for volunteers to pick aircraft, and submit patches / updates to myself and some other willing reviewers (Stuart has also volunteered as reviewer, more people are welcome). Aside form ensuring high quality, we also need to ensure that aircraft maintainers are given the opportunity to update their own aircraft. Any co-volunteers to manage the process, and especially suggestions on how to manage this in a way that is friendly towards aircraft maintainers, but also gives a reasonable chance, that 90% of aircraft in FGaddon have up-to-date metatdata by the next release, are welcome. I’m sure we will have the usual debate on subjectivity of ratings, but, that’s another thing the reviewers will have to deal with. (James Turner suggested there’s some criteria on the wiki from the last time we did this?) (There’s a task on me to link the tagging system into the aircraft search, so that searching on ‘fighter’ or ‘glass-cockpit’ brings up appropriate matches. This tends to work out anyway when aircraft have a long-description text, but it’s still very beneficial to the launcher to have some meta-data about how aircraft are used) [1]

Catalogs

The overall aim is to support a decentralized development system with the only central point being the aircraft package manager for end users. [2]. Users can simply add a hangar URL for FGUK, Lake of Constance or similar, and browse those aircraft within the launcher.

Most importantly we can improve the end-user browsing and discovery experience by enforcing some required meta-data, images and similar in the catalogs, and we can manage the install process so that users don’t get confused about where to move an aircraft file. [3]

fgmeta contains a 'create_catalog.py' script which runs over fgaddon but could be used against another aircraft store containing multiple aircraft to generate a catalog used by the launcher in combination with a webhost to publish aircraft to users. [4]

The catalog is just an XML file, and the other files needed are the thumbnail images for each package, and the package .zips themselves; the system is deliberately designed to be host-able statically on any web provider. The ‘create_catalog.py’ gives one example of creating a suitable catalog XML file, but any other approach is also valid. [5]

Supported Tags

Note  Please do not extend this list without discussion and agreement.

The tags are translation / search keys, not human-readable strings. Any additions or changes mean updated translation files. The catalog-generator script will reject aircraft with non-standard tags!

Tags are designed to be inclusive, not exclusive, to give the broadest range of search results. If multiple tags apply, use them - for example the DC-3 has had multiple civilian and military roles.

Aircraft types

  • ga
  • helicopter
  • fighter
  • interceptor
  • glider - But does this includes the Space Shuttle, Virgin Galactic's SpaceShipeOne, as well?
  • spaceship
  • bomber
  • tanker
  • cargo
  • passenger
  • bizjet - Not just for jets, but I can't think of a better term
  • reconnaissance
  • airship
  • balloon
  • trainer - Used in a pilot training role
  • aerobatic
  • ultralight

Manufacturers

Intention here is to provide logical groupings, not to track corporate history - so the MD-80 and MD-11 would get the 'douglas' tag, which will likely translate to 'Douglas / McDonell-Douglas' in the UI. The 717 could get the boeing and douglas tags. Also not supposed to be an exhaustive list, this is so we can search on 'all glass-cockpit Boeing and Airbus aircraft'. It might be worth actively lying in the tags, i.e group all Hawker-Siddley / BAC / Avro aircraft under the Vickers tag.

  • avro
  • boeing
  • cessna
  • douglas
  • lockheed
  • vickers
  • piper
  • diamond
  • airbus
  • beechcraft
  • mig
  • fokker
  • ilyushin
  • antonov
  • embrarer
  • bombardier
  • saab

Eras

Logical groupings, not historical accuracy - some aircraft are going to have a lot of these, e.g. the B-52. Again the goal is intelligent searches: 'show me all WW2 fighters'. Would like to avoid this getting political too, comments on that are welcome

  • early-pioneers
  • ww1
  • 1920s
  • 1930s
  • golden-age
  • ww2
  • 1950s
  • 1960s
  • 1970s
  • vietnam
  • coldwar
  • korean
  • 1980s
  • 1990s
  • gulfwar1
  • 2000s

Aircraft Features

This could get long, as always trying to focus on tags people might search on - 'show me all the VTOL aircraft' or 'show me all the biplanes'. Some will be very useful in improving the user-experience, if the plane is tagged with seaplane we might be able to force a water start (not for amphibious obviously).

  • prototype
  • experimental - For X1 and similar X-planes
  • ifr - Panel and equipment (radios, lighting) suitable for IFR flight
  • fixed-gear
  • retractable-gear
  • tail-dragger
  • carrier-hook - Do we need a separate tag for carrier-capable?
  • stol - For short-takeoff
  • vtol - For the Harrier, F-35 if it ever works, and the Osprey
  • floats
  • amphibious
  • cannard - Cannard planform
  • delta - Delta planform; Vulcan, Concorde, Space Shuttle
  • variable-geometry - For Tomcats and the like
  • supersonic
  • glass-cockpit
  • refuel - Supports air-to-air refeuling
  • seaplane - Flying boat or float plane
  • etops - ETOPS capable aircraft, presumably implies twin-engined
  • biplane
  • triplane
  • pressurised - Pressurised cabin

FlightGear Features

  • combat - Support this various MP combat / bomb-able options
  • dual-controls - Supports copilot over MP
  • tow - Supports glider towing over MP
  • rembrandt - Supports Rembrandt, obviously

Propulsion

  • piston
  • radial - Radial piston engined
  • diesel
  • jet
  • turboprop
  • 1-engine
  • 2-engine
  • 3-engine
  • 4-engine
  • turbocharged - For pistons with a turbo-charger
  • afterburner
  • rocket
  • electric - For power-assisted gliders, mostly.
  • unpowered - Balloons, etc

Examples

  • B-52 would have: bomber, jet. boeing, coldwar, 1960s, vietnam, 1970s, 1980s, gulfwar1, nato, refuel, retractable-gear, ifr
  • Citation would have: cessna, bizjet, jet, 2-engine, glass-cockpit, ifr, retractable-gear
  • Cub would have: piper, piston, 1-engine, ga, trainer, fixed-gear, 1930s, ww2, tail-dragger

Adding metadata to aircraft

The tags are added to or included into the sim section of the -set.xml file(s) like for example below:

<?xml version="1.0" encoding="UTF-8" ?>

<PropertyList>

 <sim>

  <tags>
   <tag>passenger</tag>
   <tag>boeing</tag>
   <tag>jet</tag>
   <tag>twin-engine</tag>
   <tag>retractable-gear</tag>
   <tag>etops</tag>
   <tag>glass-cockpit</tag>
   <tag>ifr</tag>
  </tags>

 </sim>

</PropertyList>

Related content