[Kstars-devel] UID for skyobjects proposal

Alexey Khudyakov alexey.skladnoy at gmail.com
Tue Jul 7 18:40:45 CEST 2009


On Tue, Jul 7, 2009 at 7:42 PM, Akarsh Simha<akarshsimha at gmail.com> wrote:
>> No I think UID should be generally independent of catalog.
>>
>> One object could belong to many catalogs: HD/SAO/GSC or Messie/NGC/PGC
>> etc. Ideally we should be able to display information from all
>> catalogs, add them if needed. It's one to many correspondence (one
>> object <=> many catalogs). So I don't think it's really good idea.
>
> Yes, I agree. But then, how do you propose we handle an expansion of
> catalog support?
>
It's tricky part. On most abstract level catalog could be seen as maps
(UID -> Catalog entry). But data which is required for objects
displaying must be loaded/unloaded frequently or loaded all the time.
It's RA/dec/magnitude/etc. And it doesn't fit well into map framework.
So there must be some short version of catalogs with only essential
data which are easy and fast to load. Here problem of data duplication
arise.

Simplest solution I can imagine is to  made such catalogs by hands and
add UIDs to full catalogs. However it require specially cooked
catalogs.


>> I think better idea is to keep only essential information in
>> SkyObject. For stars it's RA/dec, magnitude, proper motion, color
>> index. Everything else could be loaded on request. For example when
>> details dialog is viewed. There could be problems with matching UIDs
>> between catalogs with searching. I think design space is rather big.
>
> I don't get you here. What is "everything else"? You mean the various
> catalog names? Anything else?
>
All other catalog data. For example Spectral class, B-V, magnitude in
different bands or whatever information catalog provide. Catalogs can
contain all kind of information which could not fit into rigid
structure of SkyObject.


More information about the Kstars-devel mailing list