[Marble-devel] Reference system

Wed May 23 18:38:47 UTC 2012

Hi all,

I have implemented a small demo that uses the new reference system. The
small demo contains the next files:
main.cpp: http://pastebin.com/Z74VBMCu
marblemanager.h: http://pastebin.com/kXAHLuTz
marblemanager.cpp: http://pastebin.com/iCwPPnjV
satitem.h: http://pastebin.com/id30XEeY
satitem.cpp: http://pastebin.com/NBpV5dus

I have made new changes in the next files, (now I use diffs to make more
clear the review):
GeoDataCoordinates_p_h.diff: http://pastebin.com/ak56mVLq
GeoDataCoordinates_h.diff: http://pastebin.com/mj88Jr4R
GeoDataCoordinates_cpp.diff: http://pastebin.com/9GfDv1YM
SphericalProjection_cpp.diff: http://pastebin.com/3GzR72gb
ViewportParams_cpp.diff: http://pastebin.com/zvizfq2T

I have used a new approach. I haven't used the Marble clock in the
conversion in ViewportParams because all the times are the same for each
update. The update interval of Marble corresponds with the step time of my
orbit propagation. v = e / t --> e = v * t --> lon = lon -
(earthAngularSpeed * m_time). earthAngularSpeed and m_time are constants in
my case.

When I run my small demo a point is drawn. The point remains fixed in the
space although I click and drag over the earth globe.

Can you help me to correct this behaviour?

Best regards.

2012/5/16 Torsten Rahn <tackat at t-online.de>

