[Kstars-devel] Some thoughts on catalogs

[Jan Kotek]

Hi,

In OpenCoeli I have SQL table with 1:N relation. In second table is ID
or name saved as string. When new catalog is being imported I check if
ID already exists and merge two stars.

Magnitudes in various wavelenghts are also stored in 1:N relation.

Jan Kotek

On Tue, Mar 10, 2009 at 8:41 PM, Akarsh Simha <akarshsimha at gmail.com> wrote:
>> 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
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>