Detect Location pulls up the wrong city with the same name

[bedaro]

Hi,

In version 1.6.1, if I use "Detect Location" from Northeast Seattle, WA (zip 98115) right across the lake from Kirkland, WA, the app detects my location as Kirkland probably because of the cell tower. The issue, possibly related to #259, is that the weather being shown after my location is detected as "Kirkland, US" is clearly not what's happening in Kirkland, WA (yesterday it said it was snowing, right now it says 21 F when it's at least 20 degrees warmer). This is probably the weather for a different US city also named Kirkland--maybe the IL one?

While the proposed resolution for issue #259 is to show a pop-up when results are ambiguous, if this problem shares the same root cause (retrieving weather info based on a city name search), the solution here should be to pick the closest matching city using the geo coords. From a quick skim of the OpenWeather API, though, I'm not sure I understand why city name would be used at all for a "Detect Location" lookup; why not query based on lat and lon coordinates?

I made some Android apps a long time ago so if I get the time this week or next I may investigate how to fix this myself, that is if it's not being addressed already.

[chreekat]

Came to report the same thing. Brooklyn, OH is assumed when I am actually in Brooklyn, NY.

[chreekat]

You can see what city it thinks you're in by going to the weather map, btw.

[h-theLetter]

Same issue here. It seems to return the first matching city with the same name from OpenWeatherMap.

[robinpaulson]

I'm not sure I understand why city name would be used at all for a "Detect Location" lookup; why not
query based on lat and lon coordinates?

Ill take a guess: the author is based in Europe, a region which has less problematic naming than the US. There is likely only one "Cologne" or "Paris" or "Warsaw" in Europe, due to huge variations in dialect and language, meaning twns with the apparent same origin tend not to have the same spelling or even character set. Names in the US tend to be used over and over, always in English (although sometimes transliterated from German, Swedish, Spanish, etc.). Also, OWM provides the country, not the state/region, again favouring finding the correct place in Europe compared to the US. Given we now understand the way owm provides results, we can act to fix this. As to the second part, I assume owm does some reverse-geocoding if required, turning a name into a lat,lon pair. We could do this ourselves, using nominatin (http://nominatim.org/) or similar.

[robinpaulson]

Help requested finding out how nominatin works in android apps. There is probably a library.

[andrewmattie]

@robinpaulson Currently the app is getting the correct city through the user's lat long but then just does a search by city name leading to the inaccuracy. I believe this could be resolved by using the cityId for the query instead of city name.

[robinpaulson]

Oh, is 'cityid' part of the owm api? If that will possibly fix the issue, we should definitely investigate. Are you prepared to code this? This is a significant bug, it'd be excellent to fix it.

[andrewmattie]

Yeah, it is. I'm currently looking through the code now to see the best way to implement this and if it will fix the bug.

[andrewmattie]

Ok, I've got the cityId changes implemented and it looks like everything works as it should and the bug is fixed. I'm just going to wait for the other PRs to be merged before creating a new one.

[robinpaulson]

Please do! @andrewmattie

[robinpaulson]

Closing, as this appears to be a dupe of #183

[Lee-Carre]

For context, I recently learned (via a mail exchange with staff) that OWM uses GeoNames (map) for locations.

So, it would seem sensible to first ensure that the desired cities are correct & unambiguous in the GeoNames data.