[KPhotoAlbum] Map implementation

[Johannes Zarl]

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


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

Cheers,
  Johannes