> Hi,
>
> Please rather create diffs or even better add an entry to reviewboard :-)
>
> Otherwise other people won't be able to spot the differences.
>
> On Dienstag, 15. Mai 2012 20:55:24 marble_developer marble_developer wrote:
> > 1.- I have added an attribute in GeoDataCoordinatesPrivate class to set
> the
> > new type and I have added another attribute to set the marble clock. Code
> > for GeoDataCoordinates_p.h: http://pastebin.com/mCF0eLn7 The type
> indicates
> > the reference system to use for the GeoDataCoordinates object.
>
> This needs to be a flag at some point.
>
> > 2.- Then I have modified the GeoDataCoordinates class to declare and
> > implement the get and set methods for the the new type and for the marble
> > clock. Code for GeoDataCoordinates.h: http://pastebin.com/pFF8hjGe and
> code
> > for GeoDataCoordinates.cpp: http://pastebin.com/BUGqVETW
>
> I don't think that the clock should be a property of the GeoDataCoordinate
> class. That's neither acceptable semantically nor in terms of ressource
> consumption :-)
>
> > 3.- Later I have gone to the SphericalProjection class because the
> methods
> > in there are executed whenever geodetic coordinates converted to screen
> > coordinates. I have modified the method that has this prototipe: 'bool
> > SphericalProjection::screenCoordinates( const GeoDataCoordinates
> > &coordinates, const ViewportParams *viewport, qreal &x, qreal &y, bool
> > &globeHidesPoint ) const'. This is the new code for
> > SphericalProjection.cpp: http://pastebin.com/yhGEfDf9
> > 4.- I have modified ViewportParamsPrivate::setPlanetAxis() method to use
> > another reference system to a specific kind of GeoDataCoordinates. Code:
> > http://pastebin.com/NDFaXJGz
>
> The changes look about correct (at least for a first prototype). Did you
> test
> whether it works as expected?
> Did you check whether the resulting longitudes increase with time as
> expected?
>
> Of course the problem is still with the MarbleClock: I guess we wouldn't
> want
> to introduce the MarbleClock as a property for the viewport params. So how
> would the the time get accessed which currently is only accessible from the
> model?
>
> Also there is the catch with BoundingBoxes ("GeoDataLatLonAltBox"): They'd
> either be reference system aware or always fed with the fixed reference
> system
> even if the coordinates involved are inertial ones. The latter approach
> would
> require a conversion which again would require the clock to be accessible
> from
> the classes involved.
>
> So maybe we should make MarbleClock a singleton?
>
> Additionally we'd need to investigate possible side effects of the newly
> introduced reference system onto other code involved (beyond the bounding
> boxes).
>
> So the new code so far introduces some conceptual issues (Marble Clock
> availability, Sideeffects and possibly required handling in other classes
> such
> as the LatLonAltBox, API complexity burden).
>
> So we need to weigh up those disadvantages against the advantages (possible
> performance improvements - but those need to get verified). And only then
> we
> could think of adding this feature to our code base. It might very well be
> that it turns out not to be worth the trouble so that you might need to
> continue with your previous approach.
>
> I just had a chat with Guillaume ("smarter") and he would think that the
> performance impact is likely not to be noticable in most use cases. But
> maybe
> we could have this verified.
>
> BR,
> Torsten
>
>
>
>
>
>
>
>
>
>
> > Problems:
> > 1.- I'm not sure that the new implementation added in ViewportParams is
> > correct because the SphericalProjection::screenCoordinates() method
> doesn't
> > call ViewportParamsPrivate::setPlanetAxis() directly.
> >
> > Best regards.
> >
> > 2012/5/13 Torsten Rahn <tackat at t-online.de>
> >
> > > Hi,
> > >
> > > Now I get it :-)
> > >
> > > Yes, I can see why this kind of problem occurs with Orbit data.
> > >
> > > Right now we basically calculate the screen positions of objects for a
> > > certain
> > > position inside the projection classes. See
> > >
> > > src/lib/Projections/SphericalProjection.cpp
> > >
> > > with methods like
> > >
> > > bool SphericalProjection::screenCoordinates( const GeoDataCoordinates
> > > &coordinates,  const ViewportParams *viewport,
> > >
> > >  qreal &x, qreal &y, bool &globeHidesPoint ) const
> > >
> > > for example. The expensive part there is the line
>  qpos.rotateAroundAxis(
> > > *(
> > > viewport->planetAxisMatrix() ) ); which does the basic coordinate
> > > transformation between geodetic GeoDataCoordinates and pixel
> coordinates.
> > >
> > > I guess that would be the proper place in the code where one could
> > > introduce
> > > other such possible reference systems. If you really want to "save" CPU
> > > cycles
> > > there then you'd probably introduce an alternative planetAxisMatrix
> that
> > > is used for the rotateAroundAxis method (have a look at the other
> places
> > > in the
> > > code where the planetAxis is calculated to do this in a similar way).
> > > This would avoid having to "convert" the positions for all the
> > > GeoDataCoordinates of the Satellites. Instead you'd just create a
> fitting
> > > matrix once that would work for all :-)
> > >
> > > We'd gladly accept patches that do this in a nice way ;) This means it
> > > should
> > > work for all projections with a nice API. Ideally you'd also provide
> some
> > > basic unit regression tests :)
> > >
> > > BR,
> > >
> > > Torsten
> > >
> > > On Sonntag, 13. Mai 2012 13:20:14 marble_developer marble_developer
> wrote:
> > > > Hi,
> > > >
> > > > I will try to explain it a bit better.
> > > >
> > > > When the Earth turns the corresponding angle in each update of Marble
> > > > clock, the points added turn the same angle too, it's the normal
> > >
> > > behaviour
> > >
> > > > in Marble because the reference system rotates with the Earth globe.
> > > >
> > > > In this case, a point that has the next values for lon, lat and alt
> > >
> > > doesn't
> > >
> > > > generate an orbit. lon, lat, alt = (0, 0, 20000 * 1000). The point is
> > >
> > > drawn
> > >
> > > > always in the same point of space.
> > > >
> > > > I want that the points remain fixed in the space and they doesn't
> turn
> > >
> > > with
> > >
> > > > the Earth.
> > > >
> > > > In this case a point that has the next values for lon, lat and alt
> > > > generates an orbit. lon, lat, alt = (0, 0, 20000 * 1000). The point
> is
> > > > drawn in differents points of space because the point drawn remain
> > > > fixed
> > >
> > > in
> > >
> > > > space.
> > > >
> > > > For example, we consider that the update interval of Marble clock is
> > >
> > > 10800
> > >
> > > > s, (10800 s is the time that the Earth use to turn 45º) and that a
> > > > point with values lon, lat, alt = 0,0, 20000 * 1000 is added in each
> > > > update of Marble clock. At first, when the time is 0 s, the point p
> is
> > > > drawn in
> > >
> > > 0,0,
> > >
> > > > 20000 * 1000, then, when the time is 10800 s, the point p is drawn in
> > >
> > > 0,0,
> > >
> > > > 20000 * 1000 but the last point p' is in -45, 0, 20000 * 1000 respect
> > > > the new point p.
> > > >
> > > > I have performed this behaviour by recalculating the new lon position
> > > > in every update but it's very slowly when the number of points is
> > > > elevated.
> > > >
> > > > How can I do this task in a better way? Is it possible to change the
> > > > reference system using in Marble?
> > > >
> > > > Regards.
> > > >
> > > > 2012/5/7 marble_developer marble_developer <
> marbledeveloper at gmail.com>
> > > >
> > > > > Hi all,
> > > > >
> > > > > Is it possible to change the reference system using in Marble?
> > > > > In affirmative case, how can I change it?
> > > > > I need to use an inertial reference system instead of fixed
> reference
> > > > > system.
> > > > >
> > > > > Best regards.
> > >
> > > _______________________________________________
> > > Marble-devel mailing list
> > > Marble-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/marble-devel
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20120523/31fd0e0c/attachment.html>