[Qt-mobility-feedback] Fwd: Small Feature Request for QGeoCoordinate

[Jeffery MacEachern]

Hi David,

On Tue, Jul 20, 2010 at 15:46,  <david.laing at nokia.com> 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
>