[Kstars-devel] Some thoughts on catalogs

[Akarsh Simha]

> I believe that there is a problem with current data model. Stellar objects can 
> (and they do) appear in different catalogs. But there is no way to express 
> such relation. DeepSkyObject has ugc() and pgc() methods[1] which return UGC 
> and PGC number respectively. This isn't best way to add multiple catalog 
> support. And of course i does not provide way to get data from that catalogs. 

I agree that this is a problem. Médéric might be able to tell us how
HyperLeda, SIMBAD and these other "big" databases solve this issue. As
far as I know, they have one designation that they call a primary
designation along with several other designations - but I don't know
how they implement this kind of structure in their database.

Could you suggest some solution to this?

I really wish we could have all possible (SAO, HD, HIP, TYC)
designations for stars, but we must find a sane way to store them
all. Maybe it could just be "dumped" into an extended AuxInfo-like
structure, that is specifically overrided for each kind of object
(star, deep-sky, ...), maybe called 'DesignationInfo'.

> Second there is no way to extract arbitrary data from catalog. Star catalogs 
> can contain very diverse kind of data. Data which is present in one catalog 
> may be absent in another. Currently there is no way get arbitrary data 
> present in catalog. Creating all possible virtual functions is infeasible in 
> my opinion. Just too many of them. 
>
> So what is catalog? I'm going abstract from that point. Catalog is just set of 
> pair: { (k,v) } where `k' is record type (magnitude, RA, B-V, etc.), and `v' 
> is some value. Problem is that it could easily be of any type: number, 
> string, couple of numbers. So it's difficult to implement this properly. 
> I haven't much idea about it. It's kind of heterogenous map.

As far as I know, Cartes du Ciel has a way of handling this. They
support arbitrary catalogs where you could even have computed fields
as long as you indicate in some sort of binary catalog descriptor as
to how they must be computed.

I'm really considering implementing their catalog format in
KStars. That way, we would have a myriad of custom catalogs that have
been prepared for Cartes du Ciel pluggable into KStars. I've not done
enough homework on this to comment, though.

> Another problem I mentioned already - creating one object <-> many catalogs 
> relation. It's only become more difficult with need to utilize HTM and 
> requirement that catalogs must be pluggable. 

Jason had some scripts to match stars / objects across catalogs by
having some tolerance for inconsistencies across catalogs. I don't
think this is a big issue. If we provide all designations in each
catalog, it should then be possible to throw away duplicates and load
"conflicting" catalogs simultaneously. I haven't thought about the
implications of this, particularly on the memory usage and size of the
catalogs yet.

Regards
Akarsh