Map implementation

[Tobias Leupold]

Hi list/Johannes/Jesper :-)

Just a brainstorming about what we could do with the new map code, also having
in mind the effort to add a map showing all selected photos (as Jesper started
to implement in the GPS branch):

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.

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

For the coordinate cache, we could also simply use the existing
KGeoMap::GeoCoordinates class, as we need libkgeomap for all this anyway.

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

What do you think?

Cheers, Tobias

[Johannes Zarl]

Post by Tobias Leupold
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.

Post by Tobias Leupold
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,
...).

Post by Tobias Leupold
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.

Post by Tobias Leupold
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.

Post by Tobias Leupold
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