Hi, I agree that this will be likely one of the important topics at the Marble Sprint indeed.
Am Mittwoch, 3. November 2010 21:42:22 schrieb John Layt: > part of the Meego platform. The problem comes in the api to access > Geoclue, which is a DBus based service with C bindings, as we would > obviously prefer a Qt-ish C++ wrapper for convenience. And for Marble we have a GeoClue plugin (I don't know whether it currently works since the DBUS API had been subject to changes at one point). > Added to this is another issue I want to discuss with Marble: geo-related > astronomical calculations. With at least 4 different places in the SC with > code for sunrise/sunset/moon phases (KHolidays, Plasma dataengine, KStars, > Marble), and my needing them for the astronomical based calendars, it also > seems a good candidate for a shared library somewhere. That's something I'd like to see as well. > Some of what I know about QtMobility: > * Location api I think that it probably makes sense to use the Location API for determining the position on platforms where Qt Mobility is widely deployed and where the implementation of the Location API is fully available. This would at least be the case for MeeGo and possibly for Windows (haven't tried). > * Landmarks api I think we have a big clash of design goals with regard to the Landmark API: - One of the big ideas behind Marble is that internally it's modelled after the open OGC standard KML ( http://www.opengeospatial.org/standards/kml/ ): KML is popular, widely known and used in the world of GIS. This has several advantages: * It's quite easy to learn Marble's API for anyone who knows KML * We basically have an implementation guide for all the classes and properties since everything is described as part of an open specification. * KML is a pretty pragmatic and at the same time powerful approach to modelling data. It goes way beyond just Placemarks (=Landmarks). * Due to the internal KML modelled design import of the open standard KML is quite easy to do. Also since KML is quite generic it's possible to map the parsing result of other formats (gpx, etc.) to KML. - The idea behind the Qt Mobility API is to model a significant part of the API after Ovimaps' LMX format, see the "Landmarks Exchange Format Specification": http://www.forum.nokia.com/dp?uri=http%3A%2F%2Fsw.nokia.com%2Fid%2F9001c8de- c19e-41a0-87d3-5be4297e4d4c%2FS60_Platform_Landmarks_Exchange_Specification_v1_0_en.pdf >From what I can tell it's barely known and barely supported outside the Ovimaps Symbian world. While the Landmarks Exchange Specification is more detailed with regard to some topics (and with regard to actual implementation) it lacks other parts (at least from what I can see) that are covered by KML. There are certainly some interesting aspects about the Landmark API (filters and categories) and parts where the Landmark API is more mature. The problem I see with using the Qt Mobility Landmark API is that we'd trade an internal design (and a public API) that is modelled after an open widely used specification and standard for a design that embraces Ovimaps internal design. In theory the advantage would be that this would allow for better usage of Ovimaps data (at expense of possible 1:1 KML import which I'd regard more important). But there's a catch even with regard to the "better" Ovimaps import: > * Maps and Navigation api and widgets, including an Ovi backend >From looking at the current state of the Terms and Conditions of the Ovi Maps API I'm not sure whether we can legally make use of it: http://qt.gitorious.org/qt-mobility/qt- mobility/blobs/master/plugins/geoservices/nokia/OVI_SERVICES_TERMS_AND_CONDITIONS.txt has some terms such as: "4. USE OF OVI MAPS API DEVELOPER PACKAGE [...] You will not: (i) use or incorporate the Ovi Maps Service, Ovi Maps API Developer Package or any part thereof, in connection with any Application or other service (a) which has the primary functionality of providing turn-by-turn navigation services, real time navigation or route guidance; or (b) where such Application's functionality is substantially similar to the Ovi Maps or navigation/location-based products distributed by Nokia or its affiliates;" Not sure whether this is supposed to stay like this in the shipped version of Qt Mobility and whether it affects Marble (which provides turn-by-turn navigation services, real-time navigation and route guidance e.g.). Also in Marble we have the policy to only provide geoservices that are free in the sense of free software in the shipped version. Shipping Ovimaps with the current Terms and Conditions would surely break that policy (which is one of our selling points). Technically Marble already has full support in our stable versions for what you need to fetch Ovimaps pixmaps tiles (adding support is mostly about changing a server Url in an XML file AFAIK). > Against the Qt option, we obviously already have our own superb geo tools > in Marble that we could work with to produce our own api, but somewhat > smaller in scope than QtMobility or Marble itself: > * basic geo classes like coordinates, location, address etc > * Location api > * Celestial Mechanics api * Stuff like the GeoPainter which works well with projections * Initial Qt Quick binding support ... and lots more. Personally I think that it would be nice to have at least "conversion wrappers" available for Qt Mobility in some Marble classes (like e.g. for Qt Mobility's QGeoCoordinates vs. Marble's GeoDataCoordinates). Best Regards, Torsten >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
