Re: USNO is sending me 100 million stars

They get only 6 bytes per star because they only provide RA, Dec, and
2 magnitudes.  Our catalog will additionall have proper motions, so
our positions will be more accurate for remote dates.

Still, if we want to give users the option of foregoing proper motion,
then this would be an exciting option...

On Mon, Jun 30, 2008 at 3:29 PM, Akarsh Simha <akarshsimha <at> gmail.com> wrote:
>
>> Any chance of supporting USNO A 2.0 binary format?
>>
>> It have quite simple format 6byte record per star, is also indexed.
>> There are some C libraries for reading it. Many amateurs already have
>> downloaded it since CdC and other programs can read it.
>
> Could you link me to it's specification? I wonder how they manage with
> 6 bytes per star.
>
> It might be easy to write a program to convert this format into
> KStars' format. We should probably stick to KStars' present format at
> the end, because the KStars format is designed keeping speed in mind,
> so that all fields lie on appropriate byte boundaries.
>
> Regards
> Akarsh
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel <at> kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>

Proper Motion Duplication

Hi

I tried to get some figures on how much more weight will be added to
our catalogs, if we duplicated stars in all trixels that they will
pass in +/- 10000 years.

I realise at this point that my program is faulty (because there are
some stars with very low PM that are duplicated in 30+ trixels!), but
the rough estimate I got said that we need a 17% increase in size,
assuming that we forget about the 25 arcminute margin.

Regards
Akarsh

_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel

Re: Proper Motion Duplication

On Mon June 30 2008, Akarsh Simha wrote:
> I realise at this point that my program is faulty (because there are
> some stars with very low PM that are duplicated in 30+ trixels!), but
> the rough estimate I got said that we need a 17% increase in size,
> assuming that we forget about the 25 arcminute margin.

Don't forget the margin!  It makes a significant difference (I think).

--

-- 
Peace, James

Re: Proper Motion Duplication

> Don't forget the margin!  It makes a significant difference (I think).

Yes, I will account for the margin when I fix the script tomorrow.

Regards
Akarsh

_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel

branches/kstars/unfrozen/kstars/kstars

SVN commit 826604 by harris:

porting fix from trunk, revision 824526.  Quoting the original message:

When a color scheme is selected in the Options window (or when a new
scheme is created), reflect the new selection in the View|Color
Schemes menu as well.

(note: I also ported revision 822426, which enabled the Update button in the 
config window for a couple of controls...but I forgot the CCMAIL)

CCMAIL: kstars-devel <at> kde.org

 M  +14 -8     opscolors.cpp  

--- branches/kstars/unfrozen/kstars/kstars/opscolors.cpp #826603:826604
@@ -21,6 +21,8 @@
 #include <QPixmap>
 #include <QTextStream>

+#include <kactioncollection.h>
+#include <kapplication.h>
 #include <klocale.h>
 #include <knuminput.h>
 #include <kcombobox.h>
