The Google Code In task that I had proposed resulted in some pretty interesting observations. I must confess my description for the task wasn't very precise, so I had to ask the students attempting the task to stay in touch, update us of the progress, and tell us if they get stuck. So if they didn't have much of a background in Astronomy, we could help decipher the terms used in catalogs.
The task was completed by andromeda-galaxy (the student, not the deep sky object) and Akarsh was awesome enough to help out specially when the time zones didn't. Since the student maintained contact with me and Akarsh, the task finished faster and we were able to help deal with any unforeseen problems.
I have compiled a few points to help anyone building custom catalogs in the future.
When building a catalog
- KStars accepts colon and space delimited notations (or double values) but you can't use spaces in the old catalog format! The new CSV format will support it just fine (but it yet to be released).
- Major and Minor axes are measured in 'arcmin' only.
- Every catalog's ID field should be an integer and the catalog prefix is automatically attached in the UI. So, the object with ID '42' and catalog prefix 'SAC' will appear as 'SAC 42' in KStars.
- Refer to skyobjects.h for an enum of the objects KStars supports.
- Refer to ngcic.dat in the code but only for acceptable data formats! ngcic.dat is not a custom catalog and custom catalogs do not use fixed width notations.
Where is the Merge?!
15 December 2012. That's my deadline to finish off some pending features and finish the final merge. I have already taken way too long!
The reason I ask you to wait is that the old format is really quirky. For instance, it does support spaces, but only in the description field. So, a row of the form:
31 "Andromeda Galaxy" 189.00 61.00 ...
I also found a bug which slows up large catalog imports during the GCI task. Should be easy to fix.
Catalog specifications are missing from the documentation. They can be found in the code with a little effort so this won't be hard to compile.
P.S. The new fuzzy match works! I'm yet to test how fuzzy should the match should be. Any suggestions?