headers
Jason Harris | 2 Apr 17:36

KDE/kdeedu/kstars/kstars

SVN commit 649384 by harris:

Refactored the constellation boundaries

Previously, boundaries were stored as "segments", each of which was the 
boundary between two constellations.  A single constellation's boundary 
could be any number of segments, depending on how many other 
constellations it borders.  Each segment also contained the name of the 
two constellations which it divided.  Under this scheme, it was 
CPU-intensive to determine which constellation a particular point was 
in, and there were many corner cases.  However, the advantage of this 
method over simply storing each constellation's full boundary is that it 
avoids having redundant representation of each boundary.

Now I have switched to the more intuitive method of storing each 
constellation's full boundary.  ConstellationBoundaryComponent is a 
LineListComponent, containing all of the non-redundant constellation 
boundary segments.  However, it also represents each full boundary 
internally in a QHash of QPolygonF's.  This representation is much more 
convenient for drawing the highlighted constellation boundary, and for 
determining which constellation a given SkyPoint is in.  I also added a 
new function 'bool SkyMapComposite::inConstellation( const QString 
&name, SkyPoint *p )', which returns true if the point p is inside the 
constellation named name.  This function will be useful (for example) in 
the Observing List Wizard, when the user wants to select objects which 
are in a particular constellation.

In fact, these changes were initially prompted by a bug report that 
selecting by constellation in the ObsList wizard is very slow.  
Hopefully, these changes will help make it faster.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 14 Apr 00:55

KDE/kdeedu/kstars/kstars

SVN commit 653649 by harris:

Clip the highlighted constellation boundary at the horizon, 
if the opaque ground is shown.

TODO: there is still a bug where the constellation cannot 
be identified for some positions on the sky.

CCMAIL: kstars-devel <at> kde.org

 M  +44 -3     skymapdraw.cpp  

--- trunk/KDE/kdeedu/kstars/kstars/skymapdraw.cpp #653648:653649
@@ -188,13 +188,54 @@
 }

 void SkyMap::drawHighlightConstellation( QPainter &psky, double scale ) {
-	QPolygonF constell;
-	data->skyComposite()->constellation( focus(), &constell );
+	QPolygonF cbound;
+	data->skyComposite()->constellation( focus(), &cbound );
 	
 	psky.setPen( QPen( QColor( ks->data()->colorScheme()->colorNamed( "CBoundHighColor" ) ), 3,
Qt::SolidLine ) );

+	//If the solid ground is being drawn, then we may need to clip the 
+	//polygon at the Horizon.  cbound will be the clipped polygon
+	if ( Options::useAltAz() && Options::showGround() ) {
+		QPolygonF horizPolygon;
+		bool needClip( false );
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 14 Apr 02:54

KDE/kdeedu/kstars/kstars

SVN commit 653680 by harris:

New feature:  Earth Satellite tracks!

The display shows a curve across the sky, which is the 
path of a satellite over the next hour from the current 
location.  The color of the curve can be modified, and 
you can toggle whether satellite tracks are drawn in 
the Solar System tab of the Options window.

TODO:
+ Right now, only three satellites are included: HST, 
ISS, and UARS.  Many more are available, these are just 
for testing the feature.

+ Need to add satellite data to the Get New Stuff mechanism

+ Add tickmarks to the tracks, indicating the time of the 
passage

+ The path should be darkened where the satellite is in 
Earth's shadow (this information is already available, it's 
just a matter of using it).

+ Make thickness of the line proportional to brightness of 
the satellite?

CCMAIL: kstars-devel <at> kde.org

 M  +3 -0      colorscheme.cpp
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason Harris | 17 Apr 05:57

KDE/kdeedu/kstars/kstars

SVN commit 654832 by harris:

Adding tickmarks and time labels to satellite tracks...looks really cool!

CCMAIL: kstars-devel <at> kde.org

 M  +91 -2     skycomponents/satellitecomponent.cpp  
 M  +5 -0      skycomponents/satellitecomponent.h  
 M  +3 -23     skycomponents/satellitecomposite.cpp  
 M  +2 -1      skycomponents/satellitecomposite.h  
 M  +32 -0     skyline.cpp  
 M  +9 -0      skyline.h  

--- trunk/KDE/kdeedu/kstars/kstars/skycomponents/satellitecomponent.cpp #654831:654832
@@ -16,10 +16,14 @@
  ***************************************************************************/

 #include <QBrush>
+#include <QPainter>

+#include "kstars.h"
 #include "kstarsdata.h"
+#include "skymap.h"
 #include "skyline.h"
 #include "satellitecomponent.h"
+#include "Options.h"

 SatelliteComponent::SatelliteComponent(SkyComponent *parent, bool (*visibleMethod)())
 : LineListComponent(parent, visibleMethod)
@@ -36,18 +40,103 @@
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 17 Apr 09:15

KDE/kdeedu/kstars/kstars

SVN commit 654880 by harris:

Action fixes: we can no longer refer to actions with sender()->objectName()
Instead, you can query action names like so:

if ( sender() == actionCollection()->action("actionNameString")

Thanks, Jasem, for reminding me about this (this fixes the 
non-functional toolbar buttons, as well as some menu actions)

CCMAIL: kstars-devel <at> kde.org

 M  +8 -7      fovdialog.cpp  
 M  +23 -24    kstarsactions.cpp  
 M  +2 -1      opscatalog.cpp  
 M  +2 -1      opssolarsystem.cpp  

--- trunk/KDE/kdeedu/kstars/kstars/fovdialog.cpp #654879:654880
@@ -25,6 +25,7 @@
 #include <QTextStream>
 #include <QPaintEvent>

+#include <kactioncollection.h>
 #include <klocale.h>
 #include <kdebug.h>
 #include <kpushbutton.h>
@@ -250,16 +251,16 @@
 }

 void NewFOV::slotComputeFOV() {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 18 Apr 10:26

Re: KDE/kdeedu/kstars/kstars

Well, it looks like the satellite track positions are not accurate.  I'm 
comparing them to various sources online, especially heavens-above.com 
and spaceflight.nasa.gov/realdata.

For example, these websites predict a pass by HST over Tucson, AZ on 18 
April 2007 at 4:25 am, local time.  But I'm not seeing an HST pass in 
KStars anywhere near that time.

I'm trying to figure out what the problem is.

Jason

Jason Harris wrote:
> SVN commit 653680 by harris:
> 
> New feature:  Earth Satellite tracks!
> 
> The display shows a curve across the sky, which is the 
> path of a satellite over the next hour from the current 
> location.  The color of the curve can be modified, and 
> you can toggle whether satellite tracks are drawn in 
> the Solar System tab of the Options window.
> 
> TODO:
> + Right now, only three satellites are included: HST, 
> ISS, and UARS.  Many more are available, these are just 
> for testing the feature.
> 
> + Need to add satellite data to the Get New Stuff mechanism
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
JB BUTET | 25 Apr 14:43
Picon

Re: SatLIb verification

Hi Jason :)

Hve you updated your TLEs ? (Three Line Elements)

You need it if you want predictions are accurate.

Keep contact ;)

