[KPhotoAlbum] Map implementation
johannes at zarl.at
Tue Oct 21 16:53:44 CEST 2014
On Tuesday 21 October 2014 13:38:30 Tobias Leupold wrote:
> What about creating a new directory, e. g. simply "Map" that keeps the
> classes providing the map functionality? The AnnotationMap class then could
> be e. g. "MapView", implemented in a unified way, so that both the
> annotation dialog and the (still to write/adapt) image selection map view
> could use it. We could also create a popup accessible from the viewer like
> "Show photo on map" in this way.
Having a component that can be reused in different parts of KPA is certainly a
> About the coordinates: we could create a small class caching coordinates. At
> the moment, the coordinates are read out of the file when it's displayed.
> When another image is shown and the first is shown again, they are read out
> again. With a cache, we would avoid this.
You could use the Exif database for that. Alternatively, you could fix the
GPS-Related stubs in the image database (DB::ImageInfo, XMLDB::FileReader,
> Not that I think I would be able
> to implement something like that, but if we add support for multiple images
> later, this cache could also gather the data asynchronously, when a large
> list of images is requested (either by the annotation dialog or by the map
> view), we could then add coordinates as they are read and calculated (also
> perhaps a good moment to dive into C++/Qt a bit more for me ;-).
I'm not sure if an asynchronous job for GPS data alone is such a good idea. If
you used the Exif DB for the info, you would get the GPS data basically "for
free" when the other Exif stuff is extracted.
> For the coordinate cache, we could also simply use the existing
> KGeoMap::GeoCoordinates class, as we need libkgeomap for all this anyway.
You should probably use the DB::GpsCoordinates class or rework the existing
GPS stuff to work with KGeoMap::GeoCoordinates. In the process we would
probably loose the optional dependency on Marble and instead have an optional
dependency on libkgeomap.
> I'm not completely sure if I'm right here, but adding support for thumbnails
> could be implemented in the MapMarkerModelHelper, using the existing
> (asynchronously working?) thumbnail requester, couldn't it? For the current
> one-image display of the annotation dialog, we would not need this, but,
> thinking of asynchronous coordinate fetching, we could display all selected
> images as well ...
>From what I've seen up until now, the existing thumbnail infrastructure should
be compatible with the ModelHelper - after all it's just wrapper around an
More information about the KPhotoAlbum