Projects/Edu/KStars/Better deep-sky handling

Here are some ways to improve our deep-sky handling:

0. TOP PRIORITY -- add a number of fields to the database tables that will be used in case necessary. This should be done before release, since these changes are not backwards-compatible and so if we don't do them before release, we will need to provide scripts to import data from databases with the old structure to databases with the new structure.

1. Use Hierarchical Triangular Meshes (http://www.skyserver.org/HTM/) of various depths (or possibly, a fixed, sufficiently high depth) for deep-sky catalogues, both to selectively load data, and to selectively render objects (for extensive details on a similar implementation already existing for stars in KStars, see the file README.stars in the kstars/skycomponents directory in the source code). Maybe even better would be to have catalog-agnostic HTM meshes, with depths decided by magnitude or some sort of heuristic "visibility".

2. The database structure already has a relational system where the object is kept separate from its identification. This is necessary, because the same object almost always has multiple designations from different catalogues (eg: Messier 31 == NGC 224 == UGC 454 == Andromeda Galaxy). However, KStars really doesn't have a fuzzy-match to collate data from different catalogs and identify objects as being the same. This is one more thing that should be implemented.

3. KStars should be able to "import" data about individual objects from various data sources like NED (http://ned.ipac.caltech.edu/), SIMBAD (http://simbad.u-strasbg.fr/simbad/), or even SkyChart's (http://www.ap-i.net/skychart/start) "Identification" feature, collate it, and store it into the deep-sky database. Picture a dialog that says "Import deep-sky object", that asks you to type an object's name and choose a source. If you choose a web service (eg: SIMBAD), KStars should go query the website for information in an XML or other machine-readable format, and import the data. If you choose another astronomy app, eg: SkyChart, KStars should open up a window where you can copy-paste the information from the other program, and KStars will parse it and add it into its database. We should also provide a data "take-out" where we can export data from the database in a nice XML format, maybe compliant with the Open Astronomy Log 2.0 schema.

4. The find dialog should be much quicker. How this is to be done is something that needs to be discussed and thought about. Maybe the find dialog could show only trivial names on the list, and still support searching catalogs, except without displaying the catalog numbers in the find dialog. But this is a problem when filtering by category (eg: Open Clusters). Another possibility is to choose a "smart" hash for object names where it is trivial to choose only those objects that match a certain first letter. Some sort of a better data structure. This way, we can show the list only after the user has entered enough characters to narrow-down the list to about 50 objects.