Launchpad refuses to believe that I don't live in Russia, near the Kazakhstan border.

Bug #387738 reported by Gavin Panella
44
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Curtis Hovey

Bug Description

I updated my location using:

  https://edge.launchpad.net/~allenap/+editlocation

I've only moved across town in Norwich, UK, but after hitting Update,
Launchpad thinks I live near Samara in Russia. However, looking
outside, I can confirm that I am still in Norwich.

I tried the same procedure twice, both times with the same result.

Revision history for this message
Curtis Hovey (sinzui) wrote :

Gavin. I have bad news for you. You think you are in Norwich. You are in fact in a recreation of an English town that was used in a Soviet invasion. plan. The Russians have take you there to learn your secrets without you dropping your guard. She is not your wife, and the babies are in recording devices.

Changed in launchpad-registry:
importance: Undecided → Low
status: New → Triaged
tags: added: javascript
Revision history for this message
Curtis Hovey (sinzui) wrote :

I cannot reproduce this using firefox on Ubuntu. The location widget is getting the lat-log coord from google, and passing them geonames.com to get the closest time zone and city. I assumed that launchpad passed a google number that geonames could not handle. However. I cannot reproduce this problem on staging. Can you proide more details, or test again?

Changed in launchpad-registry:
importance: Low → Undecided
status: Triaged → Incomplete
Revision history for this message
eagle00789 (info-decomputeur) wrote :

I have the same issue on https://edge.launchpad.net/~info-decomputeur/+editlocation using FF 3.0.11 on WinXP SP3

Revision history for this message
eagle00789 (info-decomputeur) wrote :

p.s. my correct location is in the netherlands in the city Heerlen.

Revision history for this message
Curtis Hovey (sinzui) wrote :

I suspect that there is some bad math happening in our script between google coords and geonames coords. Since the two cases are near 0 degrees Longitude, I think a rounding/clamp issue is happening. We may be seeing 0 become 90. We have not changes our code in many months, well to lat-long math has not changed in 10 months. So I think this is an issue we are adapting to google and geonames changes.

Changed in launchpad-registry:
importance: Undecided → Low
status: Incomplete → Triaged
Revision history for this message
Olivier Tilloy (osomon) wrote :

Same problem here. I'm trying to set my location to Barcelona, Spain, and it keeps re-setting to somewhere off the coast of Georgia not matter what.
My timezone, however, is correctly set to Europe/Madrid.

Revision history for this message
Curtis Hovey (sinzui) wrote :

That is good information to know. When is it apparent that something is wrong. Is the marker in the wrong place when you set the location, or after you save, you see that the mark has moved to the bad location?

Taking a look at the page source for three affected users I see:
    52.6332408717, 52.6333363734
    50.9198996102, 50.9197553212
    41.5305129031, 41.3850519497

Those are very surprising numbers, and they are in the database. Since geonames returned the right timezone, the correct lat-long pair was sent to geonames. The function that does that also stores that pair in the form that is submitted to launchpad.

So the error looks like it occurs between the moment the the location is set in the page and when it is stored in Launchpad. This is not as helpful as it would seem, because nothing in the script or the widget in Launchpad ever directly changes the lat-long. I say directly because these values are floats and there could be conversion issues moving the values from javascript number -> form string -> Python float.

I think the key to this issue is that the numbers are so similar. It looks like the lat is being used as the long. The numbers differ because of possible float conversions, lat and long do have different ranges, -90..90 and -180..180 respectively.

I am still very perplexed. I cannot reproduce the problem.

Revision history for this message
Charlie Poole (charlie.poole) wrote :

Here's another instance. I set the location for a blind member of my nunit-dev team to Seattle, thinking he was located there. He told me he is actually in Youngstown, Ohio. I zoomed the google map (satellite view) so I could see both Washington and Ohio and dragged him
to Ohio. Then I zoomed in without clicking update and moved him to Youngstown. I clicked update and he ended up somewhere in Siberia although his time zone was set correctly.

I moved him back to Ohio using the same procedure - two moves at two resolutions - and he was again in Siberia.

Finally, keeping the map at a relatively close resolution, I panned from Siberia back to Ohio and clicked on Youngstown, clicked once on the map and then clicked update. That worked.

I suggest experimenting with multiple moves (and possibly zoom levels) before updating.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Here is how I reproduce:

1) I'm going to https://edge.launchpad.net/~osomon/+editlocation
2) Since my current location is wrongly set to Georgia, I zoom out 6 times to get to see Spain
3) I drag the mark to the approximate location of Barcelona, drag the map so that the mark is centred
4) I zoom in 5 times and position more accurately the mark to Barcelona
5) I click "Update", I'm taken back to https://edge.launchpad.net/~osomon
6) Here is a screenshot of the little map displaying my (wrong) location: http://launchpadlibrarian.net/28456538/location.png

Revision history for this message
Curtis Hovey (sinzui) wrote :

Thank you Oliver!

I can reproduce this with myself. I still do not understand the error, but I can provide a simple work around so that everyone can fix themselves.

Click, to place the marker. Do not drag it. I usually click, and I was able to fix my location by

1. Zooming out and clicking the approximate location I should be.
2. Zoom in and click to correct the location.

Step 1 is not really needed,

Revision history for this message
Raúl Núñez de Arenas Coronado (dervishd) wrote :

Curtis, I've checked your "fix" and works for me, thanks a lot! :)

The key seems to avoid dragging the marker.

Raúl

Revision history for this message
Curtis Hovey (sinzui) wrote :

I have a fix for this. The geonames parameter was missing from the call to set location at the drag end event. I'm not sure how to test this since the test system cannot test remote data services like Google and Geonames (which is why the broken code was release in 2.2.5).

Changed in launchpad-registry:
milestone: none → 2.2.7
status: Triaged → In Progress
importance: Low → High
Revision history for this message
Olivier Tilloy (osomon) wrote :

Thanks Curtis, I can confirm that the workaround that consists in not dragging the mark (just clicking instead) works for me.

Curtis Hovey (sinzui)
Changed in launchpad-registry:
assignee: nobody → Curtis Hovey (sinzui)
Revision history for this message
Curtis Hovey (sinzui) wrote :

Fixed in launchpad devel r8861.

Changed in launchpad-registry:
status: In Progress → Fix Committed
Revision history for this message
Olivier Tilloy (osomon) wrote :

Great, thanks for your reactivity Curtis!

Revision history for this message
Christian Reis (kiko) wrote :

Haven't been able to verify this on staging or edge; guess they just haven't updated yet.

Revision history for this message
Curtis Hovey (sinzui) wrote : Bug 387738 Fix released

Fixed released in Launchpad 2.2.7.

Changed in launchpad-registry:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.