Hi Jeffery, > However, in the spirit of "Qt Everywhere"
The "spirit of Qt Everywhere" is something that we do try to consider - although in the case of existing APIs it would normally be used to select between several options that fit within the scope and requirements of the API. > 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. Developers may use the Location API in all manner of applications on all manner of devices, but if they're using it for something far enough outside of the scope of library then we can't (and probably shouldn't) modify the API to enable that. This particular suggestion is still within the domain of coordinates and positions, but still feels out of scope for me. I will present the idea to the relevant people in order to check if this is or is not the case. > 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. Code bloat and unintended consequences are something we try to avoid, and any addition to an existing API would do well to avoid them, but we also do our best to avoid scope creep - which is equivalent to API bloat, and is why I'm pretty hesitant about the suggestion. > 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. Making the methods virtual has several drawbacks, mainly arising from conflicts with the intention of the QGeoCoordinate class. The QGeoCoordinate class is meant to be a small value class, and there might be quite a few of them in play, so we'd like to avoid adding virtual methods (and the associated size and look ups) if at all possible. It seems like a small thing to worry about, but we try to consider things like that carefully. The second problem is that all of the current uses of QGeoCoordinate in the API don't take pointers to QGeoCoordinate, so without some fancy footwork (which gets a little involved and would add size and reduce speed) the subclasses wouldn't be useful in conjunction with the classes and methods of the existing API. If this is to be worked around by strictly using just base class for the existing API and the subclasses for the extra distance calculations etc... then it hints that the QGeoCoordinate we have belongs in the Location API and the QGeoCoordinate you want belongs in a hypothetical 3d geometry API. The third and terminal problem is that we can't add virtual functions to QGeoCoordinate without breaking binary compatibility. If you'd like more details on what we can or cannot do on the binary compatibility front, this page: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ is pretty useful. One way of adding the functionality without effecting QGeoCoordinate or the way that it's used would be to have the extended distance / azimuth functions as non-member functions. This can already be done pretty easily outside of the Location API, as the QGeoCoordinate class exposes all of the relevant information for the coordinate anyhow. This means that what we have already fulfills the "make the simple cases easy and the complex cases possible" criteria, at least based on my gut feeling that 80% or more of the Location API users aren't using the distance functions that we have and that 80% or more of the remaining users don't mind what we have (beyond a certain accuracy). I can see a way forward with this idea - a new class responsible for coordinate geometry calculations (with virtual methods designed in from the start) - but it's probably still outside the scope of the Location API. It would have the benefit that it wouldn't complicate the documentation/understanding of the existing API for the users that didn't need different surface abstractions, the small drawback that they'd need to learn and remember that they didn't need the new class and the large drawback that it'd split the distance functions across two classes. Either way, I'll have some internal discussions to triple check my understanding of the scope of the API with respect to this idea and get back to you. Cheers, Dave From: ext Jeffery MacEachern [mailto:[email protected]] Sent: Wednesday, 14 July 2010 7:36 AM To: Laing David (Nokia-MS/Brisbane) Cc: [email protected]; [email protected]; Craig Scratchley Subject: Re: [Qt-mobility-feedback] Fwd: Small Feature Request for QGeoCoordinate 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, <[email protected]> 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:[email protected]] Sent: Thursday, 24 June 2010 12:44 AM To: Laing David (Nokia-D/Brisbane) Cc: [email protected] 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: "[email protected]" <[email protected]> To: [email protected] Cc: [email protected]; [email protected] 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:[email protected]] Sent: Wednesday, 23 June 2010 4:21 AM To: Laing David (Nokia-D/Brisbane) Cc: [email protected]; [email protected]; [email protected] 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 [email protected] 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:[email protected]] 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: <[email protected]> Date: Tue, Jun 15, 2010 at 5:55 PM Subject: RE: [Qt-mobility-feedback] Small Feature Request for QGeoCoordinate To: [email protected], [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of ext Jeffery MacEachern Sent: Tuesday, 15 June 2010 1:43 PM To: [email protected] 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 [email protected] http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback
