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

Tue Jul 13 23:36:28 CEST 2010

Hi David,

Sorry I took so long to get back to you on this.  I talked it over with
Craig, and looked at the code in GIT, and I wanted to clarify things a bit.
It looks like the "meat" of QGeoCoordinate's code is in the distanceTo() and
azimuthTo() functions.  The formulas used in those functions seem to be a
decent compromise between mathematical complexity and accuracy - for the
use-case of your average cell phone application.  However, in the spirit of
"Qt Everywhere", I'm not sure it makes sense to assume that the Location API
is not going to be used for all manner of applications on all manner of
devices, whether or not mobile devices/cell phones are the primary target.
I understand your desire to keep things on track in terms of the direction
you intend, but this seems like an oversight, if it could be solved without
bloat or unintended consequences.  We think the problem could be adequately
solved by making distanceTo(), azimuthTo(), and the the other couple of
functions I proposed virtual, allowing developers to optionally reimplement
the actual calculations as appropriate for their applications.  If that were
possible, Qt would not have to extend the API or deal with added complexity,
but developers who need more flexibility can achieve that in a sane manner
within the existing Qt framework.

Thoughts?
    - Jeffery MacEachern

On Wed, Jun 23, 2010 at 5:49 PM, <david.laing at nokia.com> wrote:

