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]; [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
