[Marble-devel] Re: Platform 11 Discussions

[Torsten Rahn]

Hi John,

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 
QGeoCoordinate.

> 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.

Yes.

> 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 
creation. 
-. 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. 

Best Regards,
Torsten
 
> Cheers!
> 
> John.
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel