Importing the Washington Double Stars Catalog

[Jasem Mutlaq]

So it appears that the Tycho Double Star Catalogue (TDSC) has 98,482 rows.
It provides cross-references to HIP, HD, WDS, and Tycho 1,2,3. Since Tycho2
in KStars is "unnamed" but has HD index, we can use the HD/WDS
cross-references OR xmatch as illustrated below. At any rate, out of the
98,482 rows, only 36,159 have HD indexes, 71,979 has WDS indexes, and
records having both indexes is 32,852.

There is no parallax/spec_type available. Instead we have the following:

+ RAJ2000
+ DEJ2000
+ pmRA
+ pmDE
+ PA
+ HD
+ BTmag
+ VTmag
+ Sep
+ WDS

Finally, I used (http://cdsxmatch.u-strasbg.fr/) to match TDSC vs. Tycho-2
within 0.1 arcsec position radius and got 28,677 records so there is
overlap between TDSC and Tycho-2. For 0.5 arcsec position radius, I got
over ~80k records.

Since neither starData nor deepStarData would be sufficient for TDSC data
above, it looks like we will need another struct, if we are going to go the
binary path way. I'm also not sure what to do about the 28,677 duplicate
stars among Tycho2 & TDSC? We probably need a long-term solution for these
sort of situations which would be realized whenever we add new star
catalogs. I guess one solution is to strip KStars own Tycho2 deepstars.dat
from these 28,677 stars, if we can figure out a way to cut them out. But
then users would lose these stars unless they install the double star
catalog. Another solution is to simply ignore them and allow for
"duplicates".

Regards,
Jasem



On Mon, Dec 5, 2016 at 4:59 PM, Jasem Mutlaq <mutlaqja at ikarustech.com>
wrote:

> Yeah I already loaded the catalog from Vizer, always been a great service.
> But it looks like there is a combined catalog already: Tycho Double Star
> Catalogue (TDSC) (Fabricius+ 2002)
>
> http://vizier.u-strasbg.fr/viz-bin/VizieR-3?-source=I/276/catalog
>
> So we could use catalog instead of WDS directly. Another issues is that
> Hipparcos data we're using appear to be J1991.25, so I also need to check
> if we are assuming they're J2000 or someone performed the conversion before.
>
> On Mon, Dec 5, 2016 at 12:46 PM, Christian Dersch <lupinix at mailbox.org>
> wrote:
>
>> Hi folks,
>>
>> I think we have to crossmatch WDS with Tycho-2 and/or USNO (which one
>> btw?). Crossmatches can be done on identifiers (if both catalogs ship
>> identifiers of one common catalog) or on position. A very easy to go
>> solution is http://cdsxmatch.u-strasbg.fr/xmatch but using more powerful
>> tools like Topcat or PyVO (be sure to use latest version) allows you to
>> select columns from both catalogs, doing inner and outer joins using ADQL
>> (astronomy relatex SQL dialect) and TAP services. For example we could
>> create a Tycho-2 with just an WDS identifier in addition in that way. Or a
>> WDS with Tycho-2 identifiers in addition. Or any other combination of both
>> tables.
>>
>> Btw: Almost all catalogs (notable exception: Steinicke NGC) are availabe
>> on VizieR: http://vizier.u-strasbg.fr/viz-bin/VizieR
>>
>> Greetings,
>> Christian
>>
>>
>>
>> On 12/05/2016 09:56 AM, Jasem Mutlaq wrote:
>>
>> Hello folks,
>>
>> So I'd like to make the WDS as an addon catalog: http://www.usno.navy.
>> mil/USNO/astrometry/optical-IR-prod/wds/WDS
>>
>> Note that I have problems accessing the website, I can only see the main
>> page but any links within timeout.
>>
>> So what would be the best way to go on about this? The stars are "named",
>> and a lot them are duplicates of either the static named/unnamed stars, or
>> Tycho-2/USNO stars. So what are the recommended solution?
>>
>> 1. Import them as is "new stars" and ignore duplication. We need metadata
>> for angular separation and position angle, and magnitudes of 1st and 2nd
>> components.
>> 2. "Extend" static/tycho/usno stars with the cross-reference information
>> provided by WDS? We might miss some stars that are not found in either of
>> those catalogs, highly unlikely, but possible.
>>
>> In either case, we need to extend the "metadata".
>>
>> On another note, I was checking  DeepStarComponent::loadStaticStars()
>> and found that after each record read, it checks if it is 16 or 32 bytes.
>> Can you mix 16/32 bytes within a single file?? If not, then no need to
>> perform such a check after each record unnecessarily.
>>
>> --
>> Best Regards,
>> Jasem Mutlaq
>>
>>
>>
>
>
> --
> Best Regards,
> Jasem Mutlaq
>
>


-- 
Best Regards,
Jasem Mutlaq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20161205/3852aa52/attachment.html>