It is a bug. It tries to resolve GPS pair from the query once again, what makes of course no sense at all. Accepted + will be fixed.

Any update on this?

i have also issues with GPS coordinates:

this url works: https://wttr.in/52.52045,13.40732

but that not: https://wttr.in/52.52045,13.40731
there is only one 10000'th digit difference

and taking the coordinates that google maps provides, when copy-n-past the coordinates from the map, also doesn't work:
https://wttr.in/52.5205935936161,13.407330726401623

i always get 404:

Unfortunately, the situation is the same.
https://wttr.in/52.248309,21.01475

In addition, appending zeros to a known location will fail:
This works:
https://wttr.in/52.52045,13.40732
This throws a 404:
https://wttr.in/52.520450,13.407320

Still seeing this. Hope fix gets merged soon

We have several problems here.

1. Geolocation does not work for certain locations that look like coordinate pairs (but works for some others).
2. Geolocation may not be really needed when the location is specified as coordinate pairs.

At the moment, the wttr.in service tries to geolocate (resolve into coordinates + human-readable canonical location name) each location, even if it is already a pair of coordinates.

Sometimes it works, sometimes it does not, and if it does not work, a 404 error is returned. That's not something we can control, because the location resolution is done by an external service.

However, what we can control is omitting the resolution if the location is already specified as a pair of coordinates. In this case, there will be no Location: line at the bottom of the forecast, or it will contain only coordinates, but maybe that is okay for the majority of users.

What I propose:

We can add a new option geolocation with several possible values:

• auto -- try to convert, even if it is a pair of coordinates; use the coordinates as a fallback;
• never -- do not try to convert; use the coordinates directly. If the location is not coordinates, return 404.
• always -- always try to convert; if the location is not found, even though it is originally coordinates, return 404.

Then you could use geolocation=never and the pair of coordinates, and it would just work.

Would it be a solution for you?

I would be happy with this as a solution