New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: Province name is ignored while doing IP-base geolocation #492
Comments
wttr.in show the report for please try |
I did not specify any location. I assume it geolocated me by IP.
…On Sun, Jun 28, 2020, 15:08 Igor Chubin ***@***.***> wrote:
wttr.in show the report for
Saratoga County, New York, United States of America,
not Saratoga,CA (by default).
please try saratoga,ca,us instead
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#492 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAVENOJVEQMLUUGLAEOYWTRY65OBANCNFSM4OKV7PGA>
.
|
shit happens i guess, now you know you should specify for your current situation (mobile carrier? ISP with way too broad/many ranges of ips and not using selective attribution?).. Clearly, it's not your fault but it serves as a reminder that geolocation is only as precise as... well... as precise as Per example... my ISP attributes me ip addresses that are, for one great thing, part of a very limited range every time my router/modem reconnects. Great for ssh/firewalling stuff i think. As far as geolocation... well, i'm actually about 500km from where my ips 'discover' or locate me. Not so great for weather precision.... I am an owl with relish (the green type) stuck between the left middle sharpest claws, no spark plugs. Yup. |
I think that it is a bug indeed, because the IP-based geolocation correctly detected location of the IP address, |
I'll just add another data point to this in case it's helpful (I'm 99% sure this is the same bug): When I do a plain curl to
However, I noticed that the temperate was way off (I wish it was 30°C). If I specify my location:
So it looks like the geo-ip look up is correctly getting my location (I am on Bowen Island, in Canada) but when using it to look up the weather it's only using the city name. |
@elliotrushton Yes, it is the very same bug, and #536 (found now by @vzaliva ) is also another reincarnation of the bug. Some part of information (at least province/state name) is getting lost between IP -> LOCATION and LOCATION -> GPS conversion |
Was about to make a new issue when I spotted this. Same occurs for my IP in |
Breakdownhttps://github.com/chubin/wttr.in/blob/master/lib/location.py#L177 I believe we can see the cause of the problem here, where all of your ip based locating methods exclusively return city and country, without any region information. I had a look at all three of these, and I can see the fix for at least two of them. geoipgeoip in location.py offers a region name under It also offers ipinfo
It also offers a comma separated latlong in its ip2locationCame back to this one cause I wasn't satisfied with it, and found that you're getting data with the
This endpoints returns data like so: In fact, I had another look back at ip2location, and it offers a package In other words, all three of your ip to location services can retrieve latlong. I may start over with my pull request; there's a few minor issues with it that I've now noticed, but I'd love to contribute to this project, as I think it's fantastic. Other notesI think you're performing this invokation two times if the input is an IP address; there's a difference between them if the location is some actual location, but if it's an IP, I think you would perform it twice. Another thing I noted is that you are using the IP address to fetch hemisphere information instead of the location; everyone sees the same phase at the same time, so you won't pass an incorrect name, but the /moon endpoint would show an incorrect side of the moon being lit for somebody in the northern hemisphere querying the moon phase in the southern hemisphere. Except, reading things over, I think fetching the moon phase on |
@gregdan3 Gregory thank you a lot for such a detailed analysis, and for the subsequent pull-request. Actually, Regarding cache invalidation: we already have more than 300k entries in the cache (I think that the name "cache" is a little bit misleading, it should be better call local database), and I would like to keep it, because it handle quite big part of the incoming queries. Some of the entries are, maybe, outdated, but not so much. So, what I would suggest:
The rest is looking fine. Thank you once again fro the great contribution! |
Cache file format suggestion:
|
Thanks for the advice; I'll make those changes this coming Sunday at the latest, and throw the changes back here. Can I see some examples of the production cache files as well? |
Sure:
|
Would you prefer I emulate this structure? All of the existing IP locationing methods are able to return latlong (the others give it already, but we have to switch ip2location from WS3 to WS5), so I can also add that onto the cache. |
Yes, it is a good idea |
My pull request is now updated with the requested changes. It should no longer invalidate the cache, but it will not (and cannot) provide exactly the same data as you've shown; it now caches from all three sources, and since not all three sources provide the content after the latlong, I can't be sure how to source that data except for trying a different iplocation method. |
Please see attached screenshot of wttr and weather.com forecast.
There is no sign or rain here and none is likely at this time of year!
The text was updated successfully, but these errors were encountered: