maemo.org Bugzilla – Bug 6359
Geolocation show the wrong country when more than one country code in cities database
Last modified: 2010-03-24 06:43:06 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: (Settings > General > About product) EXACT STEPS LEADING TO PROBLEM: When using Geolocation in IM status or Photo tags, GPS or GPS+Network Ovi Maps locate me correctly on the maps. Geolocation tags is wrong : E.G : "@Paris, Tahiti" (instead of "@Paris, France") E.G : "@ Avenue des Champs Elysée, Paris, Tahiti" REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: None relative to location OTHER COMMENTS: Related to topic #35212 on Maemo Talk
I have the same issue. It is showing Tahiti instead of France. I live in Grenoble, France. I've tried in 3 different cities and it still showing "Tahiti, Grenoble", "Tahiti, Meylan", "Tahiti, Echirolles".
*** This bug has been confirmed by popular vote. ***
Here is an idea of the reason : libcityinfo is the library which handles mapping between GPS coords and City Name/Country Name . As mentionned here : http://maemo.org/api_refs/5.0/5.0-final/cityinfo/index.html Libcityinfo does a reverse lookup in a database and match on country code. Tahiti is the property of France, so I guess the Tahity country code is FR (as France) so the reverse lookup gives Tahiti instead of France.... Not sure...but might be the reason
It seems we don't have access to the code so... In the package libcityinfo0-0 there is a file /usr/share/clock/wdb I have removed every lines with FR as the country but the one with Paris, and now it shows France. (not really a fix of course)
Here is the line for Tahiti : 309|qtn_clk_city_tahiti_papeete|FR|qtn_clk_country_tahiti|Pacific/Tahiti|-17.5333333333333|-149.566666666667|0.0694566049382707|0.726405062376968|* We can see the FR code. I changed if to XX.... to try : Now I am located in "Saint Pierre et Miquelon" another France teritory... If I change any other entry with the FR code but France, I am located in france
This bug can happens for every country code appearing more than once in the cities database : /usr/share/clock/wdb That could as an example happens for spain, people in madrid could see Madrid, Las Canarias
Thank you for the bug report. Andre, can you please report it internally. Changing priority to Unspecified and Severity to normal (please check https://bugs.maemo.org/page.cgi?id=fields.html#bug_severity before assigning critical severity to a bug).
Just for information : The Nokia N900 will be released tomorrow in one of the biggest phone shop network in France. This bug will be experienced all french people who will buy this phone, I really think it can damaged in a way the Nokia reputation.
yann: sadly, whatever boxes are available for that shop were made over a week ago, there's no way we can magically retroactively change the original software on them. Our time machines really don't work that well. As for fixing this for the first service release, oddly, the hope was that a lot of work would be done on the clock data and map, but as I wasn't quite sure what in the world to do about this bug, this wasn't something I planned to fix. N.B. I'm an engineer employed by Nokia to work on the Maemo Browser (MicroB), as such I'm not at all officially involved in the Clock's Map or its data. It just so happens, that I was one of two people who tried to improve some of the Clock Data (for what we hope will be the first service release). Having spoken with the team officially responsible for Clock maintenance, I can say with some certainty that if someone doesn't actively do a lot of research to determine the ideal actual result (and report it to them!), then a bug like this is unlikely to be fixed. http://www.webwizardry.net/~timeless/n900/clock/ has the tools and some intermediate data that I used. If things go well, then I believe the wdb file from http://www.webwizardry.net/~timeless/n900/clock/wdb.new should appear in some future service release. However, as I'm not formally involved in the Clock maintenance project, I can't make commitments to that effect. Anyway, the wdb file is plain text, if someone can come up with a list of changes they think should be made to the wdb file that would result in a better outcome, we can try to integrate it. Note that because the wdb file is plain text and has a number of unrelated columns, pain can be experienced when merging (I accidentally lost a couple of fixes to timezone stuff in my latest attempt, but thankfully the official team spotted some of them). So, it's best to provide a list of changes with comments of some sort. WRT the libcityinfo api, as an engineer, I must say that its API is a disaster. It doesn't operate on long/lat, but instead on map coords. In this case, I really can't see the baby for the bath-water and would sooner throw out both.
Anyway, for people interested in testing Geolocation support, an internal tester kindly provided me with the following instructions: Setup: - install gpsfeed + <http://sourceforge.net/projects/gpsfeed/> on a PC - enable External GPS device in Settings/Location - enable Bluetooth connection and pair your PC with your n900 - start emulator to set current position to _insert interesting location here_ From there, your steps will differ, however I'd like to note that afaict no one has actually included steps to reproduce (which as an engineer, I consider incredibly annoying). -- Imagine you're me (or the poor guy who is responsible for maintenance), you get a report "Geolocation tags is [sic] wrong for Paris, France". You ask your boss to approve a trip to Paris, France so you can try to analyze the bug. After fighting for a month, you get your trip approved. You land at CDG, take a train to Paris Central, and then you pull out your n900. You open Ovi Maps which is mentioned in the bug report, and it has the correct location. You're confused, you shake your head, go back to CDG and fly home. -- If you don't think I've ever had such problems, you're misguided, I work for Nokia, we deal w/ location specific problems all the time, my favorite one is that I can't call +1xxxyyyzzzz numbers while I'm in the DC/Boston metro areas on AT&T (it works fine on TMobile or in California/Vancouver), but failure to include all the steps and expected results (e.g. "I'm using <PLUS><10 DIGIT DIALING>") results in trouble tickets being closed as non reproducible, and i'm sure there's an engineer or three shaking their head at my reports. Steps to reproduce should be like this: 0. instructions are in roughly enus1/enus (if your instructions are in some other language, you need to list that in the preconditions) 1. Go to Champs Elysée, Paris, France <http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Champs+Elys%C3%A9e,&sll=48.865789,2.319928&sspn=0.001359,0.003444&ie=UTF8&radius=0.08&rq=1&ev=p&hq=Champs+Elys%C3%A9e,&hnear=&ll=48.865594,2.320718&spn=0.001323,0.003444&z=19&iwloc=lyrftr:m,9114965384244712188,48.865593,2.320717> 2. turn on your n900 3. enable gps and agps in settings>location 4. Open the camera lens cover 5. tap the screen 6. tap the title ("Camera") 7. tap geotagging 8. be sure that Enable geotagging is checked. 9. tap done 10. tap the title ("Camera") 11. tap options (note this is enus1, i'm not sure what the button says in [nokia]enus) 12. change show captured image to 'no' 13. tap save 14. tap the button below the [x] at the top right corner of the screen 15. tap automatic (if you use video, your steps to reproduce below are different, so this step is actually important!) 16. aim your n900 at the monument 17. tap and hold until you get the green box (focused indicator) (there's an audible click if you haven't muted sounds -- probably useless outside with traffic) 18. press harder until the camera actually takes a picture. 19. tap the bottom right button on the screen to go to image viewer 20. tap the last picture in the list 21. tap the center button at the bottom (it looks like a price tag) 22. tap geotagging field expected results: Country [ France ] City [ Paris ] Actual results: Country [ Tahiti ] City [ Paris ]
http://www.iso.org/iso/country_codes/iso_3166-faqs/iso_3166_faqs_specific.htm http://en.wikipedia.org/wiki/.pf the correct country code for tahiti is PF, not FR. If people could figure out the right fix for the other islands that cause problems, then this becomes a much more tractable problem.
Thanks for spending time to answer! I'm sure that this is a hard to reproduce issue (since you're not in France). First I'd like to let you know that I'll make me available for any help in debugging. This bug happens anywhere in France (of course I didn't test any where but I did travel a lot the last week and made some tries to reproduce the bug). I don't blame anyone, for sure you'll not become a globe trotter in order to test geolocation! I also believe although the devices in the boxes could not be fix (Back to the future??) a patch could perhaps be distributed. My main question is why geolocation failed : I had a look at the wdb database and I think although some country code may be wrong (that's the case for Tahity, but this is not the main reason for this bug. If I remove Tahity from the database I'm then located in "Saint Pierre et Miquelon" another french territory sharing country code FR). Here some entries of WDB : 309|qtn_clk_city_tahiti_papeete|FR|qtn_clk_country_tahiti|Pacific/Tahiti|-17.5333333333333|-149.566666666667|0.0694566049382707|0.726405062376968|* 139|qtn_clk_city_french_guiana_cayenne|FR|qtn_clk_country_french_guiana|America/Cayenne|4.93333333333333|-52.3333333333333|0.333967283950618|0.627632618281296|* 140|qtn_clk_city_french_pol_gambier_islands|FR|qtn_clk_country_french_polynesia|Pacific/Gambier|-21.3333333333333|-136.5|0.105002777777777|0.743901708145731|* 138|qtn_clk_city_fra_paris|FR|qtn_clk_country_france|Europe/Paris|48.8666666666667|2.33333333333333|0.48268086419753|0.40525847409864|* An interesting fact is the coordonates are right. I really don't know why liblocation fails, but I think there could have an additional test when several entries with the same country code are found : just compute the distance to the GPS coordonates to select the closest entry. I just hope to do my best to help this bug to be fixed.
To reproduce : 1. Go to anywhere in France 2. turn on your n900 3. enable gps with or without agps in settings>location 4. Open the camera lens cover 5. tap the screen 6. tap the title ("Camera") 7. tap geotagging 8. be sure that Enable geotagging is checked. 9. tap done 10. tap the title ("Camera") 11. tap options (note this is enus1, i'm not sure what the button says in [nokia]enus) 12. change show captured image to 'no' 13. tap save 14. tap the button below the [x] at the top right corner of the screen 15. tap automatic (if you use video, your steps to reproduce below are different, so this step is actually important!) 16. take a picture 17. tap and hold until you get the green box (focused indicator) (there's an audible click if you haven't muted sounds -- probably useless outside with traffic) 18. press harder until the camera actually takes a picture. 19. tap the bottom right button on the screen to go to image viewer 20. tap the last picture in the list 21. tap the center button at the bottom (it looks like a price tag) 22. tap geotagging field Another way : 1. Go to anywhere in France 2. turn on your n900 3. enable gps with or without agps in settings>location 4. tap the square where battery icon is diplayed 5. activate any Instant messaging acount 6. tap Availability 7. tap "My location" 8. set any but "do not show" 9. tape save 10. if A-GPS is set and connection is not set up automaticaly, select the connection to use 11. Let GPS lock (wait the antenna icon stop to blink close to battery icon) 12. Let IM connect (wait the green circle close to battery icon stops to blink) 13. tap the battery icon 14. close to "Availability" the location is shown (At this time I see: @Chaville, Tahiti, should be @Chaville, France : http://maps.google.fr/maps?f=q&source=s_q&hl=fr&geocode=&q=chaville&sll=-17.533333,-149.566667&sspn=0.189221,0.362206&ie=UTF8&hq=&hnear=Chaville,+Hauts-de-Seine,+Ile-de-France&z=15) ) 5. tap the screen 6. tap the title ("Camera") 7. tap geotagging 8. be sure that Enable geotagging is checked. 9. tap done 10. tap the title ("Camera") 11. tap options (note this is enus1, i'm not sure what the button says in [nokia]enus) 12. change show captured image to 'no' 13. tap save 14. tap the button below the [x] at the top right corner of the screen 15. tap automatic (if you use video, your steps to reproduce below are different, so this step is actually important!) 16. take a picture 17. tap and hold until you get the green box (focused indicator) (there's an audible click if you haven't muted sounds -- probably useless outside with traffic) 18. press harder until the camera actually takes a picture. 19. tap the bottom right button on the screen to go to image viewer 20. tap the last picture in the list 21. tap the center button at the bottom (it looks like a price tag) 22. tap geotagging field
After some analysis, here's some of the corrections needed. This won't solve the entirety of it though... Some entries share TLDs with different "countries" (mostly islands) which is a bit problematic. Some other entries have totally incorrect TLDs. First, incorrect TLDs: 139 (qtn_clk_city_french_guiana_cayenne) shares TLD FR needs TLD GF 154 (qtn_clk_city_guadeloupe_pointe_a_pitre) shares TLD FR needs TLD GP 210 (qtn_clk_city_martinique_fort_de_franc) shares TLD FR needs TLD MQ 213 (qtn_clk_city_mayotte_mamoudzou) shares TLD FR needs TLD YT 236 (qtn_clk_city_new_caledonia_noumea) shares TLD FR needs TLD NC 263 (qtn_clk_city_reunion_saint_denis) shares TLD FR needs TLD RE 300 (qtn_clk_city_st_pierre_miquelon_pierre) shares TLD FR needs TLD PM Then, other entries share TLDs: 126 (qtn_clk_city_easter_island_mataveri) shares TLD CL correct, but problemtic. 142 (qtn_clk_city_galapagos_islands_galapagos) shares TLD EC correct, but problemtic 201 (qtn_clk_city_madeira_funchal) shares TLD PT technically correct, problematic 259 (qtn_clk_city_portu_lisbon) shares TLD PT technically correct 295 (qtn_clk_city_spain_madrid) shares TLD ES technically correct 208 (qtn_clk_city_marq_island_taiohae) shares TLD PF I think this is correct, if problematic.. And then, the really problematic ones: 187 (qtn_clk_city_kiribati_tarawa) shares TLD KI not sure how to solve this. 255, 107 and 187 all have KI TLD, and may actually be correct. 309 (qtn_clk_city_tahiti_papeete) shares TLD FR needs TLD PF this will then share with 208 and 140 though...
I have a similar error, though a bit worse. I can be anywhere in Malta: sliema, swieqi, valletta, etc... and the location just marks : Malta,Malta. So its practically useless because everyone knows i'm in malta...
I would say this is not the same issue. This look more like a issue with the suppl.nokia.com server (which seems to be responsible for the lookup at street, district & city levels).
(In reply to comment #15) > I have a similar error, though a bit worse. I can be anywhere in Malta: sliema, > swieqi, valletta, etc... and the location just marks : Malta,Malta. So its > practically useless because everyone knows i'm in malta... Can you specify which kind of positioning you are using (network + GPS?, GPS only ?). Are you correctly located when using OviMaps.
(In reply to comment #17) > (In reply to comment #15) > > I have a similar error, though a bit worse. I can be anywhere in Malta: sliema, > > swieqi, valletta, etc... and the location just marks : Malta,Malta. So its > > practically useless because everyone knows i'm in malta... > > Can you specify which kind of positioning you are using (network + GPS?, GPS > only ?). > Are you correctly located when using OviMaps. > I'm using wifi and GPS. The coordinates are exact, though the map of malta isn't good, so much that the roads show up on the sea. even in ovi maps, I have written: MALTA Malta,Malta
> I'm using wifi and GPS. The coordinates are exact, though the map of malta > isn't good, so much that the roads show up on the sea. even in ovi maps, I have > written: MALTA Malta,Malta Ok, so this is definitively not a problem with liblocation, but with Ovi Maps (or the maps provider NavTeq I guess). I guess this problem should be reported to Nokia / NavTeq directly.
The Maltese problem is different. You can reproduce it from home, actually. Just fly to Malta with Ovi Maps. The overview of the island gives you the names of the municipalities but then if you zoom in you don't see more data. This is not a bug but lack of data. You can also check this from http://maps.ovi.com or http://navteq.com/ from a desktop browser. Feel free contacting Nokia Care and report this problem (lack of maps for Malta). It will be more useful than a bug here. btw, are you rally seeing streets in the sea? This is odd since they look on proper ground in Ovi Maps on the device and the desktop version.
(In reply to comment #20) > The Maltese problem is different. You can reproduce it from home, actually. > Just fly to Malta with Ovi Maps. The overview of the island gives you the names > of the municipalities but then if you zoom in you don't see more data. This is > not a bug but lack of data. You can also check this from http://maps.ovi.com or > http://navteq.com/ from a desktop browser. > > Feel free contacting Nokia Care and report this problem (lack of maps for > Malta). It will be more useful than a bug here. > > btw, are you rally seeing streets in the sea? This is odd since they look on > proper ground in Ovi Maps on the device and the desktop version. > I am reporting the error on nokia's site. the streets in the sea do not show up all the time, maybe it was a runtime bug or something.
Same bug here. The name of my small town have been recognised but the country is Tahiti instead of France
I have the same problem, but in Chile. I'm in "Valparaiso, Chile", but it shows "Valparaiso, Easter Island"
This is due to collision between : 126|qtn_clk_city_easter_island_mataveri|CL|qtn_clk_country_easter_island|Chile/EasterIsland|-27.15|-109.433333333333|0.17863413580247|0.771610875687292|* 104|qtn_clk_city_chile_santiago|CL|qtn_clk_country_chile|America/Santiago|-33.45|-70.6666666666667|0.284093827160494|0.803313578134042|* in wdb, problem : Easter Island shares CL with Chile We will really need to know how libcityinfo does the reverse lookup.
*** Bug 7509 has been marked as a duplicate of this bug. ***
The bug is still there in PR1.1 ... Easter island instead of Chile.
Confirmed.
I can also reproduce this bug with : 2.2009.51-1 Any plan for fix?
for me it shows: Las Condes, Santiago, Easter Island instead of Las Condes, Santiago, Chile Happy to see it is not only a Chile bug.. ;) which means it will probably be addressed sooner
More than two months this bug is open, still no plan to give the community any chance to help to fix it ??
so, the underlying problem is that the _clever_ designers of the reverse geocoding server software/apis didn't consider this stuff and chose to use country codes. There's an advantage. It means they don't have to deal with translating strings into languages. The disadvantage obviously wasn't apparent to them when they chose the design. It sounds like someone has asked someone to consider fixing the apis to suck less. Please note that the server apis are really very far outside of Maemo, they're not our fault, and we have essentially no control over any of it. This bug is currently titled "... when more than one country code in cities database". I'm assuming as such that people are interested in the purity case. The underlying database should have less bad data with the next release meaning that hopefully the mainland countries will not suffer. The Islands should end up with rather strange results, but, I can blame that on empires and their imperialism :)
*** Bug 9683 has been marked as a duplicate of this bug. ***