gmane.comp.kde.devel.kstars

Re: GSoC 2012: Project Introduction: Logs and Data

Aleksey Khudyakov — 2012-05-02T10:03:41

First and obvious problem is then nor name, nor name and HD index are
good identifier for sky object. First most faint stars are nameless, and most of
faint stars even do not have HD index (if we add USNO catalog). And to make
things worse names depend on current language. I think it already caused bugs

So some robust identifier is needed. There is uid method which is remnant of
unsuccessful attempt of creating such id. It's buggy and fairly
bitrotten but can use
it as starting point. There were few discussions about it on the list.

Re: GSoC 2012: Project Introduction: Logs and Data

Rishab Arora — 2012-05-01T14:37:42

Apologies for the late reply.
Very short version: http://blog.rishab.in/the-log-viewer/

Yes, I plan to separate the storage of observation logs from SkyObject.
From my current understanding, KStars currently writes the user log to a
file as well as stores it in "userlog.dat" when it needs to save data.
During initialization, the log is read from the text files and stored with
the SkyObject.

In my proposal, I plan to make a separate database in which I will (along
with all required information like seeing, equipment etc) store an
identifier for the star. This identifier could be the 'name' as is being
used currently, but I plan to use the HD index instead so that the logs
aren't limited to a set number of stars. Similarly, a unique identifier
(which will be assigned when I port the DSO catalog to SQLite) will be
used.

Using the name will make it work for all the objects it currently supports
at least.

When the detail dialog will display the log tab, I plan to query the
database and populate a list of logs

Fwd: Re: GSoC 2012: Project Introduction: Logs and Data

Aleksey Khudyakov — 2012-04-30T09:26:56

Forgot to CC list

-------- Original Message --------
Subject: Re: [Kstars-devel] GSoC 2012: Project Introduction: Logs and Data
Date: Sun, 29 Apr 2012 21:30:58 +0400
From: Aleksey Khudyakov <alexey.skladnoy< at >gmail.com>
To: Rishab Arora <ra.rishab< at >gmail.com>

On 26.04.2012 20:44, Rishab Arora wrote:
There is a problem. Current implementation stores logs and some other
info in the SkyObject. This approach is problematic for following
reasons: is object is destroyed all data is lost. At the moment only
faint star are loaded and unloaded to/from memory on demand.
Galaxies are very numerous too so at some point we may want to unload
them too. Also there is no easy way to get all observation logs etc.

It sounds like you want to store observation log separately from
sky object. So how do you plan link them?

 From UI point. it's very bad to force user to fill in _all_ fields.
Users are lazy and always have strange ideas. It's better to avoid
annoying constraints like: «you'll have to explicitly state all
informa

Re: GSoC 2012: Project Introduction: Logs and Data

Rishab Arora — 2012-04-26T16:44:56

Hey Aleksey!

I'll maintain communication using the mailing list for sure.

Regarding the observation logs, currently we have a feature which lets us
save a plain text entry for named objects (accessed by right clicking ->
logs). So if you wish to store what you saw while observing, say Saturn,
you'll have to explicitly state all information like the equipment you've
used, date, time etc which is already available to KStars.
I plan to replace this view with a new interface linked with a database.
Hence, when you right click and select Logs in the proposed implementation,
you'll get a list of all previous entries. And the option to add new
entries. And to export these entries (as OAL files, hopefully)



On Thu, Apr 26, 2012 at 6:23 PM, Aleksey Khudyakov <
alexey.skladnoy< at >gmail.com> wrote:

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

Re: GSoC 2012: Project Introduction: Logs and Data

Aleksey Khudyakov — 2012-04-26T12:53:27

Could you elaborate this, In particular what are observation logs and how do
you plan to store them? There are some feature which is vaguely simalar,
although it doesn't seem to be very usable.


Yes. Currently text files are parsed in very ad hoc way. We had few crash
bugs because parsers didn't check for all cases. It will be useful by itself.




Please keep you email communication on the mailing list. Probably
I and others will have something to say as well

GSoC 2012: Project Introduction: Logs and Data

