Jason Harris | 1 Apr 02:16

Re: Dealing with Proper Motion in extended catalogs

Hello,

I meant to weigh in earlier.  I think James's solution to store high  
PM stars in multiple trixel-files is the way to go.  It gives us an  
elegant and bulletproof solution to a problem that would otherwise  
require a lot of complex code to work around.

+- 10,000 years should be no problem at all.  I would be surprised if  
more than a handful of users notice.  If pressed, we could also just  
stop painting faint stars if the date drifts outside the +- 10,000  
year interval, and pop up a KMessageBox explaining why (with a "Don't  
show again" checkbox).

regards,
Jason

On Mar 31, 2008, at 2:52 AM, James Bowlin wrote:

> On Mon March 31 2008, Akarsh Simha wrote:
>> Hi James,
>>
>>> When we create the files of stars ordered by position
>>> and then brightness, I propose that we include high PM stars in
>>> multiple lists so that if any trixel crossed by the 20,000 year
>>> line is visible, we are sure the star will be displayed.
>>
>> I don't understand this part. Could you elaborate?
>
> The reason proper motion causes a problem is because it causes stars
> to move from one trixel to another.  For example, imagine if we are
(Continue reading)

Jason Harris | 9 Apr 19:31

KDE/kdeedu/kstars/kstars/data

SVN commit 795278 by harris:

The Avalon, Australia listed in the Cities database is in Victoria,
not New South Wales.  I corrected the Province, and also added an
entry for Avalon, NSW, Australia.  Coordinates were taken from
Wikipedia.

BUG: 160558
CCMAIL: kstars-devel <at> kde.org

 M  +2 -1      Cities.dat  

--- trunk/KDE/kdeedu/kstars/kstars/data/Cities.dat #795277:795278
@@ -183,7 +183,8 @@
 Aurora                           : Minnesota             : USA                   : 47 : 31 :  1 : N :  92 : 16 : 58 : W : -6.0 : US
 Austin                           : Nevada                : USA                   : 39 : 30 :  0 : N : 117 :  4 : 58 : W : -8.0 : US
 Austin                           : Texas                 : USA                   : 30 : 16 :  9 : N :  97 : 44 : 36 : W : -6.0 : US
-Avalon                           : New South Wales       : Australia             : 38 :  1 : 59 : S : 144 : 28 :  0 : E :+10.0 : AU
+Avalon                           : New South Wales       : Australia             : 33 : 38 :  1 : S : 151 : 19 : 57 : E : 10.0 : AU
+Avalon                           : Victoria              : Australia             : 38 :  5 :  6 : S : 144 : 25 : 48 : E : 10.0 : AU
 Aviano                           :                       : Italy                 : 46 :  1 : 58 : N :  12 : 35 : 59 : E :  1.0 : EU
 Avon                             : Connecticut           : USA                   : 41 : 40 :  1 : N :  72 : 49 : 58 : W : -5.0 : US
 Ayase                            :                       : Japan                 : 35 : 27 :  0 : N : 139 : 26 : 59 : E : 9.0  : --

Akarsh Simha | 10 Apr 18:45
Picon
Gravatar

Conjunction Tool - Bugs + UI Design

Hello

I've written a small bit of code to predict 'close' conjunctions
in the apparent positions of any two KSPlanetBase objects. Many thanks
to everyone on this list who helped me out with that.

The code is buggy and I haven't found time over the past few days to
trace the bug. Here's my test code:

http://pastebin.com/m4977ac7d

The debug statements in the attached ksconjunct.cpp output the correct
Julian Day, but wrong RA for the given KSPlanetBase objects. Can
someone help me find out what the bug is?

As I do not know Qt interface design, I would request someone to help
me out by designing a user interface that accepts the following input:

* Two solar system objects (maybe we could start off with planets)
* Start Date for Computation
* End Date for Computation
* Maximum allowable separation between the objects (how 'close' is the
  conjunction?) 

The interface should also show the output, which is the map returned
by KSConjunct::findClosestApproach()

Regards
Akarsh.
(Continue reading)

Jason Harris | 11 Apr 02:03

KDE/kdeedu/kstars/kstars

SVN commit 795605 by harris:

Fixing bug #119963.  Now you can center & track on solar system
bodies, even when they are not being drawn.  The centered body remains
invisible but does get a name label.

The drawback from this fix is that users can no longer attempt to save
CPU cycles by turning off solar system bodies; their positions will
still get updated, even when invisible.  Still, that's better than
centering on a null position when the user tries to center on a real
body.

BUG: 119963
CCMAIL: kstars-deveL <at> kde.org

 M  +3 -3      skycomponents/solarsystemcomposite.cpp  
 M  +4 -0      skymap.cpp  
 M  +1 -1      skymap.h  

--- trunk/KDE/kdeedu/kstars/kstars/skycomponents/solarsystemcomposite.cpp #795604:795605
@@ -88,7 +88,7 @@

 void SolarSystemComposite::update( KStarsData *data, KSNumbers *num )
 {
-    if ( ! selected() ) return;
+	//    if ( ! selected() ) return;

     m_Sun->EquatorialToHorizontal( data->lst(), data->geo()->lat() );
     m_Moon->EquatorialToHorizontal( data->lst(), data->geo()->lat() );
@@ -101,7 +101,7 @@
(Continue reading)

Jason Harris | 11 Apr 02:07

Re: KDE/kdeedu/kstars/kstars

oops, I meant bug #122528:
https://bugs.kde.org/show_bug.cgi?id=122528

On Apr 10, 2008, at 5:03 PM, Jason Harris wrote:

> SVN commit 795605 by harris:
>
> Fixing bug #119963.  Now you can center & track on solar system
> bodies, even when they are not being drawn.  The centered body remains
> invisible but does get a name label.
>
> The drawback from this fix is that users can no longer attempt to save
> CPU cycles by turning off solar system bodies; their positions will
> still get updated, even when invisible.  Still, that's better than
> centering on a null position when the user tries to center on a real
> body.
>
> BUG: 119963
> CCMAIL: kstars-deveL <at> kde.org
>
>
>
> M  +3 -3      skycomponents/solarsystemcomposite.cpp
> M  +4 -0      skymap.cpp
> M  +1 -1      skymap.h
>
>
> --- trunk/KDE/kdeedu/kstars/kstars/skycomponents/ 
> solarsystemcomposite.cpp #795604:795605
> @@ -88,7 +88,7 @@
(Continue reading)

Jason Harris | 11 Apr 02:17

KDE/kdeedu/kstars/kstars/data

SVN commit 795606 by harris:

Fixing bug #123647: Delta Cancri is "Asselus Australis", not "Asselus Borealis"

Sorry I took so long...

BUG: 123647
CCMAIL: kstars-devel <at> kde.org

 M  +1 -1      stars.dat  

--- trunk/KDE/kdeedu/kstars/kstars/data/stars.dat #795605:795606
@@ -499,7 +499,7 @@
 074348.47 -285717.4 -000004.6+000003.900000.4 03.9400.16A2 0
 205710.41 +411001.9 +000008.5-000024.000009.2 03.9400.03A1 1            , nu  Cyg
 074114.88 -093303.9 -000074.8-000019.600022.6 03.9401.02K0 0            , alp Mon
-084441.11 +180917.5 -000017.1-000228.500024.0 03.9401.08K0 0            , del Cnc, Asellus Borealis
+084441.11 +180917.5 -000017.1-000228.500024.0 03.9401.08K0 0            , del Cnc, Asellus Australis
 020326.19 +722516.5 -000044.0+000022.500020.1 03.95-0.00A2 0            , 50  Cas
 063641.00 -191520.6 +000062.3-000069.900050.4 03.9501.04K1 0            , nu 2CMa
 040839.67 +474245.3 +000020.2-000033.300005.9 03.96-0.03B3 0            , 48  Per
Jason Harris | 11 Apr 02:49

KDE/kdeedu/kstars/kstars

SVN commit 795610 by harris:

Increase maximum zoom level by a factor of 5.

CCMAIL: kstars-devel <at> kde.org

 M  +1 -1      kstars.kcfg  
 M  +1 -1      kstarsdata.h  

--- trunk/KDE/kdeedu/kstars/kstars/kstars.kcfg #795609:795610
@@ -598,7 +598,7 @@
 			<label>Zoom Factor, in pixels per radian</label>
 			<whatsthis>The zoom level, measured in pixels per radian.</whatsthis>
 			<default>1000.</default>
-			<min>200.</min><max>1000000.</max>
+			<min>200.</min><max>5000000.</max>
 		</entry>
 		<entry name="MagLimitAsteroid" type="Double">
 			<label>Faint limit for asteroids</label>
--- trunk/KDE/kdeedu/kstars/kstars/kstarsdata.h #795609:795610
@@ -34,7 +34,7 @@
 #include "skycomponents/skymapcomposite.h"

 #define MINZOOM 200.
-#define MAXZOOM 1000000.
+#define MAXZOOM 5000000.
 #define DEFAULTZOOM 2000.
 #define DZOOM 1.10
 #define AU_KM 1.49605e8  //km in one AU

(Continue reading)

Akarsh Simha | 16 Apr 18:55
Picon
Gravatar

Re: Magnitude of Mars

Hi

> I was using Kstars tonight and I looked at the info/details for Mars.  I
> noticed that the current visual magnitude for Mars is listed as 15.3
> (March 18, 2008 23:04 US central time [GMT -5]) which is clearly
> incorrect.  I'm not sure if this is an error in the database or in the
> calculation which figures in distance, etc, but something is amiss.

I cannot reproduce this in a recent SVN revision that I am currently
on.

Regards
Akarsh.
Andrew Buck | 17 Apr 03:30
Picon
Favicon

Re: Magnitude of Mars


On Wed, 2008-04-16 at 22:25 +0530, Akarsh Simha wrote:
> Hi
> 
> > I was using Kstars tonight and I looked at the info/details for Mars.  I
> > noticed that the current visual magnitude for Mars is listed as 15.3
> > (March 18, 2008 23:04 US central time [GMT -5]) which is clearly
> > incorrect.  I'm not sure if this is an error in the database or in the
> > calculation which figures in distance, etc, but something is amiss.
> 
> I cannot reproduce this in a recent SVN revision that I am currently
> on.
> 
> Regards
> Akarsh.
> 

I am running version 1.2.5 (kde version 3.5.8) right now however I have
recently switched to Debian testing.  I think when I had this error I
was running Debian stable (etch).  This version has 1.6 for the
magnitude as it's listed now, so its presumably been fixed then.  Sorry
about bringing up a bug in what was probably a fairly old version.  If I
send in any more reports in the future I'll remember to document the
version as well.

-Buck
Akarsh Simha | 17 Apr 09:56
Picon
Gravatar

Conjunctions tool backends, a few bugfixes

Hello

I fixed the bug in the conjunctions tool backend and it now works
beautifully. I tested it only against two planets (Mars vs Jupiter),
and it gave out correct results. But I suppose it should work equally
well for other planets as well.

I would request someone to design an interface for this, as I
mentioned in a previous email.

Also attached is a small patch with a few documentation bugfixes, and
a fix to Bug #147917 in the code, which requires re-generation of the
template file for complete fixing.

The bugfix to cities.dat has to do with renaming of Indian
cities, that happened quite a few years back, with cities officially
adopting regional names.

ksconjunct.h and ksconjunct.cpp need to be put into the
/kstars/kstars/tools directory.

Regards
Akarsh.
Attachment (patch_20080417.tar.gz): application/octet-stream, 6187 bytes
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
(Continue reading)


Gmane