Hi David, 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).
Okay, I see what you mean. The confusion was over the use of int vs some floating-point type in your original comment: > I think if we provide something like > QGeoCoordinate QGeoCoordinate::appropriateDistanceFunctionName(int > metresNorth, int metresEast) > then we'd want to provide something like > QGeoCoordinate QGeoCoordinate:: appropriateDistanceFunctionName (int > metres, qreal heading) > as well. Using a qreal instead of a double certainly makes sense to me; Craig and were just concerned about the lack of sub-metre precision implied by those signatures. If that has been revised, then there is no issue. >> > 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. That sounds good. >> > 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
