headers
Akarsh Simha | 2 Aug 22:43
Picon
Gravatar

KDE/kdeedu/kstars/kstars/skycomponents

SVN commit 841239 by asimha:

Fixing bug with display of stars.

CCMAIL: kstars-devel <at> kde.org

 M  +1 -1      starcomponent.cpp  

--- trunk/KDE/kdeedu/kstars/kstars/skycomponents/starcomponent.cpp #841238:841239
@@ -512,7 +512,7 @@

     for(int i = 0; i < m_skyMesh -> size(); ++i) {

-        Trixel trixel = ( ( i >= 256 ) ? ( i - 256 ) : ( i + 256 ) );
+        Trixel trixel = i;// = ( ( i >= 256 ) ? ( i - 256 ) : ( i + 256 ) );
         StarBlock *SB = new StarBlock( dataReader.getRecordCount( i ) );
         if( !SB )
             kDebug() << "ERROR: Could not allocate new StarBlock to hold shallow unnamed stars for trixel " << trixel << endl;
Permalink | Reply | 0 comments |
headers
Akarsh Simha | 4 Aug 12:33
Picon
Gravatar

KDE/kdeedu/kstars/kstars/tools

SVN commit 841944 by asimha:

Ensuring that indentation in conjunctions.cpp complies with that used
in the rest of KStars

CCMAIL: kstars-devel <at> kde.org

 M  +79 -79    conjunctions.cpp  

--- trunk/KDE/kdeedu/kstars/kstars/tools/conjunctions.cpp #841943:841944
@@ -4,7 +4,7 @@
     begin                : Sun 20th Apr 2008
     copyright            : (C) 2008 Akarsh Simha
     email                : akarshsimha <at> gmail.com
- ***************************************************************************/
+***************************************************************************/

 /***************************************************************************
  *                                                                         *
@@ -51,50 +51,50 @@
 ConjunctionsTool::ConjunctionsTool(QWidget *parentSplit)
     : QFrame(parentSplit), Object1( 0 ), Object2( 0 ) {

-  setupUi(this);
+    setupUi(this);

-  /*
-  OutputView -> setTableFlags( Tbl_autoScrollBars|Tbl_clipCellPainting );
-  OutputView -> setAutoUpdate( TRUE );
-  OutputView -> setNumRows( 0 );
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akarsh Simha | 9 Aug 10:23
Picon
Gravatar

KDE/kdeedu/kstars/kstars/data/tools

SVN commit 844299 by asimha:

Fixing the perl script that puts ASCII data from the NOMAD catalog
into the MySQL database. It now uses a nicer table structure with no
redundant information.

CCMAIL: kstars-devel <at> kde.org

 M  +17 -38    nomaddatatomysql.pl  

--- trunk/KDE/kdeedu/kstars/kstars/data/tools/nomaddatatomysql.pl #844298:844299
@@ -38,21 +38,15 @@

 my $tbl_query = qq/
 CREATE TABLE IF NOT EXISTS `$db_tbl` (
-  `Trixel` varchar(14) NOT NULL COMMENT 'Trixel Name',
-  `HD` int NULL COMMENT 'HD Catalog Number',
+  `Trixel` int(11) NOT NULL COMMENT 'Trixel Number',
   `RA` double NOT NULL COMMENT 'RA Hours',
   `Dec` double NOT NULL COMMENT 'Declination Degrees',
   `dRA` double NOT NULL COMMENT 'Proper Motion along RA',
   `dDec` double NOT NULL COMMENT 'Proper Motion along Dec',
   `PM` double NOT NULL COMMENT 'Proper Motion (magnitude)',
-  `Parallax` double NOT NULL COMMENT 'Parallax',
-  `Mag` float NOT NULL COMMENT 'Visual Magnitude',
-  `BV_Index` float NOT NULL COMMENT 'B-V Color Index',
-  `Spec_Type` char(2) NOT NULL COMMENT 'Spectral Class',
-  `Mult` tinyint(1) NOT NULL COMMENT 'Multiple?',
-  `Var` tinyint(1) NOT NULL COMMENT 'Variable?',
-  `Name` varchar(70) default NULL COMMENT 'Long Name',
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akarsh Simha | 9 Aug 10:29
Picon
Gravatar

KDE/kdeedu/kstars/kstars/data/tools

SVN commit 844300 by asimha:

Adding the machinery required to produce binary data files for the
USNO NOMAD Catalog.

CCMAIL: kstars-devel <at> kde.org

 M  +16 -0     Makefile  
 A             nomadbinfiletester.c   [License: GPL (v2+)]
 A             nomadmysql2bin.c   [License: GPL (v2+)]

--- trunk/KDE/kdeedu/kstars/kstars/data/tools/Makefile #844299:844300
@@ -10,17 +10,26 @@

 MYSQL_CONFIG=/usr/bin/mysql_config
 KSTARS_MYSQL_DB_TO_BIN=./mysql2bin
+KSTARS_NOMAD_MYSQL_DB_TO_BIN=./nomadmysql2bin
 KSTARS_MYSQL_DB_DB=$(KSTARS_MYSQL_DB_USER)
 KSTARS_MYSQL_DB_TBL=tycho2
+KSTARS_NOMAD_MYSQL_DB_TBL=nomad

 all: mysql2bin binfiletester

 mysql2bin: mysql2bin.c
 	$(CC) $(CFLAGS) `$(MYSQL_CONFIG) --cflags` $@.c $(LDFLAGS) `$(MYSQL_CONFIG) --libs` -o $@

+nomadmysql2bin: nomadmysql2bin.c
+	$(CC) $(CFLAGS) `$(MYSQL_CONFIG) --cflags` $@.c $(LDFLAGS) `$(MYSQL_CONFIG) --libs` -o $@
+
 binfiletester: binfiletester.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akarsh Simha | 9 Aug 12:01
Picon
Gravatar

NOMAD 1e8 - the ugly way.

Hi

I managed to implement, in what I think is an ugly manner, the
handling of multiple meshes in KStars. I don't like the way I do it
now, but don't know enough OOP to decide of a better way to do things
that will still be easy to implement. So I thought I should post here
and get some feedback.

I have a patch here that adds the functionality required to load the
1e8 star catalog:
http://members.bas.org.in/kstar/USNO-NOMAD-support.patch
And some test data here:
http://members.bas.org.in/kstar/nomad_test.bz2
To use the test data, decompress it and rename it to
'USNO-NOMAD-1e8.dat' and put it in one of the KDE Standard
Directories.

Here's a summary of the changes:
1. DeepStarComponent is a copy of StarComponent that has a lot of
methods and properties removed or modified.
2. StarBlockList has an additional constructor that is called only
from DeepStarComponent, that sets a StarBlockList::deepStars to true.
I don't like the name, because there's also StarComponent::deepStars
and DeepStarComponent::deepStars and they mean different things.
3. StarBlockList::fillToMag reads data using a 16-byte deepStarData
structure or a 32-byte starData structure, depending on whether
StarBlockList::deepStars is true or not.
4. SkyMapComposite has a QList that stores pointers to any
DeepStarComponent classes. The constructor of SkyMapComposite looks
for the catalogs and adds DeepStarComponents for each of them to this
(Continue reading)

Permalink | Reply | 5 comments |
headers
James Bowlin | 9 Aug 15:57
Picon

Re: NOMAD 1e8 - the ugly way.

On Sat August 9 2008, Akarsh Simha wrote:
> I managed to implement, [...], the handling of multiple meshes in
> KStars. 

Wow!  That's great!

> I don't like the way I do it now, but don't know enough OOP to decide
> of a better way to do things that will still be easy to implement. So
> I thought I should post here and get some feedback.

I agree with the approach of getting it working ugly first and then
cleaning up the code.

> Here's a summary of the changes:
> 1. DeepStarComponent is a copy of StarComponent that has a lot of
> methods and properties removed or modified.

Sounds good.

> 2. StarBlockList has an additional constructor that is called only
> from DeepStarComponent, that sets a StarBlockList::deepStars to true.
> I don't like the name, because there's also StarComponent::deepStars
> and DeepStarComponent::deepStars and they mean different things.

I agree that it is not a good idea to have the same name mean more
than one thing.  It sounds like your subclassing ideas below will
fix this problem, but if not, I'd suggest making the names more 
specific.  For example, "DeepStars_1e8" or "DeepStars_NOMAD", or
"DeepStars_16".
(Continue reading)

Permalink | Reply | 4 comments |
headers
Akarsh Simha | 10 Aug 07:28
Picon
Gravatar

Re: NOMAD 1e8 - the ugly way.

Hi James,

I've just had a glance at your points and am planning to implement a
few of them. I should reply to each point that you made sometime later
today, but before that, I thought I should make a point about
supporting multiple file formats.

> > 3. Better than above, have a StarFileReader class that subclasses
> > from BinFileHelper and defines a way of reading one record from the
> > file and creating a StarObject out of it. This way, we could simply
> > have different versions of StarFileReader, like DeepStarFileReader,
> > USNOStarFileReader that override the StarFileReader::readStar() (or
> > whatever) method to handle different file formats. This will give us
> > enough flexibility to support USNO A or any other format (say, ones
> > from Stellarium or Cartes du Ciel). Maybe we could even have a file
> > that tells the program how to understand various data files.
> 
> I like the idea of making it easy to add support for other file formats,
> but I think having a data file to explain the formats of the other data
> files might be a bridge too far because it sounds like some significant
> work that might never get used.  

I was wrong in thinking that we might be able to support USNO A or
other catalogs. I realise that there is a major hurdle in this whole
affair, because USNO A does not use HTM but uses a simple partitioning
by (IIUC) declination ranges.

In this case, it might be best to just stick to 32-bytes and 16-bytes
per star and have a parameter in the StarBlockList constructor or
something to decide between the two.
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Bowlin | 10 Aug 08:45
Picon

Re: NOMAD 1e8 - the ugly way.

On Sat August 9 2008, Akarsh Simha wrote:
> I was wrong in thinking that we might be able to support USNO A or
> other catalogs. I realise that there is a major hurdle in this whole
> affair, because USNO A does not use HTM but uses a simple
> partitioning by (IIUC) declination ranges.

I had wondered about this but then I though you might have been
referring to simply the star record structure.

> In this case, it might be best to just stick to 32-bytes and 16-bytes
> per star and have a parameter in the StarBlockList constructor or
> something to decide between the two.

Ideally, this would simply be a field in the binary file header and
each DeepStarComponent would figure out what to do when it reads its
file header.  But if this is going to cause you extra work, it is
fine to have the star record size for each file hard coded for now.
I've envisioned a DeepStarComponent ctor that is given the file name
as one of the parameters and it then reads in all/most of the 
particulars from the file header.  But again it is fine to hard code
some or all of this information for now (and perhaps forever).

I agree that just sticking to 32-bytes and 16-bytes for now is a good
idea.

> I think I should move the Tycho-2 mag 12.5 deep star architecture
> into deepStarComponent, as you recommend, and I think I'll go ahead
> and do it.

Great.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Akarsh Simha | 10 Aug 21:56
Picon
Gravatar

Re: NOMAD 1e8 - the ugly way.

Hi James,

Thanks for your inputs. I'm yet to find time to read through the older
mail, but here are replies for this one.

> > In this case, it might be best to just stick to 32-bytes and 16-bytes
> > per star and have a parameter in the StarBlockList constructor or
> > something to decide between the two.
> 
> Ideally, this would simply be a field in the binary file header and
> each DeepStarComponent would figure out what to do when it reads its
> file header.  But if this is going to cause you extra work, it is
> fine to have the star record size for each file hard coded for now.
> I've envisioned a DeepStarComponent ctor that is given the file name
> as one of the parameters and it then reads in all/most of the 
> particulars from the file header.  But again it is fine to hard code
> some or all of this information for now (and perhaps forever).

This information is already there in the header, and we can make use
of it from there, as you suggest. I hadn't thought of this.

> I agree that just sticking to 32-bytes and 16-bytes for now is a good
> idea.

This makes things a lot more simpler.

> > Now, if we don't support other catalogs, we brings in a lot of
> > simplicity - I can retain the relatively ugly fillToMag because a
> > better solution is far too much code duplication and not worth the
> > effort, IMO. Instead, I can rename the StarBlockList::deepStars as
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Bowlin | 11 Aug 02:52
Picon

Re: NOMAD 1e8 - the ugly way.

On Sun August 10 2008, Akarsh Simha wrote:
> > The fact that you've implemented multiple meshes gives us a lot of
> > flexibility.  One approach would be to put the static stars in
> > their own DeepStarComponent and simply not do any dynamic updating
> > of that instance.  It does everything the other DeepStarComponents
> > do and less. I guess there would have to be a flag inside of
> > DeepStarComponent that would turn off the dynamic updating.  It
> > would be set either with a special constructor or with a simple
> > function call.  I think this will be cleaner and easier than
> > appending a StarBlock structure to StarComponent.  The flag is
> > checked just once or twice per draw cycle per DeepStarComponent so
> > efficiency shouldn't be a concern.
>
> But wouldn't this remove the whole point of breaking StarComponent
> into DeepStarComponent and StarComponent? 

On the contrary, it would allow us to complete the split of 
StarComponent and DeepStarComponent because it will allow us to remove
a lot of code (from StarComponent) that is still repeated in those two 
classes.  You created DeepStarComponent (I presume) by making a copy
of StarComponent and deleting a bunch of code.  Ideally all of (or most 
of) the code that is now in DeepstarComponent, you will be able to
delete from StarComponent.

We have two different perspectives: you want to split things according
to static vs. dynamic and I want to split things according to the
data structures that hold the stars.

> Are you looking at a NamedStarComponent and UnnamedStarComponent?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane