headers
Joseph Kerian | 4 Oct 19:57
Picon

Compilation of KStars/htmesh broken on FreeBSD

Regarding the first part of the patch... does kstars actually compile
on any arch that doesn't support boolean? If so... I suspect explicit
testing for those archs (Solaris?) might be easier than enumerating
the exceptions.

In the second part, LONG_LONG_MAX doesn't seem to be defined anywhere
in C++98 or C99. limits.h (or climits) defines LLONG_MAX, which
perhaps this line should be changed to outright.

--a non kstars dev
Joe

===================================================================
--- kstars/htmesh/SpatialGeneral.h      (revision 720996)
+++ kstars/htmesh/SpatialGeneral.h      (working copy)
@@ -75,7 +75,7 @@

 // emulate the standard bool type where not supported by compiler

-#  if !defined(SXGENERAL_H) && !defined(__sgi) && !defined(__linux)
&& !defined(_WIN32)
+#  if !defined(SXGENERAL_H) && !defined(__sgi) && !defined(__linux)
&& !defined(_WIN32) && !defined(__FreeBSD__)
 #    ifdef __unix
 /*
  * The following ifndef must ALWAYS be present since C++ may use
Index: kstars/htmesh/SkipListElement.h
===================================================================
--- kstars/htmesh/SkipListElement.h     (revision 720996)
+++ kstars/htmesh/SkipListElement.h     (working copy)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 7 Oct 01:21

KDE/kdeedu/kstars/kstars

SVN commit 722230 by harris:

Printing the sky map now works.

This is a pretty extensive change, but almost all of it was a simple
refactoring.  Namely, instead of passing a "scale" argument to dozens
of draw-related functions, the scale is now a member variable of SkyMap.

As a reminder, the scale factor is always 1.0, unless we are printing.
Then the scale factor is determined by the properties of the printer.
Essentially, it's the ratio of the width (or height) of the printer's
QPaintDevice to that of the SkyMap widget.

This is a nice change, because few people knew what scale was for, so
now we don't have to pass a mysterious argument all over the codebase.
Most of the changes in this commit involve the removal of the scale
argument from various functions.

Also, I am using QPrinter and QPrintDialog instead of KPrinter,
because from what I've read, KPrinter will probably not be ready for
KDE-4.0.

CCMAIL: kstars-devel <at> kde.org

 M  +20 -6     kstarsdcop.cpp  
 M  +4 -4      skycomponents/asteroidscomponent.cpp  
 M  +1 -2      skycomponents/asteroidscomponent.h  
 M  +5 -5      skycomponents/cometscomponent.cpp  
 M  +1 -2      skycomponents/cometscomponent.h  
 M  +3 -3      skycomponents/constellationnamescomponent.cpp
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 12 Oct 18:38

KDE/kdeedu/kstars/kstars/data

SVN commit 724557 by harris:

FIx some broken URLs, and add an image of Jupiter from 
NASA's New Horizons mission.

CCMAIL: kstars-devel <at> kde.org

 M  +5 -4      image_url.dat  
 M  +2 -2      info_url.dat  

--- trunk/KDE/kdeedu/kstars/kstars/data/image_url.dat #724556:724557
@@ -48,7 +48,7 @@
 NGC 253:Show HST Image (1998):http://imgsrc.hubblesite.org/hu/db/1998/42/images/a/formats/web_print.jpg
 NGC 300:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2004/13/images/e/formats/web_print.jpg
 NGC 346:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2005/04/images/a/formats/web_print.jpg
-NGC 604:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2003/30/images/b/formats/web_print.jpg
+NGC 604:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2003/30/images/a/formats/web_print.jpg
 NGC 891:Show HST Image:http://imgsrc.hubblesite.org/hu/db/1999/10/images/a/formats/web_print.jpg
 NGC 1275:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2003/14/images/a/formats/web_print.jpg
 NGC 1300:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2005/01/images/a/formats/web_print.jpg
@@ -78,7 +78,7 @@
 NGC 2736:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2003/16/images/a/formats/web_print.jpg
 NGC 2787:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2002/07/images/a/formats/web_print.jpg
 NGC 2903:Show HST Image:http://imgsrc.hubblesite.org/hu/db/1999/10/images/a/formats/web_print.jpg
-NGC 3079:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2001/28/images/a/formats/web_print.jpg
+NGC 3079:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2001/28/images/b/formats/large_web.jpg
 NGC 3132:Show HST Image:http://imgsrc.hubblesite.org/hu/db/1998/39/images/a/formats/web_print.jpg
 NGC 3310:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2001/26/images/a/formats/web_print.jpg
 NGC 3314:Show HST Image:http://imgsrc.hubblesite.org/hu/db/2000/14/images/a/formats/web_print.jpg
@@ -115,7 +115,7 @@
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Kotek | 14 Oct 22:50
Picon

HTM questions

Hi,
I have a few questions about HTM indexing mechanism. My program is
using Java version. I know howto convert point to it trixel
representation.  My program is using it and it works as charm.

But after a few days of trying I still do not know how:

1) convert area (ellipse, pollygon) to set of trixels
2) get neighbours of trixel in defined distance (ie get all objects in
distance from point)
3) convert trixel to ra dec coordinates (ie inverse function).

Did you handle this in KStars? Can you point me to source code?

Thanks Jan Kotek
http://kotek.net/opencoeli

PS:
There is also an alternative to HTM:
HEALPix (Hierarchical Equal Area isoLatitude Pixelization).
http://healpix.jpl.nasa.gov/index.shtml

Features are impressive..  It is more simplier then HTM (does not uses
trigonometry), well documented and should be very portable.
Permalink | Reply | 3 comments |
headers
James Bowlin | 14 Oct 23:55
Picon

Re: HTM questions

On Sun October 14 2007, Jan Kotek wrote:
> 1) convert area (ellipse, pollygon) to set of trixels

In kstars/kstars/htm/HTMesh.cpp there is code that does this for
circles, lines, triangles and quadrilaterals.  For higher order
polygons and segmented lines there are crude methods in
kstars/skycomponents/skymesh.cpp that make repeated calls to
the above HTMesh methods, storing the resulting trixels in a QHash.

The higher order polygon code could probably be vastly improved.
If you come up with a better way to handle non-convex polygons,
please let us know about it.  Also, I think the code in HTMesh.cpp
that handles single line segments could also be improved.

This code is working for us for now but it may need to be tweaked
before it can work for you.  It is not yet a general purpose solution.

We had no need for ellipses so I didn't explore for a solution.
I suggest simply using a circle that contains the ellipse.  This
is fast even though it might include a few extra trixels.  In
general, the gains from the HTM index are so great that a few
extra trixels here and there are no big deal.  Our higher order
polygon code also generates extra trixels for non-convex polygons
but the extremely minor benefits from fixing this didn't seem
to warrant the extra coding effort.  

In KStars, after initialization, the only HTM actions we perform
are point and circle lookups which are both very fast.  This is
why we didn't put in a lot of effort into optimizing the more
complicated indexing.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jan Kotek | 15 Oct 02:43
Picon

Re: HTM questions

Hi James,
Thanks for references,  thants exactly what I needed. It will take me
some times to read that source, so now just quick reaction.

> > 2) get neighbours of trixel in defined distance (ie get all objects
> > in distance from point)
>
> This is done by creating an index of the objects.  For point objects,
> the index is an array (or hash) of lists of pointers to the objects.
> The trixels are the index of the array.

So if I understand correctly, there is no math function for getting
neigbourh trixels,  you are just using precallculated tables? I am
planing level > 10 with many items, it can be problem.

There are some comparations of Healpix versus HTM. In short: healpix
is 10x faster becouse it does not use trigonometry (slow sin and cos),
but just some sort of coordinate division.

http://www.google.com/search?q=htm+versus+healpix&ie=UTF-8&oe=UTF-8

I will propably switch, bcos sky indexing is crutial for my
application. I am using sql and there is risk that I will need to port
indexing algorthm to TSQL language. Healpix core is more simplier. And
I also like documented source :-)

Regards,
Jan
Permalink | Reply | 1 comment |
headers
James Bowlin | 15 Oct 03:52
Picon

Re: HTM questions

On Sun October 14 2007, you wrote:
> > > 2) get neighbours of trixel in defined distance (ie get all
> > > objects in distance from point)
> >
> > This is done by creating an index of the objects.  For point
> > objects, the index is an array (or hash) of lists of pointers to
> > the objects. The trixels are the index of the array.
>
> So if I understand correctly, there is no math function for getting
> neigbourh trixels,  

I don't know.  We never needed it so I didn't look.

> you are just using precallculated tables? 

For the stars (in kstars/skycomponents/starcomponent.cpp) there is
a data member called m_starIndex.  The size of this array is the number
of trixels.  Each element of the array is a list of pointers to star
objects.  The list contains all of the stars that are in a given
trixel.  In a relational database you would use a table linking
trixels to stars with a one (trixel) to many (stars) relationship.

We find all of the stars within a circular aperture by using the
HTM to get a list of all of the trixels needed to cover the aperture
and then for each trixel in that list we use the m_starIndex array to
get all of the stars in that trixel.

If your are using a level-10 mesh then the use of an array might
be impractical since it would have to have 8M elements.  We left
the mesh level as a free (compile time) parameter and then tuned it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 15 Oct 23:21

strategies for expanding the size of catalogs

Hello,

One of the most popular complaints about KStars is that its catalogs are too 
small, and specifically that the star catalog doesn't go deep enough.

What would it take to include the HST Guide Star Catalog in KStars (about 15 
million stars, about 115 times the number now included)?  

Here's what I have in mind, I'd like to hear other thoughts on this:

We store all stars brighter than 6.0 (or some similar bright limit) in a 
single data file.  These objects are always loaded into memory when the 
program is running.

For fainter stars (6.0 to 15.0), the data files are split by region on the 
sky, so that we can dynamically load only those stars that are needed for the 
location that is currently being drawn.  In fact, the GSC is already split 
into 9537 regions.  This might be a good number of regions for us.

If we do this, then we're obviously going to be accessing the disk a lot while 
the program runs.  To keep the interface responsive, we can do things like:

* use binary data files to improve load times.

* sort each regional star data file by magnitude, so that we can stop reading 
the file when the zoom-dependent faint limit is reached.

* use "progressive drawing", where stars appear in the map as they are loaded, 
rather than waiting for the data stream before drawing the sky.  Obviously, 
we wouldn't draw each star as it's loaded, but for example whenever N
(Continue reading)

Permalink | Reply | 9 comments |
headers
James Bowlin | 16 Oct 01:01
Picon

Re: strategies for expanding the size of catalogs

On Mon October 15 2007, Jason Harris wrote:
> What do you think?  Is it a good idea to keep the brightest stars as
> a separate, non-regionalized catalog?  Will the progressive drawing
> work?

I think this is a wonderful idea Jason.  I agree with keeping the
brightest stars separate.  We are currently using a level-3 HTM
which has 512 region.  Keeping the dimmer stars in 512 different
batches makes sense but I have no idea what the optimal number
of regions is.  Another thing to consider is having redundant data
on disk in order to optimize memory usage.  In that scenario, the
brightest stars would be in one file (or batch) but they would
also be repeated in each of the regions so that when the user zooms
in to a region, we can dump the global set of brigtest stars.
We could even have several levels of regional files with a smaller
set of regional files that don't go to the dimmest levels.

I think we would get the best disk performance using flat binary
files sorted by brightness as you suggest.  Unfortunately binary
format will not be portable so we would probably want to generate
the binary files at install time or have separate data sets for
different architectures.  Also, I don't know if C++ is designed
to let us initialize objects by just loading in memory.  In C
and assembly, I am accustom to reading from disk directly into
essentially an array of structs.

Another idea would be to use a MySQL backend but I think we can
actually get better performance out of flat binary files.

Instead of (or in addition to) giving users a faintness magnitude
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jason Harris | 16 Oct 02:25

Re: strategies for expanding the size of catalogs

Hi James,

On Monday 15 October 2007 16:01, James Bowlin wrote:
> I think we would get the best disk performance using flat binary
> files sorted by brightness as you suggest.  Unfortunately binary
> format will not be portable so we would probably want to generate
> the binary files at install time or have separate data sets for
> different architectures.  Also, I don't know if C++ is designed
> to let us initialize objects by just loading in memory.  In C
> and assembly, I am accustom to reading from disk directly into
> essentially an array of structs.
>
I hadn't considered the non-portability issue.  Probably creating the binary 
data files at compile time is the way to go.  Someone in KDE-land must be 
doing this already...

It would be nice if we knew ahead of time how much of the data file to read to 
reach magnitude X.  However, I think the variable-length string names make 
this difficult, unless we pad each object's name data to be the same number 
of characters.  Anyway, maybe this is not important, if we will just be 
reading records sequentially from the beginning of each file.

> Another idea would be to use a MySQL backend but I think we can
> actually get better performance out of flat binary files.
>
> Instead of (or in addition to) giving users a faintness magnitude
> slider we could give them a slider for how much memory to use for
> holding stars.  The idea is that we can usually keep all of the
> stars we display in RAM and only hit the disk when the user zooms
> or pans (or the time changes significantly).  We should avoid
(Continue reading)

Permalink | Reply | 4 comments |

Gmane