Rishab Arora — 2012-04-25T21:24:57

Hello everyone! :)

I'm Rishab, and as Samikshan mentioned, one of the two students accepted
for KStars this year! Needless to say, I'm really excited to work on KStars
this summer :)

I am relatively new to the community, so I'll take a moment to introduce
myself. I'm Rishab Arora (idling on IRC as 'spacetime'), an undergraduate
student of Information Technology from New Delhi, India. Currently in my
third year of college, I take particular interest in handling large amounts
of data. I'm an amateur astronomer and have a habit of naming devices,
heuristics and algorithms (or anything I can name) after heavenly bodies,
so I think I should fit right in. ;)

I'll start with a small description of what I've be aiming for this summer.
My proposal "Improving Data Storage, Logs and adding DSO catalogs to
KStars" involves
a. building a log viewer which will enable users to 'store' observation
logs in an internal database
b. improving the way data files handled, specifically the parsing of text
files. I'll be making

GSoC 2012 Project Introduction: More beginnerfriendly KStars

Samikshan Bairagya — 2012-04-25T17:29:00

Hi Everybody!

My project proposal for Google Summer of Code, 2012, with the idea -
"Make KStars more usable for beginner astronomers by adding
'What's Interesting...' feature to KStars and by making 'Star Hopping'
feature user-configurable" - has been accepted. It is really exciting
and I am confident that this would be a rewarding experience for me,
the community and the users of KStars.

Through these features KStars will become more friendly and usable for
beginner and intermediate level astronomers.

Anyway, even though I am not new to this list and have posted here in the
past, I would like to introduce myself here in brief. I am an undergraduate
student of Computer Science and Engineering at National Institute of
Technology in Durgapur, India. I have made contributions to KStars as a
part of Season of KDE, 2011 and afterwards.

To know more about me, my project proposal and previous work you can
take a look at my blog at http://samxan.wordpress.com/ . I will regularly
be posting there about my work pr

Re: [kstars] kstars: Hmm, we shouldn't have a KStars-standard gitignore. Let users define

Rafal Kulaga — 2012-04-25T07:50:54

Of course, what entries do we want to have in .gitignore is a
different story ;-)



2012/4/25 Rafal Kulaga <rl.kulaga< at >gmail.com>:

Re: [kstars] kstars: Hmm, we shouldn't have a KStars-standard gitignore. Let users define

Rafal Kulaga — 2012-04-25T07:41:47

Hi Akarsh!

It's not unusual for the repo to have its .gitignore. Even the kernel
repo has one :-) I'd leave it.

Cheers,
Rafal


2012/4/25 Akarsh Simha <akarshsimha< at >gmail.com>:

Re: Errors in StarBlockFactory / StarBlockList

Aleksey Khudyakov — 2012-04-21T16:47:43

I don't know how things work but what about checking checking
invariants after every modificication of whatever gets modified.
Programm will be slow but you'll find exact moment of breakage

Errors in StarBlockFactory / StarBlockList

Akarsh Simha — 2012-04-18T07:46:24

Hi

I keep getting this and other similar output on the terminal:

kstars(30667) StarBlockFactory::markNext: WARNING: Marking block with faint mag =  12.79  after block with faint mag  15.26 in trixel 32606

This is something very bad, because if this is real, then half the
stars are not going to be drawn. Looking through the code, I can't
tell why this is happening. I ran a check on my catalog for incorrect
magnitude order, but the tester (data/tools/nomadbinfiletester)
reported no errors.

This was very likely introduced after Akademy 2008 (August 2008),
because I'm almost certain that I weeded out most of the bugs before
that, and something like this would have almost certainly caught my
attention. However, these bugs are also hard to find because they
could happen only for specific regions of the sky. In this case, the
output on my terminal shows this happening for trixels 32606 and 32607
which seem to lie around M 34 in Perseus.

Alexey introduced some changes in this code, but looking through them,
I d

Re: GSoC slots

Rafal Kulaga — 2012-04-16T06:47:43

Hi everybody,