>  Hi Jason,
>
>
>
> [Just so that everyone else has some context, there were some off mail
> lists pointing out that it was an idea rather than code that had been
> rejected, and that seemed to be more acceptable]
>
>
>
> Regarding Jeff’s proposal:
>
>
>
> The Location API is about writing code to let a user know where they are in
> the world based on various position technologies.  The current distance
> function is a small convenience function out to one side of that, and Jeff’s
> suggestion has highlighted some similar functionality that is missing that
> will probably have a similar level of use to the existing distance
> function.   I’m going to make a change request and (providing it passes our
> checks and balances) implement it and make it part of the Location API.
>
>
>
> The checks and balances that we have are necessary to maintain quality –
> “change request” and “product manager” sound a little bureaucratic /
> draconian, but they’re synonymous with “suggestion logged in the bug
> tracker” and “person with the higher level concept of the library”
> respectively.
>
>
>
> Regarding Craig’s proposal:
>
>
>
> We still don’t quite have the open governance model ironed out just yet,
> but whatever it is I can imagine that we’ll want to be sure that we can
> maintain the quality of Qt, both at the API and code levels.
>
>
>
> Part of writing good APIs is saying no.  Even if the replaceable surface
> abstraction idea came with code, it would have received the same response
> since it doesn’t appear to fit with what we’re trying to do with the
> Location API.  Of course, when the “what we’re trying to do” part of
> designing future libraries comes under open governance then people will be
> able to help steer that part.
>
>
>
> I’d sincerely like to understand where you’re coming from.  What we have
> here is that one idea was rejected, or at least deferred, on quality
> grounds.  I’m having trouble seeing the connection to “nothing is likely to
> be accepted”.  In particular I’d like to know what you expected from us –
> because it’s good data for us in general, and it’ll also mean that we can
> either a) take some advice on board or b) clarify how we’re currently
> operating a little better.
>
>
>
> Cheers,
>
>
>
> Dave
>
>
>
> *From:* ext Jason H [mailto:scorp1us at yahoo.com]
> *Sent:* Thursday, 24 June 2010 12:44 AM
>
> *To:* Laing David (Nokia-D/Brisbane)
> *Cc:* qt-mobility-feedback at trolltech.com
>
> *Subject:* Re: [Qt-mobility-feedback] Fwd: Small Feature Request for
> QGeoCoordinate
>
>
>
> That doesn't sound like the open development model we've been promised...
>
> I understand the need for prevent bloat and keeping it tidy, but it is hard
> for me to get behind contributing to Qt if nothing is likely to get
> accepted, or if there is some draconian process. I am sure I am not the only
> one who feels this way. Nokia is eager to accept contributions:
> http://qt.nokia.com/developer/qt-roadmap/
> http://labs.trolltech.com/blogs/2010/06/03/qt-and-open-governance/
>
> But statements like this paint a completely different picture.
>
>   ------------------------------
>
> *From:* "david.laing at nokia.com" <david.laing at nokia.com>
> *To:* wcs at ensc.sfu.ca
> *Cc:* saa34 at sfu.ca; qt-mobility-feedback at trolltech.com
> *Sent:* Tue, June 22, 2010 9:38:04 PM
> *Subject:* Re: [Qt-mobility-feedback] Fwd: Small Feature Request for
> QGeoCoordinate
>
> Hi Craig,
>
>
>
> I’ll paste my original response, from when this message first appeared
> off-list.
>
>
>
> Any changes that we make will have to go through all of our internal checks and balances - and something like your suggestion would probably also involve a product manager, since it may be too far away from the core of what we're trying to do with the Location API.
>
>
>
> I'll bring it up and will try to work out whether there's a demand for such a feature - if we find that there's demand for that kind of thing then we'll broaden the scope to match the demand.
>
>
>
> As an additional comment, I’m pretty sure we don’t need to add API support
> for finding a coordinate that is an x metre change in altitude from another
> coordinate, since it can already be done with:
>
>   QGeoCoordinate coord1;
>
>   QGeoCoordinate coord2(coord1);
>
>   coord2.setAltitude(coord2.altitude + x);
>
>
>
> I’ll add it to the proposed find-a-coordinate-at-an-offset function with a
> default value of 0, which will go into the change request that I’m putting
> together.
>
>
>
> My feeling is that most distance use cases will involve
>
> a)      altitude-independent distance  (coord1.distanceTo(coord2))
>
> b)   the difference in altitude between two points (coord1.altitude() –
> coord2.altitude())
>
>
>
> I’m not sure that we’ll find sufficient demand for considering altitude
> when calculating the distance between points – like I said in my initial
> reply, it feels like it’s outside of the core of what the Location API is
> about (grabbing the position of a user via GPS/cell ID/etc...).  I also
> couldn’t find anything as advanced in the Android, Apple, S60, or JSR 293
> Location APIs – that’s not to say that we’re unwilling to go above and
> beyond what they’re providing, but it does provide a sanity check for
> features we are considering.
>
>
>
> I’ll add the method we use for distance calculations to the documentation
> for the method.  If we can improve the accuracy without too much effect on
> performance we might look at upgrading the surface abstraction to WGS84 (if
> we’re not using it already) – however I think selectable surface
> abstractions are well away from what we’re trying to provide with the API.
>
>
>
> Cheers,
>
>
>
> Dave
>
>
>
> *From:* ext Craig Scratchley [mailto:wcs at ensc.sfu.ca]
> *Sent:* Wednesday, 23 June 2010 4:21 AM
> *To:* Laing David (Nokia-D/Brisbane)
> *Cc:* j.maceachern at gmail.com; saa34 at sfu.ca;
> qt-mobility-feedback at trolltech.com
> *Subject:* Re: Fwd: [Qt-mobility-feedback] Small Feature Request for
> QGeoCoordinate
>
>
>
> Hi Dave.  Thanks for your quick reply.  I had made two separate
> suggestions, so I'll comment on each separately.
>
> 1)  Generating a new QGeoCoordinate by adding an offset that includes a
> change in altitude.  As I had indicated, we are interested in location
> tracking that includes indoor location, possibly in multi-storey buildings.
> In fact, we are developing location technology that includes the use of
> inertial sensors to help determine location.
>
> Indoor location and maps is something that is growing.  Consider, for
> instance, Micello Indoor Maps:
>
> http://itunes.apple.com/us/app/micello-indoor-maps/id349747050?mt=8
>
> Note the floor change in the screenshot below.
>
>
>
> And of course also consider Nokia's Kamppi project:
>
> http://betalabs.nokia.com/apps/nokia-kamppi-trial
>
> 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)
>
>
>
> Note in the attached RFP that an indoor resolution of 1cm is specified for
> a device that can measure the distance a user moves.
>
> Perhaps adjusting altitude with an offset should be done in a separate
> function call.
>
> 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).
>
> 2)  Selectable surface abstraction.
>
> As I mentioned, our project at SFU will deal with relatively small
> distances.  The amount of computation that is required to calculate things
> like the distance between two coordinates changes significantly depending on
> the surface abstraction.  For small distances, many of the abstractions will
> give very acceptable accuracy.  For large distances and depending on the
> accuracy needed, a particular choice of abstraction might be best.  I don't
> know much about surveying, but perhaps applications like it need very high
> accuracy.  The benefit of allowing the selection of the surface abstraction
> is that one can make that complexity/accuracy tradeoff for their
> calculations at their known scale.  Of course there should be some default
> abstraction.  Hopefully that default is clearly documented.  I haven't
> thought through this issue very carefully, but thought I'd share this
> paragraph anyway.  I note that GPS seems to use a spheroidal reference
> surface (in WGS84):
>
>
> http://en.wikipedia.org/wiki/World_Geodetic_System#A_new_World_Geodetic_System:_WGS84
>
>      Craig
>
> david.laing at nokia.com wrote:
>
> Hi,
>
>
>
> Any changes that we make will have to go through all of our internal checks and balances - and something like your suggestion would probably also involve a product manager, since it may be too far away from the core of what we're trying to do with the Location API.
>
>
>
> I'll bring it up and will try to work out whether there's a demand for such a feature - if we find that there's demand for that kind of thing then we'll broaden the scope to match the demand.
>
>
>
> Cheers,
>
>
>
> Dave
>
>
>
> -----Original Message-----
>
> From: ext Craig Scratchley [mailto:wcs at ensc.sfu.ca <wcs at ensc.sfu.ca>]
>
> Sent: Tuesday, 22 June 2010 1:15 PM
>
> To: Laing David (Nokia-D/Brisbane)
>
> Cc: Jeffery MacEachern; Shervin A.
>
> Subject:
>
>  Re: Fwd: [Qt-mobility-feedback] Small Feature Request for QGeoCoordinate
>
>
>
> Hi Dave.
>
>
>
> Hmmm.  This is interesting.  I've got a couple comments.  First of all,
>
> there is an interesting page on such conversions at:
>
>
>
> http://en.wikipedia.org/wiki/Geographical_distance
>
>
>
> For our purposes at SFU, we are going to want to track altitude in
>
> addition to latitude and longitude.  We will want, for example, to track
>
> which floor of a building the user is on.  Therefore, I might imagine
>
> something like:
>
>
>
>  QGeoCoordinate QGeoCoordinate::appropriateDistanceFunctionName(int
>
> metresNorth, int metresEast, int metresVertical)
>
>
>
>
>
> Or
>
>  something like that.  This would adjust altitude in addition to lat.
>
> and long.
>
>
>
> In our case, the distances will be very small, so there seem to be all
>
> sorts of approximations that can be used.  On the other hand, for very
>
> large distances, one might want to use an Ellipsoidal-surface formulae
>
> (such as the one at http://geographiclib.sourceforge.net/ ) instead of
>
> one based on an assumption that the Earth is spherical.  Perhaps it
>
> would be best to allow the user to choose which abstraction he wants to
>
> use for the surface.
>
>
>
> Thanks,
>
>      Craig
>
>
>
> ---------- Forwarded message ----------
>
>
>
> From:  <david.laing at nokia.com> <david.laing at nokia.com>
>
> Date: Tue, Jun 15, 2010 at 5:55 PM
>
> Subject: RE: [Qt-mobility-feedback] Small Feature Request for QGeoCoordinate
>
> To: j.maceachern at gmail.com, qt-mobility-feedback at trolltech.com
>
>
>
>
>
> Hi Jeffery,
>
>
>
> It's a good suggestion.
>
>
>
> 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.
>
>
>
> I'll schedule this for internal discussion (to work out the proper
>
> form of the API and any potential headaches it may cause etc...) and
>
> if all goes well it'll make it into the Location API by the next
>
> release of Qt Mobility.
>
>
>
> Thanks,
>
>
>
> Dave
>
>
>
> -----Original Message-----
>
> From: qt-mobility-feedback-bounces at trolltech.com
>
> [mailto:qt-mobility-feedback-bounces at trolltech.com <qt-mobility-feedback-bounces at trolltech.com>] On Behalf Of ext
>
> Jeffery MacEachern
>
> Sent: Tuesday, 15 June 2010 1:43 PM
>
> To: qt-mobility-feedback at trolltech.com
>
> Subject: [Qt-mobility-feedback] Small Feature Request for QGeoCoordinate
>
>
>
> Hello,
>
>
>
> I'm not sure if this is the best place for a feature request, but the
>
> bug tracker was down.  I would like to request the addition of a
>
> method to the QGeoCoordinate class which would allow a distance (e.g.
>
> (x,y) in some standard unit of length) to be added to a
>
> QGeoCoordinate.  This would be a useful companion to the
>
> QGeoCoordinate::distanceTo() function.  In my
>
>  case, this need came up
>
> while working with a sensor that provides relative distances in metres
>
> as offsets from a known geographical reference point; one could easily
>
> imagine other situations where such a calculation would be useful as
>
> well.
>
>
>
> Thoughts on this would be appreciated.
>
>
>
> ~ Jeffery MacEachern
>
> _______________________________________________
>
> Qt-mobility-feedback mailing list
>
> Qt-mobility-feedback at trolltech.com
>
> http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Qt-mobility-feedback mailing list
> Qt-mobility-feedback at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-mobility-feedback/attachments/20100713/2cbf64db/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 21830 bytes
Desc: not available
Url : http://lists.qt.nokia.com/pipermail/qt-mobility-feedback/attachments/20100713/2cbf64db/attachment.jpe 