Version: (using KDE 4.3.1) OS: Linux Installed from: Fedora RPMs Using the Geolocation, Edit Geographic Coordinates function. I've used on two pictures and then receive a pop up window stating Max. number of API calls per day reached! The title on the pop-up window is "digikam3rdparty.free.fr - JavaScript -". The limit either is way too low to be useful or there is a bug which is causing the limit to be prematurely exceeded.
The solution is simple : The plugin must use google maps api version 3 instead version 2. Plugin currently use a web site relay through a php page to display googlemaps contents. With version 2, this is mandatory because google require a key ID to play with map. Now with version 3, it's more simple : http://code.google.com/intl/de/apis/maps/documentation/v3/ It no longer needs an API key, this means embedding in the GPS sync plugin would no longer require using digikam3rdparty (=> faster loading). Embedding in Desktop apps seems to be encouraged: http://groups.google.com/group/google-maps-js-api- v3/browse_thread/thread/8c187e778ce921c8 Any volunteers to do it ? Gilles Caulier
Created attachment 39391 [details] Quick port of the coordinates editor to Google Maps V3 and geonames.org The problem with the max. number of API calls was not with Google Maps, but with the service which we used for the altitude. This patch ports the geolocation to Google Maps V3 and geonames.org which also provides some sort of altitude information. The script still resides on the free.fr server, because this way we can push the update before releasing kipi-plugins 1.1. Please test it. You only have to change the URI in gpsmapwidget.cpp:43: gpsLocalorUrl = QString("http://digikam3rdparty.free.fr/gpslocator/getlonlatalt-v3.php"); I think there are still some problems with the altitude. Michael
*** Bug 219874 has been marked as a duplicate of this bug. ***
Run in to the same issue on Karmic, with RC1. I couldn't geotag a single picture today.
I tested the new url with digikam 1.0 and kipi-plugins 1.0 in debian testing, it seems to work quite nicely. No api messages and no ip blocks by google so far. Thankyou a lot!
ok, after about an hour of geotagging google seems to be banning my ip again. Probably I used the dialog to often in too short time. But this time it lasted ways longer than with the old api.
I found two minor bugs. lat 37.98023195505279, lon 12.038891315416759 gives a altitude of -32768. This is possibly a bug in geonames. And you cannot correct this. If I enter another altitude, as soon as I leave the field, the old value is restored. But this is not so serious if the widget is supposed to be replaced anyway I think
(In reply to comment #7) > I found two minor bugs. lat 37.98023195505279, lon 12.038891315416759 gives a > altitude of -32768. This is possibly a bug in geonames. According to Wikipedia, the SRTM data used goes only from 56 °S to 60 °N, but maybe there are some gaps inbetween. > And you cannot correct this. If I enter another altitude, > as soon as I leave the field, the old value is restored. Strange, changing the altitude works fine here... I found that the old version is working again today. Another disadvantage of the new version is that the search box on the map is not (yet?) available in the V3 api. So I think we could go like this: Update the coordinates editor to V3+geonames.org NOW, and leave the track list editor at v2+topocoding.com. If somebody needs features of the old system, he can use the track list editor, and everybody else can at least use the new system and not be blocked by too many API calls. What do you think? Michael
(In reply to comment #8) > So I think we could go like this: Update the coordinates editor to > V3+geonames.org NOW, and leave the track list editor at v2+topocoding.com. If > somebody needs features of the old system, he can use the track list editor, > and everybody else can at least use the new system and not be blocked by too > many API calls. > > What do you think? This sounds like a good idea to me to make the plugin working again for now.
I'd like to ask the developers to increase the importance of this bug and possibly some others related to geotagging, because in the present state the plugin is quite annoying to use. Thanks in advance.
Mike, do you have a quick fix right now? Eg. simply deactivating altitude lookup?
If I may add my 2 cents: I'd suggest this: Look up altitude [ ] (radio button) The rest as in the bottom of Michael G. Hansen's email. I've also submitted a bug #221458 with a full backtrace, because the API error causes a total crash if the window is resized or moved. Hope this helps, and thank you for your involvement.
Created attachment 40191 [details] Add an option to choose the Google Maps API version and the altitude lookup service. Using this patch, one can decide whether to use the Google Maps API V2 or V3 and which altitude lookup service one wants to use: none, geonames.org, topocoding.com Michael
I agree for an option about altitude service, but why google API version. I think V3 must be the default no. Right ? Gilles Caulier
The V3 API does not yet offer everything that the V2 API offers, for example the search bar (bug #222067). So I think that for now, we should offer both APIs. Michael
I agree with Michael G. Hansen - the lack of the search button is another bug I was going to submit. Thanks Gilles for your work.
SVN commit 1080191 by mghansen: Make it possible to choose between the V2 and V3 Google Maps API and between topocoding, geonames and no altitude lookup service. For old versions of the plugin, revert to V2 API to make the search field available. Left to do: Do the same for the track list editor. BUG: 222067 CCBUG: 209365 M +3 -1 NEWS M +305 -40 gpssync/getlonlatalt.php M +88 -2 gpssync/gpseditdialog.cpp M +2 -0 gpssync/gpseditdialog.h M +27 -0 gpssync/gpsmapwidget.cpp M +6 -0 gpssync/gpsmapwidget.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1080191
SVN commit 1080193 by mghansen: Look up altitudes only when dropping the marker and not while moving it. This should reduce the number of calls to topocoding and give us more time before we get blocked. CCBUG: 209365 M +10 -8 tracklistedit.php WebSVN link: http://websvn.kde.org/?view=rev&revision=1080193
Gerald, This file still valid using kipi-plugins 2.4 ? Gilles Caulier
The message causing this bug was emitted by topocoding.com JavaScript, which is not used any more since version 2.0. Michael