+1 to this. I would also like to add that we have received 3 proposals
based on the same project idea (WUT & star hopping) and they are all
really good. It was hard to pick the best one.

Cheers,
Rafal



2012/4/11 Akarsh Simha <akarshsimha< at >gmail.com>:

USNO NOMAD catalog artefacts near bright stars

Akarsh Simha — 2012-04-15T21:22:47

The USNO NOMAD catalog seems to have artefacts near bright stars. I'm
guessing that these owe their existence to diffraction spikes and
glare, as is seen in the POSS plates. AFAIK, NOMAD uses the POSS
plates to find stars.

For comparison, consider the query on NOMAD here:
http://www.nofs.navy.mil/tmp/fchTdJ3EC_fch.html

The same field, with the same central star in the POSS [Blue] plates:
http://archive.stsci.edu/cgi-bin/dss_search?v=poss2ukstu_blue&r=18+12+24&d=-07+17+44&e=J2000&h=15.0&w=15.0&f=gif

Notice how some stars are spurious and some magnitudes are
over-estimated in NOMAD, possibly due to the diffraction spikes.

The same artefacts are found in KStars -- all bright stars usually
have a string of stars flanking them, that are usually aligned
approximately with the north-south direction. I guess these artefacts
are the result of diffraction spikes. It is therefore unlikely that
these disagreements with DSS images are bugs in KStars -- they are
more likely catalog artefacts.

Regards
Akarsh

Re: Some observations regarding USNO NOMAD in KStars

Akarsh Simha — 2012-04-15T08:40:52

This is embarrassing -- I didn't know revision hashes change when
rebasing. Here's the correct revision number:

3c6204ab85ad7c010bd03f647196def875f9d7f4 (currently HEAD)

Regards
Akarsh

Re: Some observations regarding USNO NOMAD in KStars

Akarsh Simha — 2012-04-15T08:34:58

Hi,

Here's a tarball containing a bunch of plots of the region around
trixel 12310. The x-axis is right ascension in hours and the y-axis is
declination in degrees.

http://www.ph.utexas.edu/~asimha/KStars-NOMAD-Tests.tar.bz2

Test 1: Shows that there are sizable differences between data dumps of
     USNO NOMAD made with different criteria.

Test 2: Shows the effect of precession computed by KStars, between
     J2000.0 and 2012.3

Test 3: The precessed coordinates of Test 2 were shifted by constant
     RA and Dec shifts to make them coincide with the unprecessed
     J2000.0 coordinates. Note the existence of spuriously
     introduced precessed stars (green crosses that are not
     coincident with a red plus). Note also the existence of
     outliers that did not have precessed counterparts (red plusses
     that are not coincident with green crosses). Note also that
     these red outliers form a nearly right-angled triangle on the
     top right of the image. Hmmm...

Test 4: The red outlie

Some observations regarding USNO NOMAD in KStars

Akarsh Simha — 2012-04-15T07:54:33

Hi

I did some tests on the USNO NOMAD catalog machinery in KStars
today. I'm sending a copy of these to the mailing list both for
documentation / archival purposes and so that others can look it up
when required.

This was prompted because I noticed that the star field in Trixel
12310 (of the "deep" level 6 SkyMesh) did not seem to match with the
DSS image of the same region. This could involve precession and might
be related / a bug introduced by the short-circuiting of precession,
nutation and aberration computations when the simulation time elapsed
since the last such calculation is less than about a minute (see
revision 832469e64f222e6d1cc9da77a7b4587db20c05ba). Or it could just
be that the catalog (with the search criteria used to limit down to a
100 million stars in KStars) disagrees with the POSS plates.

The following are the results of some checks done against trixel 12310
/ a rectangular patch in (RA, Dec) around trixel 12310:

1. (ra, dec) seems to be recomputed when the simulation clock is
   su

[kstars] kstars: 1. Rename the 'Backends' tab under 'Advanced' options to 'General' and

Akarsh Simha — 2012-04-14T12:41:54

