Can you all please remove my email address
photographyworkaholics gmail.com
as this email doesn't concern me in any way. It came to me initially by
mistake as the sender entered my address in error.
Thank you
Jules
On 14 May 2016 15:04, <stellarium-pubdevel-requ...@lists.sourceforge.net>
wrote:
> Send Stellarium-pubdevel mailing list submissions to
> stellarium-pubdevel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
> or, via email, send a message with subject or body 'help' to
> stellarium-pubdevel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> stellarium-pubdevel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Stellarium-pubdevel digest..."
>
>
> Today's Topics:
>
> 1. Re: RA/DEC and ALT/AZ information in Vec3f classes
> (Alexander Wolf)
> 2. Re: RA/DEC and ALT/AZ information in Vec3f classes (Georg Zotti)
> 3. Re: RA/DEC and ALT/AZ information in Vec3f classes
> (Andr? Moutinho)
> 4. VSOP87 doubt (Andr? Moutinho)
> 5. Simple J2000 to Altaz conversion help (Andre Moutinho)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 13 May 2016 11:27:01 +0700
> From: Alexander Wolf <alex.v.w...@gmail.com>
> Subject: Re: [Stellarium-pubdevel] RA/DEC and ALT/AZ information in
> Vec3f classes
> To: Stellarium developers public mailing list
> <stellarium-pubdevel@lists.sourceforge.net>
> Message-ID:
> <
> cambjemuwz+lrr+yzd-gux-d5bu8bukarhkyysqus2ymmh-d...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi!
>
> 2016-05-13 8:27 GMT+07:00 Andr? Moutinho <mouti...@gmail.com>:
>
> > Hello all,
> >
> > I have noticed the transformation function ?project? uses vector Vec3f
> > classes as input and output parameters.
> >
> > How is the RA/DEC and ALT/AZ information stored in such classes? And the
> > x,y position in screen?
> >
>
> Please see StelUtils.(hpp|cpp) for finding conversion of coordinates.
>
> --
> With best regards, Alexander
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Fri, 13 May 2016 11:00:32 +0200
> From: Georg Zotti <georg.zo...@univie.ac.at>
> Subject: Re: [Stellarium-pubdevel] RA/DEC and ALT/AZ information in
> Vec3f classes
> To: Stellarium developers public mailing list
> <stellarium-pubdevel@lists.sourceforge.net>
> Message-ID:
> <2ba73f44c01ef5cc83f4b0ff518b8...@webmail2016.univie.ac.at>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> They should usually be unit vectors in the sphere. (Sometimes I think
> the length is <>1, but conceptually it should be 1. Use normalize() in
> doubt.)
>
> When used as screen coordinates, it's x/y directly (I think), or
> viewport-related. But this is a different transformation and should be
> documented.
>
> G.
>
>
> Am 13.05.2016 06:27, schrieb Alexander Wolf:
> > Hi!
> >
> > 2016-05-13 8:27 GMT+07:00 Andr? Moutinho <mouti...@gmail.com>:
> >
> >> Hello all,
> >>
> >> I have noticed the transformation function ?project? uses vector
> >> Vec3f classes as input and output parameters.
> >>
> >> How is the RA/DEC and ALT/AZ information stored in such classes? And
> >> the x,y position in screen?
> >
> > Please see StelUtils.(hpp|cpp) for finding conversion of coordinates.
> >
> > --
> > With best regards, Alexander
> >
> ------------------------------------------------------------------------------
> > Mobile security can be enabling, not merely restricting. Employees who
> > bring their own devices (BYOD) to work are irked by the imposition of
> > MDM
> > restrictions. Mobile Device Manager Plus allows you to control only the
> > apps on BYO-devices by containerizing them, leaving personal data
> > untouched!
> > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> > _______________________________________________
> > Stellarium-pubdevel mailing list
> > Stellarium-pubdevel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 13 May 2016 18:51:51 -0300
> From: Andr? Moutinho <mouti...@gmail.com>
> Subject: Re: [Stellarium-pubdevel] RA/DEC and ALT/AZ information in
> Vec3f classes
> To: stellarium-pubdevel@lists.sourceforge.net
> Message-ID:
> <
> cacix5c0mfofn_ms5znyapoybg-fvexbc_dtgqacmvdxyt9n...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Thank you!
>
> Have found them
>
> Andre
>
>
> Hi!
>
>
>
> 2016-05-13 8:27 GMT+07:00 Andr? Moutinho <mouti...@gmail.com>:
>
> Hello all,
>
> I have noticed the transformation function ?project? uses vector Vec3f
> classes as input and output parameters.
>
> How is the RA/DEC and ALT/AZ information stored in such classes? And the
> x,y position in screen?
>
>
>
> Please see StelUtils.(hpp|cpp) for finding conversion of coordinates.
>
>
>
> --
>
> With best regards, Alexander
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Fri, 13 May 2016 19:05:13 -0300
> From: Andr? Moutinho <mouti...@gmail.com>
> Subject: [Stellarium-pubdevel] VSOP87 doubt
> To: stellarium-pubdevel@lists.sourceforge.net
> Message-ID:
> <
> cacix5c0bga+sdznagw-zvo_wtjwryuozf0kxxvergfgn4dh...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello all,
>
> I working on a project and I need plot only stars in a map from an observer
> located on Earth.
>
> I have found some VSOP87 transformation matrices and I would like to know
> if I will need such transformation for my case. Asking this because I have
> searched VSOP87 and it seems it is related to planets location and I will
> not plot planets. Or I am wrong?
>
>
> matEquinoxEquToJ2000 = matVsop87ToJ2000 * getRotEquatorialToVsop87();
> matJ2000ToEquinoxEqu = matEquinoxEquToJ2000.transpose();
> matJ2000ToAltAz = matEquinoxEquToAltAz*matJ2000ToEquinoxEqu;
>
> Can anyone explain the function of getRotEquatorialToVsop87()?
>
> Thanks
> Andre
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: Sat, 14 May 2016 11:04:25 -0300
> From: "Andre Moutinho" <mouti...@gmail.com>
> Subject: [Stellarium-pubdevel] Simple J2000 to Altaz conversion help
> To: "Stellarium developers public mailing list"
> <stellarium-pubdevel@lists.sourceforge.net>
> Message-ID: <001e01d1ade9$87695ef0$963c1cd0$@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello all,
>
>
>
> I am trying to get the function j2000ToAltAz() work as simple as possible.
> But my test case is not returning a valid RA/DEC to ALT/AZ conversion.
>
>
>
> I have made getRotEquatorialToVsop87() returns Mat4d::identity() as a first
> approach to make code simple. I have noticed that
> getRotEquatorialToVsop87()
>
> uses JDE and this variable has a previous state (time) that I will not have
> in my application so I don't know how to solve this because my application
> will only plot a static stellar map for a certain date/time/location. Maybe
> returning an identity matrix would not change much the result.
>
>
>
> I may be trying something stupid but please forgive me because I don't have
> much knowledge in this subject. Hope someone can help me.
>
>
>
>
>
> Thanks a lot
>
> Andre
>
>
>
> Here is the code:
>
>
>
>
>
> // Matrices used for every coordinate transfo
>
> Mat4d matAltAzToEquinoxEqu; // Transform from topocentric
> altazimuthal coordinate to Earth Equatorial
>
> Mat4d matEquinoxEquToAltAz; // Transform from Earth
> Equatorial to topocentric (StelObserver) altazimuthal coordinate
>
> Mat4d matEquinoxEquToJ2000; // For Earth, this is almost the
> inverse precession matrix, =Rz(VSOPbias)Rx(eps0)Rz(-psiA)Rx(-omA)Rz(chiA)
>
> Mat4d matJ2000ToEquinoxEqu; // precession matrix
>
> Mat4d matJ2000ToAltAz;
>
> Mat4d matAltAzModelView; // Modelview matrix for
> observer-centric altazimuthal drawing
>
> Mat4d invertMatAltAzModelView; // Inverted modelview matrix for
> observer-centric altazimuthal drawing
>
>
>
>
>
> const double JD_SECOND=0.000011574074074074074074; // 1/(24*60*60)=1/86400
>
> const double JD_MINUTE=0.00069444444444444444444; // 1/(24*60) =1/1440
>
> const double JD_HOUR =0.041666666666666666666; // 1/24
>
> const double JD_DAY =1.;
>
> const double ONE_OVER_JD_SECOND = 24 * 60 * 60; // 86400
>
>
>
> QPair<double,double> JD; // From 0.14 on: JD.first=JD_UT,
> JD.second=DeltaT=TT-UT. To gain JD_TT, compute JDE=JD.first+JD.second or
> better just call getJDE()
>
> #define LATITUDE 51.76954
>
> #define LONGITUDE 4.605606
>
>
>
>
>
> const Mat4d
> matJ2000ToVsop87(Mat4d::xrotation(-23.4392803055555555556*(M_PI/180)) *
> Mat4d::zrotation(0.0000275*(M_PI/180)));
>
> const Mat4d matVsop87ToJ2000(matJ2000ToVsop87.transpose());
>
>
>
>
>
> Mat4d getRotEquatorialToVsop87()
>
> {
>
> Mat4d rval = Mat4d::identity();
>
> return rval;
>
> }
>
>
>
> Mat4d getRotAltAzToEquatorial(double JD)
>
> {
>
> double lat = LATITUDE;
>
> double lng = LONGITUDE;
>
> if( lat > 90.0 ) lat = 90.0;
>
> if( lat < -90.0 ) lat = -90.0;
>
> return Mat4d::zrotation((getSiderealTime(JD)+lng)*M_PI/180.)*
> Mat4d::yrotation((90.-lat)*M_PI/180.);
>
> }
>
>
>
> update()
>
> {
>
> matAltAzToEquinoxEqu = getRotAltAzToEquatorial(getJD());
>
> matEquinoxEquToAltAz = matAltAzToEquinoxEqu.transpose();
>
> matEquinoxEquToJ2000 = matVsop87ToJ2000 *
> getRotEquatorialToVsop87();
>
> matJ2000ToEquinoxEqu = matEquinoxEquToJ2000.transpose();
>
> matJ2000ToAltAz = matEquinoxEquToAltAz*matJ2000ToEquinoxEqu;
>
> }
>
>
>
> Vec3d j2000ToAltAz(const Vec3d& v)
>
> {
>
> return matJ2000ToAltAz*v;
>
> }
>
>
>
>
>
> void setTime(QDateTime d)
>
> {
>
> setJD(StelUtils::qDateTimeToJd(d));
>
> }
>
>
>
> Void main()
>
> {
>
> QDateTime date = QDateTime(QDate(2016, 4, 15), QTime(10,0,0,0),
> QTimeZone::utc());
>
> setTime(date);
>
> update()
> Vec3d in;
>
>
>
> double ra = 16.123456;
>
> double dec = 36.46667;
>
> spheToRect(ra*M_PI/180.0, dec*M_PI/180.0, in);
>
> double alt1, az1;
>
> rectToSphe(&az1, &alt1, out2);
>
>
>
> qDebug() << "j2000ToAltAz.alt:" << alt1*180/M_PI;
>
> qDebug() << "j2000ToAltAz.az:" << az1*180/M_PI;
>
> }
>
>
>
>
>
> ---
> Este email foi escaneado pelo Avast antiv?rus.
> https://www.avast.com/antivirus
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>
> ------------------------------
>
> _______________________________________________
> Stellarium-pubdevel mailing list
> Stellarium-pubdevel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>
> End of Stellarium-pubdevel Digest, Vol 107, Issue 2
> ***************************************************
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Stellarium-pubdevel mailing list
Stellarium-pubdevel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
