Bug 153070

Chistian,

This feature is planed with KDE4 port of digiKam...

Gilles Caulier

SVN commit 816774 by cgilles:

digiKam from trunk (KDE4) : I'm happy to said than a new powerfull Search tool is available in digiKam : Searches over a map !

This tool use Marble widget from trunk with a patch from me to perform a rectangle selection on the canvas. Thepatch is available at this url:

http://digikam3rdparty.free.fr/misc.tarballs/marbleselection.patch

When you make a selection, digiKam query the database to find all pictures which have been taken into this area.

There is a screenshot of this tool in action at this url:

http://digikam3rdparty.free.fr/Screenshots/NewSearchTools/mapsearchtool.png

Several improvments need to be done in marble to have a more suitable selection tool, but at least it work fine as well.

CCMAIL: marcel.wiesweg@gmx.de
CCMAIL: digikam-users@kde.org
CCMAIL: tackat@kde.org

BUGS: 153070




 M  +6 -8      gpssearchview.cpp  
 M  +6 -6      gpssearchwidget.cpp  
 M  +3 -3      gpssearchwidget.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=816774

Nice start, but the code in question doesn't work as advertized and can't get committed to SVN like this and needs some improvement before it gets applied:

1.) Most obvious problem is that the method

void MarbleWidget::setSelection(const QRect& region)

completely ignores the current projection when defining the "corners" of the
bounding box. The suggested method works fine for the example Iceland. But if you select a larger area closer to the poles in globe projection you might realize that the suggested way to create a latLonBoundingBox doesn't work.

The correct solution would make use of 

virtual GeoDataLatLonAltBox AbstractProjection::latLonAltBox( const QRect& screenRect, const ViewportParams *viewport );

Please have a look at the implementation of 

GeoDataLatLonAltBox ViewportParams::viewLatLonAltBox() const

as an example. The viewLatLonAltBox returns a GeoDataLatLonBox for the current view.

This is an important issue that needs to get fixed before this patch can be committed to SVN.

2.) I'm not sure whether it's a good solution to make a Rubberband the property of a MarbleWidgetInputHandler. Shouldn't this be a property of the view?
I also have concerns about the performance of the painting of the rubberband. Does it work well for you? IIRC due to technical/conceptual limits Marble needs to repaint the whole screen at least for some backends even if there's just a dirtyRect changed ( e.g. due to the calculation of labels not overlapping which needs to take into account the whole screen ) .

3.) I'm not sure whether the introduction of a boolean for the selectionMode is a good solution. I guess in the future we'll have many different "input modes" and I wonder whether having a boolean for each of them would be a proper solution.

I like the screenshot :-)

Torsten

Oh and please use GeoDataLatLon(Alt)Box as much as possible when improving the patch. :-)

Created attachment 25128 [details]
patch version 2

new version of patch for marble. point 1/ fixed.

Gilles Caulier

Hi,

When dealing with latitude longitude bounding boxes please make sure in the application on your end that you also properly deal with the International Date Line (IDL): You are emitting the bounding box ranges as "coordinates" (I see the need to create plain double types from the GeoDataLatLonAltBox however I wonder whether there's a better solution instead of emitting the "coordinates" in a list).

You might run into a problem in your application if you expect the "western" value to be always to the left of the "eastern" value: on the -180 - 180 longitude range the western value can actually be to the right of the eastern bounding box range. In that case you have to treat the single bounding box like TWO split bounding boxes which range from the western value to the 180 deg longitude and from the -180 deg longitude to the eastern value.

This is a problem that is inherent with the concept of latitude longitude bounding boxes and it's not Marble specific and it happens with all projections.

If you don't take this issue into account then you'll get everything outside the bounding box selected if the bounding box covers the IDL ( of course still within proper latitude ranges, but I fear that doesn't help ). 

Created attachment 25131 [details]
patch version 3

This version KML import as string code which is another issue...

Torsten, 

About point #2, here QRubberBand performance drawing are fine here (Qt 4.3.3). 

I use this widget in digiKam without problem.

Of course we can use the view instance to host this widget. We will take a look later after to fix point #1

About #3 : yes, this can be optimized. In fact MarbleWidgetInputHandler code need to be fully re-writted...

Gilles

Marcel,

About #6 from Torsten, let's me hear if IDL stuff can be a problem in database interface to perform map search. 

Gilles

Ok, sorry if it looks a bit like nitpicking but selections are really something that I'd like to see well-done right from the start.

I'd like to have the signal you're emitting changed a bit:

Currently it's called "newSelection" which uses the C++ keywords "new" and doesn't stick to the Qt naming scheme of things. What about naming the signal 

void regionSelected( QList<double> coords ) 

or emitting simply a 

void selectionChanged()

and letting the application retrieve through another method "QList<double> selection() const" what area is actually selected.

BTW: how does your method cover deselection?


> About point #2, here QRubberBand performance drawing are fine here (Qt 4.3.3).

Great :-) Just wanted to have feedback whether it works fine. So forget about it.
 
> About #3 : yes, this can be optimized. In fact 
> MarbleWidgetInputHandler code need to be fully re-writted... 

Yes, this is known but I haven't had the time to take care of it. Do you have any suggestions how MarbleWidgetInputHandler should look like in the future and what would you like to see changed about it?

>Yes, this is known but I haven't had the time to take care of it. Do you have any >suggestions how MarbleWidgetInputHandler should look like in the future and what >would you like to see changed about it? 

1/ In first, the code structure can still the same but the coding style need to be polished. It's really hard to read code. A lots of comments need to be added, and bracketing fixed.

2/ The section witch handle keyboard do not use Qt keys definition. All is hardcoded without any comments... It's can be not portable (in the case of key definition can be differents in others OS)

I can do point #1

Gilles

Created attachment 25132 [details]
patch version 4

Fix signal name emit by marble widget.
Fix selection behaviours when region is outside active map.
Remove bool flags about section status.

> I can do point #1 

Yes, that would be great.
I think I've done #2 with Revision 817093

Created attachment 25137 [details]
patch version 5

compile with last changes from svn

I wonder whether we shouldn't go for this API for selections which is derived from the API from QGraphicsItem and which seems to cover all cases I can think of at the moment:

void MarbleWidget::setSelectionArea ( GeoDataLatLonAltBox latLonAltBox );
void MarbleWidget::setSelectionArea ( double west, double east, double north, double south );

GeoDataLatLonAltBox MarbleWidget::selectionArea () const
void MarbleWidget::selectionArea ( double &west, double &east, double &north, double &south );

QList<GeoDataObjects *> MarbleWidget::selectedItems () const

void MarbleWidget::selectionChanged ()   [signal]

Do you think this makes sense and do you think that you can change the Digikam code accordingly? :-)

Torsten, 

I'm fully agree with your api. changing digiKam code is not a problem (:=))) go ahead...

Gilles

A video of map search tool in action is available at this url: 

http://digikam3rdparty.free.fr/TourMovies/mapsearchdemo.ogv

Gilles Caulier

This is really really great!

I think it would be useful to display the the location of all
found images as small yellow dots in the right world view and use
(e.g.) a red mark for the currently selected image.
Clicking on a dot should make that image the current one.
(What is not obvious: if there are many dots at essentially the same
point, which should be chosen? Google earth has a pretty good
solution of displaying all the possibilities as a cloud around the
chosen point.
However, I am not sure if something like this is possible with marble...)

Another nice thing would be mini-thumbnails as mouse-overs
over a dot. This could be realized using appropriate kml code
in which the (already generated) thumbnail of the image displayed
in a much smaller version.

To Arnd, #18

>I think it would be useful to display the the location of all
>found images as small yellow dots in the right world view and use
>(e.g.) a red mark for the currently selected image. 

Yes, it's in my TODO list. the current code already use KML to ask to Marble where to place the picture dot on the map. Currently only one picture mark is supported, but i will improve code. If you is curious, look into libs/imageproperties/worldmapwidget.cpp

>Clicking on a dot should make that image the current one.
>(What is not obvious: if there are many dots at essentially the same
>point, which should be chosen? Google earth has a pretty good
>solution of displaying all the possibilities as a cloud around the
>chosen point.
>However, I am not sure if something like this is possible with marble...) 
>
>Another nice thing would be mini-thumbnails as mouse-overs
>over a dot. This could be realized using appropriate kml code
>in which the (already generated) thumbnail of the image displayed
>in a much smaller version. 

Perhaps in the future. New KML import code from marble is currently under construction. Perhaps Torsten can give us more info about...

In all case, is marble can handle mouse click over marks and if a signal is fire from marble, it's easy to use it in digiKam to change iconview focus.

Gilles

Created attachment 25159 [details]
example kml to show a thumbnail on mouse over

The attached file is an example of how to realize a mouse-over thumbnail
using kml. To test this out:
- edit the two occurances of 
  /home/fotos/.thumbnails/large/3869d92528329abd6bc7a34fcc46f1cc.png
  to an existing file in your thumbnails directory
- (optional: adjust  dot_image.png to an existing file with a dot, but
   this is not necessary as GE display a small marker in any case)
- in google earth: add this thumb_mouse_over.kml (with full path)
  as network link to the Temporary Places
- double click on the new entry and it should move you to the location
  of the marker
- now on a mouse over the small thumbnail will be shown
- clicking on that mini-thumbnail will show the thumbnail in larger size
  (including a brief comment).

So to realize this from within digikam, support for
 IconStyle and StyleMap (normal/highlight) 
would be needed.
The Region/LatLonAltBox/Lod/LookAt are not needed for this feature.

I just checked with marble: while this file loads fine and
clicking on the resulting point also allows to see the contents, 
the mouse-over, the IconStyle and StyleMap is not yet supported.

Torsten, if I remember correctly, further kml features are planned
for post 4.1, is that right? Would IconStyle/StyleMap be one of those?

This is all really great work, Gilles, Marcel and Torsten+the marble team.
Thanks a lot! Arnd

SVN commit 817853 by mwiesweg:

- Correct comment: It's lon1 < lon < lon2 (with positive values to East)
- Searching by a lon/lat rectangle: Handle the case that the rectangle
  stretches the 180 deg longitude line.
  In this case lon1 is suddenly greater than lon2, we can omit checking
  for >180/<-180, so it's (lon > lon1 OR lon < lon2)

CCBUG: 153070


 M  +23 -6     imagequerybuilder.cpp   [UTF-8 ENCODING PROBLEMS]


WebSVN link: http://websvn.kde.org/?view=rev&revision=817853

Great work Gilles!

But of course ;-), with patch version 5, Qt4.4 and Marble from current SVN I have noticed a few problems:
- usability: I tried hard and had to read the patch to understand I have to use Ctrl+Drag ;-)
- when you drag the rubber band and the scroll-map-arrows at the edge appear, the map does not scroll, and you cannot drop the rectangle there. If you do this, strange things may happen, such as a rubberband that will always follow the mouse cursor from now on in this widget, regardless of click state.
- the found coordinates are printed in the console; if I copy&paste and check the pairs with Google Map, a much larger region is selected than it is shown on map. If I select a small part of Iceland, the West/North coordinates are somewhere on Greenland.
- here, the rubberband is filled with blue noise while dragging and not drawn at all when dropped. I suspect a Qt problem here, or a problem with my system.

> - usability: I tried hard and had to read the patch to understand I have to use Ctrl+Drag ;-) 

I'm sure Gilles will find a more intuitive way. For now it's important that it's technically working.

> the found coordinates are printed in the console; if I copy&paste and check 
> the pairs with Google Map, a much larger region is selected 

Yes, the coordinates returned are the bounding box values for the viewport.
Mea culpa - I'll sort that out soon however right now I'm under heavy load for my daytime job.

SVN commit 818702 by cgilles:

digiKam from trunk : worldmap widget based on MArble : add support of more than one items to import via KML interface.
CCBUGS: 153070


 M  +16 -8     imagepropertiesgpstab.cpp  
 M  +2 -1      imagepropertiesgpstab.h  
 M  +25 -7     imagepropertiessidebardb.cpp  
 M  +43 -37    worldmapwidget.cpp  
 M  +29 -4     worldmapwidget.h  
 D             worldmapwidgetdb.cpp  
 D             worldmapwidgetdb.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=818702

To Arnd #18:

>I think it would be useful to display the the location of all
>found images as small yellow dots in the right world view and use
>(e.g.) a red mark for the currently selected image.
>Clicking on a dot should make that image the current one.
>(What is not obvious: if there are many dots at essentially the same
>point, which should be chosen? Google earth has a pretty good
>solution of displaying all the possibilities as a cloud around the
>chosen point.
>However, I am not sure if something like this is possible with marble...)

Multiple points over the map is implemented with commit #818702.

>Another nice thing would be mini-thumbnails as mouse-overs
>over a dot. This could be realized using appropriate kml code
>in which the (already generated) thumbnail of the image displayed
>in a much smaller version. 

KML import in marble will be improved in a near future. Add mini thumbs over the map will be possible to add new KML sections in worldmapwidget.cpp.

Gilles Caulier

Created attachment 27057 [details]
Update of the previous patch to SVN KDE 4.1 branch

There are two show stoppers which keep me from applying the patch:

1.) usage of QRubberBand with Oxygen gives garbled screen output
2.) I need to fix the case where the selected bounding box doesn't equal the viewport rect.

Created attachment 27059 [details]
patch against digiKam form trunk (0.10.0-beta3)

This patch must be applied to digiKam to use last marble selection canvas patch #27057

Comment on attachment 27059 [details]
patch against digiKam form trunk (0.10.0-beta3)

patch is now included to digiKam

Torsten,

To perform a search in digiKam database, your patch work very well...

But when i select a Map Search virtual folder from digiKam, it will be nice to set selection area on marble accordingly. I see that you have add a new public slot named setSelection(const Rect&). Sound like this method use a rectangle based on screen coordinate. Why not to provide a way to set selection using a list of coordinate in degrees ? 

Gilles Caulier

Torsten,

What about marble canvas selection patch ? It's applyied to trunk now ?

Gilles Caulier

Marcel,

marble canvas selection patch is now applied to trunk.

Please checkout marble code from trunk, and test your database backend. If all is fine for you, we can close this file...

To help you, the console you can see these debug lines:

Marble: Starting selection 
Marble: Leaving selection
Selection region: ( 93 ,  195 ) ( 258 ,  305 )
West:  -29.3308  North:  65.5512  East:  26.7322  South:  29.1143 

Note : with Oxygen theme, the rubber band is broken (content, not frame). Selection still possible, but it look strange in the canvas. It relevant of Oxygen style. Use another one and all will be fine.

Gilles Caulier 

Works like a charm Gilles, it took me a while to realize that the box is drawn with Ctrl key pressed. :-)

Gerhard

I re-assign this file to Oxygen project following problem described to #31. 

It's only reproducible with Oxygen theme...

Gilles Caulier

There is this patch I made a while ago, which should fix the bug on oxygens side and now I guess I'm forced to commit it: https://bugs.kde.org/attachment.cgi?id=27106

For such selections like marble's it disables the transparent area, which causes the problem. But why does it only happen to marble?

Just an idea: Could it be that it happens due to backing store / double buffering being switched off?

SVN commit 901854 by huynhhuu:

Workaround for Marble to get rubberbands working.
BUG: 169841
CCBUG: 153070

 M  +4 -3      oxygen.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=901854

*** This bug has been confirmed by popular vote. ***

What is the status of this bug? Can the title be changed to reflect the actual Oxygen bug you see? Is there a way to reproduce this with current trunk? Thanks.

If you can provide the information requested in comment #38, please add a comment.

This is an old bug, it has been fixed over 2 years ago. It can be closed.

ok. Closing, then :)