Git commit 624f0c5faba1daf3558159bcd1eff7fe35c0e4cb by Akarsh Simha.
Committed on 14/04/2012 at 14:37.
Pushed by asimha into branch 'master'.

1. Rename the 'Backends' tab under 'Advanced' options to 'General' and
   add a "DSS Imagery" group in it.

2. DSS Image default size / padding is now configurable.

CCMAIL: kstars-devel< at >kde.org

M  +13   -0    kstars/kstars.kcfg
M  +4    -3    kstars/ksutils.cpp
M  +152  -47   kstars/options/opsadvanced.ui
M  +1    -1    kstars/tools/observinglist.cpp

http://commits.kde.org/kstars/624f0c5faba1daf3558159bcd1eff7fe35c0e4cb

diff --git a/kstars/kstars.kcfg b/kstars/kstars.kcfg
index 633c4d4..258d0f6 100644
--- a/kstars/kstars.kcfg
+++ b/kstars/kstars.kcfg
< at >< at > -1130,4 +1130,17 < at >< at >
       <whatsthis>List of selected satellites.</whatsthis>
     </entry>
   </group>
+  <group name="General">
+    <entry name="DefaultDSSImageSize" type="Double">
+      <label>Default size for DSS images</label>
+      <whatsthis>The default size for DSS images downloaded from the internet.</

[kstars] kstars: Lots of changes that were tightlycoupled:

Akarsh Simha — 2012-04-14T11:55:34

Git commit c1f1f8e133248d319d6523c9c6ea6dd5156aa3ad by Akarsh Simha.
Committed on 14/04/2012 at 13:50.
Pushed by asimha into branch 'master'.

Lots of changes that were tightly coupled:

1. Reorganize options related to Observing List in kstars.kcfg under a
   new group.

2. Revamp the design of the "Advanced" options section to introduce a
   Tab Widget [I need feedback on this decision]. This is so that we
   can put all the advanced options in there without any clutter. [Q:
   Does observing list belong there?]

3. Remove the hackish DSS vs. SDSS preference option in the Observing
   List view and introduce the setting in the Advanced options under
   Observing List.

CCMAIL: kstars-devel< at >kde.org

M  +27   -16   kstars/kstars.kcfg
M  +502  -469  kstars/options/opsadvanced.ui
M  +2    -2    kstars/tools/observinglist.cpp
M  +0    -7    kstars/tools/observinglist.ui

http://commits.kde.org/kstars/c1f1f8e133248d319d6523c9c6ea6dd5156aa3ad

diff --git a/kstars/kstars.kcfg b/kstars/kstars.kcfg
index b8c8714..87

GSoC slots

Akarsh Simha — 2012-04-11T06:23:39

Hi

I suppose all you students are on this mailing list. This is that part
of the timeline when the Google distributes its limited slots to open
source projects, and large open source projects distribute those even
more limited precious slots to various proposals in KDE. While
students owe their "allegiance" only to the project and their summer
job, mentors have to see the interest of both KDE and the open source
community at large, and the students at the same time. It's hard to be
completely fair to one party without doing some injustice to the
other. That's part of the reason I usually recommend that students
apply to multiple projects (despite that not being in the interest of
the organization), because you shouldn't lose out just because of
other factors.

Let us hope that all turns out well at the end of the day, but I'm
just writing this to prepare us all in advance and point out to you
that if we didn't pick you, it doesn't mean that you weren't good
enough to do a GSoC. It's just that there are too

Dead code removal

Aleksey Khudyakov — 2012-04-08T20:36:40

Hi!

I've just pushed commits which remove a bunch of dead code
from KStars. I've used callcatcher to find it[1].

If you think that some of the code should be kept despite being unused 
then revert relevant changeset.


[1] http://www.skynet.ie/~caolan/Packages/callcatcher.html

Re: Bug with inline image display

Rafal Kulaga — 2012-04-05T12:34:53

Hi Manfred!

Thanks for your report. I'll take a look at this.

Cheers,
Rafal



2012/3/31 Manfred G Kitzbichler <manfred.kitzbichler< at >gmail.com>: