Hi Jeffery,

It's an internal branch at the moment - it'll make its way into master not long 
after it's done.

Cheers,

Dave

> -----Original Message-----
> From: ext Jeffery MacEachern [mailto:[email protected]]
> Sent: Friday, 27 August 2010 9:25 AM
> To: Laing David (Nokia-MS/Brisbane)
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: Fwd: [Qt-mobility-feedback] Small Feature Request for
> QGeoCoordinate
> 
> Great, thanks.  Is the branch you mentioned in a public repository
> where I could look at it?  I haven't been able to find it.
> 
>  - Jeffery MacEachern
> 
> 
> 
> On Thu, Aug 26, 2010 at 15:19,  <[email protected]> wrote:
> > Hi Jeffery,
> >
> > We've got a change request filed and I've got some code and unit
> tests in a separate branch.  Most of my time has been directed at the
> Maps and Navigation API at the moment, so it's hard to say whether the
> functions will make it into the 1.1 release of Mobility.  If they don't
> make it into the 1.1 release they'll be in the master branch not too
> long after the release.
> >
> > Cheers,
> >
> > Dave
> >
> >> -----Original Message-----
> >> From: ext Jeffery MacEachern [mailto:[email protected]]
> >> Sent: Friday, 27 August 2010 5:29 AM
> >> To: Laing David (Nokia-MS/Brisbane)
> >> Cc: [email protected]; [email protected]; qt-mobility-
> [email protected]
> >> Subject: Re: Fwd: [Qt-mobility-feedback] Small Feature Request for
> >> QGeoCoordinate
> >>
> >> Hi David,
> >>
> >> Any news on the distance functions?
> >>
> >>  - Jeffery MacEachern
> >>
> >>
> >>
> >> On Tue, Jul 20, 2010 at 15:46,  <[email protected]> wrote:
> >> > Hi Jeffery,
> >> >
> >> > I responded at the time, but I'll reiterate:
> >> >
> >> >> > Looking again at the APIs you had sketched out and I had
> sketched
> >> in
> >> >> reply, I think the data types need to be modified for what I am
> now
> >> >> referring to as metresHorizontal and also for my metresVertical.
> >> Given
> >> >> that altitude is a double, and distance is a qreal, it seems
> >> something
> >> >> like this would be a better:
> >> >> >
> >> >> >  QGeoCoordinate QGeoCoordinate::
> appropriateDistanceFunctionName
> >> >> (qreal
> >> >> > metresHorizontal, qreal heading, double metresVertical)
> >> >
> >> > All of our other distances are qreal (which is double on desktop
> >> platforms) and in meters, so we'd probably stick with that rather
> than
> >> mixing qreal and double.  We generally leave the units in the
> >> documentation rather than having them in the parameter names (or at
> >> least we have been so far in the Location API).
> >> >
> >> >> > Perhaps adjusting altitude with an offset should be done in a
> >> >> separate function call.
> >> >
> >> > There's no place for such a function call, since we can already do
> it
> >> with
> >> > QGeoCoordinate coordinate1 = coordinate2;
> >> > coordinate1.setAltitude(coordinate1.altitude() + offset);
> >> >
> >> > I can add a vertical offset parameter to the other related
> functions
> >> and have the parameter default to 0.0 - it doesn't complicate the
> API
> >> and there's a decent chance that it'll be useful to the people using
> >> those functions, so it's worth adding.
> >> >
> >> >> > Also, while metresNorth and metresEast would work okay for
> small
> >> >> distances, they probably don't make that much sense for large
> >> distances
> >> >> (I think you would get different resulting co-ordinates if you
> >> applied
> >> >> them in the two different orders).
> >> >
> >> > I was thinking we'd apply them simultaneously.  Ideally we'd use a
> >> method where the order doesn't matter - in fact we should probably
> have
> >> a unit test to check that
> >> >  c.move(metresNorth, 0).move(0, metresEast) == c.move(0,
> >> metresEast).move(metresNorth, 0) == c.move(metresNorth, metresEast)
> >> >
> >> > This is trivially true if the earth is modeled as an ideal sphere,
> >> since there's a direct mapping between degrees travelled north/south
> or
> >> east/west and metres.  It may take a little more work when using a
> >> better approximation - If I have time I'll analyze the errors of the
> >> various methods and see if we can get something that behaves like
> this.
> >> >
> >> > Cheers,
> >> >
> >> > Dave
> >> >
> >

_______________________________________________
Qt-mobility-feedback mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback

Reply via email to