@@ -128,24 +130,24 @@

 void OpsColors::slotPreset( int index ) {
     QString sPreset = PresetFileList.at( index );
-    bool result = setColors( sPreset );

branches/kstars/unfrozen/kstars/kstars

SVN commit 826605 by harris:

porting fix from trunk, revision 825333.  Quoting original commit message:

Improve combined use of the "by name" and "by type" filtering in the
Find Object tool.  Prior to this commit, changing the object-type
selection would clear the name filter edit box.

CCMAIL: kstars-devel <at> kde.org

 M  +85 -90    finddialog.cpp  
 M  +43 -39    finddialog.h  

--- branches/kstars/unfrozen/kstars/kstars/finddialog.cpp #826604:826605
@@ -68,7 +68,7 @@
     connect( this, SIGNAL( cancelClicked() ), this, SLOT( reject() ) );
     connect( ui->SearchBox, SIGNAL( textChanged( const QString & ) ), SLOT( enqueueSearch() ) );
     connect( ui->SearchBox, SIGNAL( returnPressed() ), SLOT( slotOk() ) );
-    connect( ui->FilterType, SIGNAL( activated( int ) ), this, SLOT( filterByType( int ) ) );
+    connect( ui->FilterType, SIGNAL( activated( int ) ), this, SLOT( enqueueSearch() ) );
     connect( ui->SearchList, SIGNAL( doubleClicked( const QModelIndex & ) ), SLOT( slotOk() ) );

 
@@ -83,7 +83,61 @@

 void FindDialog::init() {
     ui->SearchBox->clear();
+    filterByType();
+    sortModel->sort( 0 );
+    initSelection();

branches/kstars/unfrozen/kstars/kstars

SVN commit 826606 by harris:

porting fix from trunk, revision 825021.  Quoting original commit message:

Fix bug that made it impossible to compute FOV angles of eyepieces and cameras in
the NewFOV tool.

CCMAIL: kstars-devel <at> kde.org

 M  +3 -6      fovdialog.cpp  

--- branches/kstars/unfrozen/kstars/kstars/fovdialog.cpp #826605:826606
@@ -224,14 +224,11 @@
 void NewFOV::slotComputeFOV() {
     KStars *ks = (KStars*)(parent()->parent());

-    if ( sender() == ks->actionCollection()->action( "ComputeEyeFOV" ) ) kDebug() << "A";
-    if ( sender() == ks->actionCollection()->action( "ComputeEyeFOV" ) && ui->TLength1->value() > 0.0 )
kDebug() << "B";
-
-    if ( sender() == ks->actionCollection()->action( "ComputeEyeFOV" ) && ui->TLength1->value() > 0.0 )
+    if ( sender() == ui->ComputeEyeFOV && ui->TLength1->value() > 0.0 )
         ui->FOVEdit->setText( KGlobal::locale()->formatNumber( ui->EyeFOV->value() *
ui->EyeLength->value() / ui->TLength1->value() ) );
-    else if ( sender() == ks->actionCollection()->action( "ComputeCameraFOV" ) &&
ui->TLength2->value() > 0.0 )
+    else if ( sender() == ui->ComputeCameraFOV && ui->TLength2->value() > 0.0 )
         ui->FOVEdit->setText( KGlobal::locale()->formatNumber( ui->ChipSize->value() * 3438.0 /
ui->TLength2->value() ) );
-    else if ( sender() == ks->actionCollection()->action( "ComputeHPBW" ) && ui->RTDiameter->value() >

branches/kstars/unfrozen/kstars/kstars

SVN commit 826610 by harris:

porting fix from trunk, revision 822804.  Quoting the original commit message:

Fixing a usability issue in the options window.
Toggling the view toolbar buttons now toggles the
corresponding control in the options dialog.  This is
useful for those who keep the options window open while
using the program.

TODO: there's no meta-option for deep-sky objects in the
options window.  I'll ask translators if it's ok to add
one for 4.2.

Thanks for pointing this out, James.

CCMAIL: kstars-devel <at> kde.org

 M  +12 -0     kstars.h  
 M  +30 -5     kstarsactions.cpp  

--- branches/kstars/unfrozen/kstars/kstars/kstars.h #826609:826610
@@ -48,6 +48,12 @@
 class JMoonTool;
 class ImageViewer;

+class OpsCatalog;
+class OpsGuides;
+class OpsSolarSystem;
+class OpsColors;

branches/kstars/unfrozen/kstars/kstars

SVN commit 826611 by harris:

Porting fix from trunk, revision 824546.  Quoting the original commit message:

Resolving an inconsistency between toolbar actions and
the configuration window: the view toolbar provides an
action to toggle all deep-sky objects on/off, but in the
configuration window, there were only controls for
individual catalogs (Messier, NGC, IC, etc).

I added a Checkbox to the configuration window to toggle
all deep-sky objects.  Unchecking this box will disable
all deep-sky related widgets in the window, like the
"Hipparcos star catalog" checkbox does for stars.  The
checkbox and the toolbar button are properly synced with
each other.

No new string was added, but there will be a fuzzy: I
adopted the "Deep-Sky Catalogs" string which was used as
a group-box title.  The group box now has no title.  For
consistency, I also removed the (redundant anyway) "Star
catalog" title from the stars group box.  So that string
has disappeared.

CCMAIL: kstars-devel <at> kde.org

 M  +3 -0      kstarsactions.cpp  
 M  +19 -0     opscatalog.cpp  
 M  +1 -0      opscatalog.h  
 M  +30 -95    opscatalog.ui  

caught up on trunk->unfrozen ports

I've now ported all of the trunk commits to unfrozen, except for a
couple which are superseded by unfrozen changes.