JB

Jason Harris a écrit :
> Hello,
> 
> I have finally added Earth satellite tracking to KStars using SatLib; see the 
> attached screenshot.  However, I'm having trouble verifying that the 
> predictions are accurate.  I'm comparing to websites like heavens-above.com, 
> and it looks to me like the SatLib predictions are completely different.
> 
> Quoting an earlier email on this topic[1]:
>> I'm comparing [the SatLib predictions] to various sources online,
>> especially heavens-above.com and spaceflight.nasa.gov/realdata.
>>
>> For example, these websites predict a pass by HST over Tucson, AZ on 18
>> April 2007 at 4:25 am, local time.  But I'm not seeing an HST pass in
>> KStars anywhere near that time.
> 
> I've tried several other dates as well, I can't seem to find any correlation 
> between the SatLib predictions and those published at heavens-above and NASA.
> 
> I was wondering if you had any insight in this matter.  Have you done any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 25 Apr 18:57

Re: SatLIb verification

> Hi Jason :)
>
> Hve you updated your TLEs ? (Three Line Elements)
>
> You need it if you want predictions are accurate.
>
> Keep contact ;)
>
> JB

Yes, of course. :)
The TLEs I am using were obtained on April 13th.  See the file here:
http://websvn.kde.org/trunk/KDE/kdeedu/kstars/kstars/data/satellites.dat?revision=653680&view=markup

The epoch in the TLEs is "07094...", which is the 94th day of year 2007, or 
April 4th.

Anyway, my original question was: have you done any verification of the SatLIb 
predictions against other published satellite predictions?  If so, can you 
tell me about the results and which sources you used for the comparison?

thanks,
Jason

--

-- 
KStars: KDE Desktop Planetarium
kstars <at> 30doradus.org
Permalink | Reply | 5 comments |
headers
Jason Harris | 25 Apr 03:53

SatLIb verification

Hello,

I have finally added Earth satellite tracking to KStars using SatLib; see the 
attached screenshot.  However, I'm having trouble verifying that the 
predictions are accurate.  I'm comparing to websites like heavens-above.com, 
and it looks to me like the SatLib predictions are completely different.

Quoting an earlier email on this topic[1]:
> I'm comparing [the SatLib predictions] to various sources online,
> especially heavens-above.com and spaceflight.nasa.gov/realdata.
> 
> For example, these websites predict a pass by HST over Tucson, AZ on 18
> April 2007 at 4:25 am, local time.  But I'm not seeing an HST pass in
> KStars anywhere near that time.

I've tried several other dates as well, I can't seem to find any correlation 
between the SatLib predictions and those published at heavens-above and NASA.

I was wondering if you had any insight in this matter.  Have you done any 
verification of the SatLib predictions?  If so, can you share the sources you 
compared with?

thanks,
Jason

[1]: http://lists.kde.org/?l=kstars-devel&m=117688489902995&w=2
--

-- 
KStars: KDE Desktop Planetarium
kstars <at> 30doradus.org
(Continue reading)

Permalink | Reply | 7 comments |
headers
JB BUTET | 25 Apr 22:38
Picon

Re: SatLIb verification

Hi

Ok, with good TLEs it seems there's a pb.
I have another program (in dos, really accurate) for satellites to verify.

> Anyway, my original question was: have you done any verification of the SatLIb 
> predictions against other published satellite predictions?  If so, can you 
> tell me about the results and which sources you used for the comparison?

I've ported satlib in order to make some predictions abou ISS. So I've 
done ISS comparison with heavens-above and ...m don't remember this 
great site... mmm... ah... no more neurons left here... calsky !!

And errors was really minimal. (predictions were good).

But I haven't try for others.

May be Patrick or Bernard has some other ideas ?

Clear skies,

JB
Permalink | Reply | 4 comments |

Gmane