[Marble-devel] Re: Platform 11 Discussions
tackat at t-online.de
Sat Jun 4 09:34:46 CEST 2011
On Friday, 3. June 2011 19:00:38 John Layt wrote:
> I'm at the Platform 11 sprint discussing how kdleibs is going to look after
Thanks for being there and wearing the Marble helmet :-) Unfortunately I
wasn't able to join the Platform 11 meeting since I had been pretty busy with
other stuff (but I'll hopefully be at the Qt Contributors Summit).
> Qt5. One thing we are discussing is geolocation and one idea that has been
> floated to having QGeoCoordinates and QGeoAddress moved from QtLocation
> into QtCore as fundamental data types, i.e. part of the Qt type system
> including QVariant and everything.
Yes, we had a similar discussion at the Marble meeting as you might remember.
And while we had quite some reservations regarding the other QGeo-classes
QGeoCoordinate however is a notable exception! :-)
The API of QGeoCoordinate is very similar to Marble's GeoDataCoordinate class.
And the reason is of course that there isn't much about a geospatial
coordinate class that one could do very much differently.
So this is a pretty much straightforward pick.
QGeoAddress looks like a good pick to me as well: It's imho not as important
and useful as QGeoCoordinate but it's quite good at what it was designed for.
And it doesn't pull in other stuff.
> These classes would then become the
> common interchange and storage format that even the lowest level KDE
> libraries can use in their classes and api without needing QtLocation or
> libmarble to be installed at build or run time.
Sounds good to me. We can add conversion methods to GeoDataCoordinate for
convenience and for a possible partial or full transition towards
> Note we are not suggesting Marble switch classes, or that the Qt classes
> should get all the advanced Marble features, or that QtLocation is the
> blessed gelocation framework, it's just a way to store and pass around
> basic geo data without needing a full geolocation/mapping library
> installed. It also should give some flexability around the choice of
> geolocation frameworks.
> Does this sound a good idea?
Yes, I think so. And since we discussed the case of QGeoCoordinate at the
Marble Meeting already I believe that I'm also speaking for the other Marble
guys as well (If one of our Marbleheads disagrees, this is your chance to
speak up now !)
> Is there anything in the Qt classes that you
> think should be changed, or any Marble features that would be good to add?
The only things that we do differently in GeoDataCoordinate are the
to/fromString methods which have a few things that make it more flexible:
- GeoDataCoordinate::toString() has a precision parameter
- There are GeoDataCoordinate::lonToString() and
GeoDataCoordinate::latToString() which have a QString-like API for string
-. There is GeoDataCoordinate::fromString() (which doesn't catch all possible
cases but it's useful for the most important ones).
If we could add those features to QGeoCoordinate that would be (imho) a good
thing to do.
Apart from that there are some differences which are rather a matter of taste
and/or use case specific:
- our enums for the Notation/Coordinate Format are different
- and we "cache" the matrix/quaternion that is associated to the 3D-globe case
for reasons of performance.
> Are there any other basic geodata classes you think should also be added?
I don't think so. A GeoCoordinate class is really the most important thing to
have in QtCore and definetely belongs there. All other stuff doesn't simply
have the same essential relevance and doesn't belong into QtCore IMHO.
> Marble-devel mailing list
> Marble-devel at kde.org
More information about the Marble-devel