move zig to base, python/go out to legacy
This commit is contained in:
parent
bcab444bca
commit
1800c68081
GPG key ID:
A7B62D657EF764F8
202 changed files with 1120 additions and 765 deletions
2
.gitignore
vendored
2
.gitignore
vendored
|
|
@ -7,3 +7,5 @@ log/
|
|||
*.swp
|
||||
*.mmdb
|
||||
*.dat
|
||||
.zig-cache/
|
||||
zig-out/
|
||||
|
|
|
|||
98
IMPERIAL_UNITS.md
Normal file
98
IMPERIAL_UNITS.md
Normal file
|
|
@ -0,0 +1,98 @@
|
|||
# Imperial Units Implementation
|
||||
|
||||
## Overview
|
||||
|
||||
The application automatically selects between metric and imperial (USCS) units based on the request context, matching the behavior of the original Python implementation.
|
||||
|
||||
## Unit Selection Priority
|
||||
|
||||
The system determines which units to use in the following priority order:
|
||||
|
||||
1. **Explicit query parameter** (highest priority)
|
||||
- `?u` - Force imperial units (°F, mph, inches, inHg)
|
||||
- `?m` - Force metric units (°C, km/h, mm, hPa)
|
||||
|
||||
2. **Language parameter**
|
||||
- `?lang=us` - Use imperial units (for us.wttr.in subdomain)
|
||||
|
||||
3. **Client IP geolocation**
|
||||
- Requests from US IP addresses automatically use imperial units
|
||||
- Uses GeoIP database to detect country code
|
||||
|
||||
4. **Default**
|
||||
- Metric units for all other cases
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Code Changes
|
||||
|
||||
1. **GeoIP Module** (`src/location/geoip.zig`)
|
||||
- Added `isUSIP()` method to detect US IP addresses
|
||||
- Queries MaxMind database for country ISO code
|
||||
- Returns `true` if country code is "US"
|
||||
|
||||
2. **Handler** (`src/http/handler.zig`)
|
||||
- Added `geoip` to `HandleWeatherOptions`
|
||||
- Implements priority logic for unit selection
|
||||
- Extracts client IP from headers (X-Forwarded-For, X-Real-IP)
|
||||
- Passes `use_imperial` flag to all renderers
|
||||
|
||||
3. **Renderers** (all updated to support imperial units)
|
||||
- `ansi.zig` - Shows °F instead of °C
|
||||
- `line.zig` - Shows °F and mph for formats 1-4
|
||||
- `custom.zig` - Converts all units (temp, wind, precip, pressure)
|
||||
- `v2.zig` - Shows imperial units in detailed format
|
||||
- `json.zig` - Already outputs both units (no changes needed)
|
||||
|
||||
### Conversions
|
||||
|
||||
- Temperature: `°F = °C × 9/5 + 32`
|
||||
- Wind speed: `mph = km/h × 0.621371`
|
||||
- Precipitation: `inches = mm × 0.0393701`
|
||||
- Pressure: `inHg = hPa × 0.02953`
|
||||
|
||||
## Testing
|
||||
|
||||
### Unit Tests
|
||||
|
||||
All renderers have unit tests verifying imperial units:
|
||||
- `test "render with imperial units"` in ansi.zig
|
||||
- `test "format 2 with imperial units"` in line.zig
|
||||
- `test "render custom format with imperial units"` in custom.zig
|
||||
- `test "render v2 format with imperial units"` in v2.zig
|
||||
- `test "imperial units selection logic"` in handler.zig
|
||||
- `test "isUSIP detects US IPs"` in geoip.zig
|
||||
|
||||
### Integration Testing
|
||||
|
||||
```bash
|
||||
# Test with lang=us
|
||||
curl "http://localhost:8002/London?lang=us&format=2"
|
||||
# Output: 51.5074,-0.1278: ☁️ 54°F 🌬️SW19mph
|
||||
|
||||
# Test with explicit ?u
|
||||
curl "http://localhost:8002/London?format=2&u"
|
||||
# Output: 51.5074,-0.1278: ☁️ 54°F 🌬️SW19mph
|
||||
|
||||
# Test metric override
|
||||
curl "http://localhost:8002/London?lang=us&format=2&m"
|
||||
# Output: 51.5074,-0.1278: ☁️ 12°C 🌬️SW30km/h
|
||||
|
||||
# Test from US IP (automatic detection)
|
||||
curl -H "X-Forwarded-For: 8.8.8.8" "http://localhost:8002/London?format=2"
|
||||
# Output: Uses imperial if 8.8.8.8 is detected as US IP
|
||||
```
|
||||
|
||||
## Documentation Updates
|
||||
|
||||
- **API_ENDPOINTS.md** - Added "Unit System Defaults" section explaining priority
|
||||
- **README.md** - Updated "Implemented Features" to mention auto-detection
|
||||
- **IMPERIAL_UNITS.md** - This document
|
||||
|
||||
## Compatibility
|
||||
|
||||
This implementation matches the original Python behavior in `lib/parse_query.py`:
|
||||
- Same priority order
|
||||
- Same detection logic
|
||||
- Same unit conversions
|
||||
- Compatible with existing clients and scripts
|
||||
765
README.md
765
README.md
|
|
@ -1,612 +1,153 @@
|
|||
*wttr.in — the right way to check the weather!*
|
||||
|
||||
wttr.in is a console-oriented weather forecast service that supports various information
|
||||
representation methods like terminal-oriented ANSI-sequences for console HTTP clients
|
||||
(curl, httpie, or wget), HTML for web browsers, or PNG for graphical viewers.
|
||||
|
||||
wttr.in uses [wego](http://github.com/schachmat/wego) for visualization
|
||||
and various data sources for weather forecast information.
|
||||
|
||||
You can see it running here: [wttr.in](http://wttr.in).
|
||||
|
||||
## Usage
|
||||
|
||||
You can access the service from a shell or from a Web browser like this:
|
||||
|
||||
$ curl wttr.in
|
||||
Weather for City: Paris, France
|
||||
|
||||
\ / Clear
|
||||
.-. 10 – 11 °C
|
||||
― ( ) ― ↑ 11 km/h
|
||||
`-’ 10 km
|
||||
/ \ 0.0 mm
|
||||
|
||||
|
||||
Here is an actual weather report for your location (it's live!):
|
||||
|
||||
|
||||
|
||||
(It's not your actual location - GitHub's CDN hides your real IP address with its own IP address,
|
||||
but it's still a live weather report in your language.)
|
||||
|
||||
Or in PowerShell:
|
||||
|
||||
```PowerShell
|
||||
Invoke-RestMethod http://wttr.in
|
||||
```
|
||||
|
||||
Want to get the weather information for a specific location? You can add the desired location to the URL in your
|
||||
request like this:
|
||||
|
||||
$ curl wttr.in/London
|
||||
$ curl wttr.in/Moscow
|
||||
$ curl wttr.in/Salt+Lake+City
|
||||
|
||||
If you omit the location name, you will get the report for your current location based on your IP address.
|
||||
|
||||
Use 3-letter airport codes in order to get the weather information at a certain airport:
|
||||
|
||||
$ curl wttr.in/muc # Weather for IATA: muc, Munich International Airport, Germany
|
||||
$ curl wttr.in/ham # Weather for IATA: ham, Hamburg Airport, Germany
|
||||
|
||||
Let's say you'd like to get the weather for a geographical location other than a town or city - maybe an attraction
|
||||
in a city, a mountain name, or some special location. Add the character `~` before the name to look up that special
|
||||
location name before the weather is then retrieved:
|
||||
|
||||
$ curl wttr.in/~Vostok+Station
|
||||
$ curl wttr.in/~Eiffel+Tower
|
||||
$ curl wttr.in/~Kilimanjaro
|
||||
|
||||
For these examples, you'll see a line below the weather forecast output that shows the geolocation
|
||||
results of looking up the location:
|
||||
|
||||
Location: Vostok Station, станция Восток, AAT, Antarctica [-78.4642714,106.8364678]
|
||||
Location: Tour Eiffel, 5, Avenue Anatole France, Gros-Caillou, 7e, Paris, Île-de-France, 75007, France [48.8582602,2.29449905432]
|
||||
Location: Kilimanjaro, Northern, Tanzania [-3.4762789,37.3872648]
|
||||
|
||||
You can also use IP-addresses (direct) or domain names (prefixed with `@`) to specify a location:
|
||||
|
||||
$ curl wttr.in/@github.com
|
||||
$ curl wttr.in/@msu.ru
|
||||
|
||||
To get detailed information online, you can access the [/:help](http://wttr.in/:help) page:
|
||||
|
||||
$ curl wttr.in/:help
|
||||
|
||||
|
||||
### Weather Units
|
||||
|
||||
By default the USCS units are used for the queries from the USA and the metric system for the rest of the world.
|
||||
You can override this behavior by adding `?u` or `?m` to a URL like this:
|
||||
|
||||
$ curl wttr.in/Amsterdam?u
|
||||
$ curl wttr.in/Amsterdam?m
|
||||
|
||||
## Supported output formats and views
|
||||
|
||||
wttr.in currently supports five output formats:
|
||||
|
||||
* ANSI for the terminal;
|
||||
* Plain-text for the terminal and scripts;
|
||||
* HTML for the browser;
|
||||
* PNG for the graphical viewers;
|
||||
* JSON for scripts and APIs;
|
||||
* Prometheus metrics for scripts and APIs.
|
||||
|
||||
The ANSI and HTML formats are selected basing on the User-Agent string.
|
||||
The PNG format can be forced by adding `.png` to the end of the query:
|
||||
|
||||
$ wget wttr.in/Paris.png
|
||||
|
||||
You can use all of the options with the PNG-format like in an URL, but you have
|
||||
to separate them with `_` instead of `?` and `&`:
|
||||
|
||||
$ wget wttr.in/Paris_0tqp_lang=fr.png
|
||||
|
||||
Useful options for the PNG format:
|
||||
|
||||
* `t` for transparency (`transparency=150`);
|
||||
* transparency=0..255 for a custom transparency level.
|
||||
|
||||
Transparency is a useful feature when weather PNGs are used to add weather data to pictures:
|
||||
|
||||
$ convert source.jpg <( curl wttr.in/Oymyakon_tqp0.png ) -geometry +50+50 -composite target.jpg
|
||||
|
||||
In this example:
|
||||
|
||||
* `source.jpg` - source file;
|
||||
* `target.jpg` - target file;
|
||||
* `Oymyakon` - name of the location;
|
||||
* `tqp0` - options (recommended).
|
||||
|
||||
|
||||
|
||||
You can embed a special wttr.in widget, that displays the weather condition for the current or a selected location, into a HTML page using the [wttr-switcher](https://github.com/midzer/wttr-switcher). That is how it looks like: [wttr-switcher-example](https://midzer.github.io/wttr-switcher/) or on a real world web site: https://feuerwehr-eisolzried.de/.
|
||||
|
||||
|
||||
|
||||
## One-line output
|
||||
|
||||
For one-line output format, specify additional URL parameter `format`:
|
||||
|
||||
```
|
||||
$ curl wttr.in/Nuremberg?format=3
|
||||
Nuremberg: 🌦 +11⁰C
|
||||
```
|
||||
|
||||
Available preconfigured formats: 1, 2, 3, 4 and the custom format using the percent notation (see below).
|
||||
|
||||
You can specify multiple locations separated with `:` (for repeating queries):
|
||||
|
||||
```
|
||||
$ curl wttr.in/Nuremberg:Hamburg:Berlin?format=3
|
||||
Nuremberg: 🌦 +11⁰C
|
||||
```
|
||||
Or to process all this queries at once:
|
||||
|
||||
```
|
||||
$ curl -s 'wttr.in/{Nuremberg,Hamburg,Berlin}?format=3'
|
||||
Nuremberg: 🌦 +11⁰C
|
||||
Hamburg: 🌦 +8⁰C
|
||||
Berlin: 🌦 +8⁰C
|
||||
```
|
||||
|
||||
To specify your own custom output format, use the special `%`-notation:
|
||||
|
||||
```
|
||||
c Weather condition,
|
||||
C Weather condition textual name,
|
||||
h Humidity,
|
||||
t Temperature (Actual),
|
||||
f Temperature (Feels Like),
|
||||
w Wind,
|
||||
l Location,
|
||||
m Moonphase 🌑🌒🌓🌔🌕🌖🌗🌘,
|
||||
M Moonday,
|
||||
p precipitation (mm),
|
||||
o Probability of Precipitation,
|
||||
P pressure (hPa),
|
||||
|
||||
D Dawn*,
|
||||
S Sunrise*,
|
||||
z Zenith*,
|
||||
s Sunset*,
|
||||
d Dusk*.
|
||||
|
||||
(*times are shown in the local timezone)
|
||||
```
|
||||
|
||||
So, these two calls are the same:
|
||||
|
||||
```
|
||||
$ curl wttr.in/London?format=3
|
||||
London: ⛅️ +7⁰C
|
||||
$ curl wttr.in/London?format="%l:+%c+%t\n"
|
||||
London: ⛅️ +7⁰C
|
||||
```
|
||||
Keep in mind, that when using in `tmux.conf`, you have to escape `%` with `%`, i.e. write there `%%` instead of `%`.
|
||||
|
||||
In programs, that are querying the service automatically (such as tmux), it is better to use some reasonable update interval. In tmux, you can configure it with `status-interval`.
|
||||
|
||||
If several, `:` separated locations, are specified in the query, specify update period
|
||||
as an additional query parameter `period=`:
|
||||
```
|
||||
set -g status-interval 60
|
||||
WEATHER='#(curl -s wttr.in/London:Stockholm:Moscow\?format\="%%l:+%%c%%20%%t%%60%%w&period=60")'
|
||||
set -g status-right "$WEATHER ..."
|
||||
```
|
||||
|
||||
|
||||
To see emojis in terminal, you need:
|
||||
|
||||
1. Terminal support for emojis (was added to Cairo 1.15.8);
|
||||
2. Font with emojis support.
|
||||
|
||||
For the Emoji font, we recommend *Noto Color Emoji*, and a good alternative option would be the *Emoji One* font;
|
||||
both of them support all necessary emoji glyphs.
|
||||
|
||||
Font configuration:
|
||||
|
||||
```xml
|
||||
$ cat ~/.config/fontconfig/fonts.conf
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
|
||||
<fontconfig>
|
||||
<alias>
|
||||
<family>serif</family>
|
||||
<prefer>
|
||||
<family>Noto Color Emoji</family>
|
||||
</prefer>
|
||||
</alias>
|
||||
<alias>
|
||||
<family>sans-serif</family>
|
||||
<prefer>
|
||||
<family>Noto Color Emoji</family>
|
||||
</prefer>
|
||||
</alias>
|
||||
<alias>
|
||||
<family>monospace</family>
|
||||
<prefer>
|
||||
<family>Noto Color Emoji</family>
|
||||
</prefer>
|
||||
</alias>
|
||||
</fontconfig>
|
||||
```
|
||||
|
||||
(to apply the configuration, run `fc-cache -f -v`)
|
||||
|
||||
## Data-rich output format
|
||||
|
||||
In the experimental data-rich output format, that is available under the view code `v2`,
|
||||
a lot of additional weather and astronomical information is available:
|
||||
|
||||
* Temperature, and precepetation changes forecast throughout the days;
|
||||
* Moonphase for today and the next three days;
|
||||
* The current weather condition, temperature, humidity, windspeed and direction, pressure;
|
||||
* Timezone;
|
||||
* Dawn, sunrise, noon, sunset, dusk time for he selected location;
|
||||
* Precise geographical coordinates for the selected location.
|
||||
|
||||
```
|
||||
$ curl v2.wttr.in/München
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
$ curl wttr.in/München?format=v2
|
||||
```
|
||||
|
||||
or, if you prefer Nerd Fonts instead of Emoji, `v2d` (day) or `v2n` (night):
|
||||
|
||||
```
|
||||
$ curl v2d.wttr.in/München
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
(The mode is experimental, and it has several limitations currently:
|
||||
|
||||
* It works only in terminal;
|
||||
* Only English is supported).
|
||||
|
||||
Currently, you need some tweaks for some terminals, to get the best possible visualization.
|
||||
|
||||
### URXVT
|
||||
|
||||
Depending on your configuration you might be taking all steps, or only a few. URXVT currently doesn't support emoji related fonts, but we can get almost the same effect using *Font-Symbola*. So add to your `.Xresources` file the following line:
|
||||
```
|
||||
xft:symbola:size=10:minspace=False
|
||||
```
|
||||
You can add it _after_ your preferred font and it will only show up when required.
|
||||
Then, if you see or feel like you're having spacing issues, add this: `URxvt.letterSpace: 0`
|
||||
For some reason URXVT sometimes stops deciding right the word spacing and we need to force it this way.
|
||||
|
||||
The result, should look like:
|
||||
|
||||
|
||||
|
||||
## Different output formats
|
||||
|
||||
### JSON output
|
||||
|
||||
The JSON format is a feature providing access to *wttr.in* data through an easy-to-parse format, without requiring the user to create a complex script to reinterpret wttr.in's graphical output.
|
||||
|
||||
To fetch information in JSON format, use the following syntax:
|
||||
|
||||
$ curl wttr.in/Detroit?format=j1
|
||||
|
||||
This will fetch information on the Detroit region in JSON format. The j1 format code is used to allow for the use of other layouts for the JSON output.
|
||||
|
||||
The result will look something like the following:
|
||||
```json
|
||||
{
|
||||
"current_condition": [
|
||||
{
|
||||
"FeelsLikeC": "25",
|
||||
"FeelsLikeF": "76",
|
||||
"cloudcover": "100",
|
||||
"humidity": "76",
|
||||
"observation_time": "04:08 PM",
|
||||
"precipMM": "0.2",
|
||||
"pressure": "1019",
|
||||
"temp_C": "22",
|
||||
"temp_F": "72",
|
||||
"uvIndex": 5,
|
||||
"visibility": "16",
|
||||
"weatherCode": "122",
|
||||
"weatherDesc": [
|
||||
{
|
||||
"value": "Overcast"
|
||||
}
|
||||
],
|
||||
"weatherIconUrl": [
|
||||
{
|
||||
"value": ""
|
||||
}
|
||||
],
|
||||
"winddir16Point": "NNE",
|
||||
"winddirDegree": "20",
|
||||
"windspeedKmph": "7",
|
||||
"windspeedMiles": "4"
|
||||
}
|
||||
],
|
||||
...
|
||||
```
|
||||
|
||||
Most of these values are self-explanatory, aside from `weatherCode`. The `weatherCode` is an enumeration which you can find at either [the WorldWeatherOnline website](https://www.worldweatheronline.com/developer/api/docs/weather-icons.aspx) or [in the wttr.in source code](https://github.com/chubin/wttr.in/blob/master/lib/constants.py).
|
||||
|
||||
### Prometheus Metrics Output
|
||||
|
||||
The [Prometheus](https://github.com/prometheus/prometheus) Metrics format is a feature providing access to *wttr.in* data through an easy-to-parse format for monitoring systems, without requiring the user to create a complex script to reinterpret wttr.in's graphical output.
|
||||
|
||||
To fetch information in Prometheus format, use the following syntax:
|
||||
|
||||
$ curl wttr.in/Detroit?format=p1
|
||||
|
||||
This will fetch information on the Detroit region in Prometheus Metrics format. The `p1` format code is used to allow for the use of other layouts for the Prometheus Metrics output.
|
||||
|
||||
A possible configuration for Prometheus could look like this:
|
||||
|
||||
```yaml
|
||||
- job_name: 'wttr_in_detroit'
|
||||
static_configs:
|
||||
- targets: ['wttr.in']
|
||||
metrics_path: '/Detroit'
|
||||
params:
|
||||
format: ['p1']
|
||||
```
|
||||
|
||||
The result will look something like the following:
|
||||
|
||||
|
||||
# HELP temperature_feels_like_celsius Feels Like Temperature in Celsius
|
||||
temperature_feels_like_celsius{forecast="current"} 7
|
||||
# HELP temperature_feels_like_fahrenheit Feels Like Temperature in Fahrenheit
|
||||
temperature_feels_like_fahrenheit{forecast="current"} 45
|
||||
[truncated]
|
||||
...
|
||||
|
||||
|
||||
## Moon phases
|
||||
|
||||
wttr.in can also be used to check the phase of the Moon. This example shows how to see the current Moon phase
|
||||
in the full-output mode:
|
||||
|
||||
$ curl wttr.in/Moon
|
||||
|
||||
Get the Moon phase for a particular date by adding `@YYYY-MM-DD`:
|
||||
|
||||
$ curl wttr.in/Moon@2016-12-25
|
||||
|
||||
The Moon phase information uses [pyphoon](https://github.com/chubin/pyphoon) as its backend.
|
||||
|
||||
To get the moon phase information in the online mode, use `%m`:
|
||||
|
||||
$ curl wttr.in/London?format=%m
|
||||
🌖
|
||||
|
||||
Keep in mind that the Unicode representation of moonphases suffers 2 caveats:
|
||||
|
||||
- With some fonts, the representation `🌘` is ambiguous, for it either seem
|
||||
almost-shadowed or almost-lit, depending on whether your terminal is in
|
||||
light mode or dark mode. Relying on colored fonts like `noto-fonts` works
|
||||
around this problem.
|
||||
|
||||
- The representation `🌘` is also ambiguous, for it means "last quarter" in
|
||||
northern hemisphere, but "first quarter" in souther hemisphere. It also means
|
||||
nothing in tropical zones. This is a limitation that
|
||||
[Unicode](https://www.unicode.org/L2/L2017/17304-moon-var.pdf) is aware about.
|
||||
But it has not been worked around at `wttr.in` yet.
|
||||
|
||||
See #247, #364 for the corresponding tracking issues,
|
||||
and [pyphoon#1](https://github.com/chubin/pyphoon/issues/1) for pyphoon. Any help is welcome.
|
||||
|
||||
## Internationalization and localization
|
||||
|
||||
wttr.in supports multilingual locations names that can be specified in any language in the world
|
||||
(it may be surprising, but many locations in the world don't have an English name).
|
||||
|
||||
The query string should be specified in Unicode (hex-encoded or not). Spaces in the query string
|
||||
must be replaced with `+`:
|
||||
|
||||
$ curl wttr.in/станция+Восток
|
||||
Weather report: станция Восток
|
||||
|
||||
Overcast
|
||||
.--. -65 – -47 °C
|
||||
.-( ). ↑ 23 km/h
|
||||
(___.__)__) 15 km
|
||||
0.0 mm
|
||||
|
||||
The language used for the output (except the location name) does not depend on the input language
|
||||
and it is either English (by default) or the preferred language of the browser (if the query
|
||||
was issued from a browser) that is specified in the query headers (`Accept-Language`).
|
||||
|
||||
The language can be set explicitly when using console clients by using command-line options like this:
|
||||
|
||||
curl -H "Accept-Language: fr" wttr.in
|
||||
http GET wttr.in Accept-Language:ru
|
||||
|
||||
The preferred language can be forced using the `lang` option:
|
||||
|
||||
$ curl wttr.in/Berlin?lang=de
|
||||
|
||||
The third option is to choose the language using the DNS name used in the query:
|
||||
|
||||
$ curl de.wttr.in/Berlin
|
||||
|
||||
wttr.in is currently translated into 54 languages, and the number of supported languages is constantly growing.
|
||||
|
||||
See [/:translation](http://wttr.in/:translation) to learn more about the translation process,
|
||||
to see the list of supported languages and contributors, or to know how you can help to translate wttr.in
|
||||
in your language.
|
||||
|
||||
|
||||
|
||||
## Windows Users
|
||||
|
||||
There are currently two Windows related issues that prevent the examples found on this page from working exactly as expected out of the box. Until Microsoft fixes the issues, there are a few workarounds. To circumvent both issues you may use a shell such as `bash` on the [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/install-win10) or read on for alternative solutions.
|
||||
|
||||
### Garbage characters in the output
|
||||
There is a limitation of the current Win32 version of `curl`. Until the [Win32 curl issue](https://github.com/chubin/wttr.in/issues/18#issuecomment-474145551) is resolved and rolled out in a future Windows release, it is recommended that you use Powershell’s `Invoke-Web-Request` command instead:
|
||||
- `(Invoke-WebRequest http://wttr.in).Content`
|
||||
|
||||
### Missing or double wide diagonal wind direction characters
|
||||
The second issue is regarding the width of the diagonal arrow glyphs that some Windows Terminal Applications such as the default `conhost.exe` use. At the time of writing this, `ConEmu.exe`, `ConEmu64.exe` and Terminal Applications built on top of ConEmu such as Cmder (`cmder.exe`) use these double-wide glyphs by default. The result is the same with all of these programs, either a missing character for certain wind directions or a broken table in the output or both. Some third-party Terminal Applications have addressed the wind direction glyph issue but that fix depends on the font and the Terminal Application you are using.
|
||||
One way to display the diagonal wind direction glyphs in your Terminal Application is to use [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701?activetab=pivot:overviewtab) which is currently available in the [Microsoft Store](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701?activetab=pivot:overviewtab). Windows Terminal is currently a preview release and will be rolled out as the default Terminal Application in an upcoming release. If your output is still skewed after using Windows Terminal then try maximizing the terminal window.
|
||||
Another way you can display the diagonal wind direction is to swap out the problematic characters with forward and backward slashes as shown [here](https://github.com/chubin/wttr.in/issues/18#issuecomment-405640892).
|
||||
|
||||
## Installation
|
||||
|
||||
To install the application:
|
||||
|
||||
1. Install external dependencies
|
||||
2. Install Python dependencies used by the service
|
||||
3. Configure IP2Location (optional)
|
||||
4. Get a WorldWeatherOnline API and configure wego
|
||||
5. Configure wttr.in
|
||||
6. Configure the HTTP-frontend service
|
||||
|
||||
### Install external dependencies
|
||||
|
||||
wttr.in has the following external dependencies:
|
||||
|
||||
* [golang](https://golang.org/doc/install), wego dependency
|
||||
* [wego](https://github.com/schachmat/wego), weather client for terminal
|
||||
|
||||
After you install [golang](https://golang.org/doc/install), install `wego`:
|
||||
|
||||
$ go get -u github.com/schachmat/wego
|
||||
$ go install github.com/schachmat/wego
|
||||
|
||||
### Install Python dependencies
|
||||
|
||||
Python requirements:
|
||||
|
||||
* Flask
|
||||
* geoip2
|
||||
* geopy
|
||||
* requests
|
||||
* gevent
|
||||
|
||||
If you want to get weather reports as PNG files, you'll also need to install:
|
||||
|
||||
* PIL
|
||||
* pyte (>=0.6)
|
||||
* necessary fonts
|
||||
|
||||
You can install most of them using `pip`.
|
||||
|
||||
Some python package use LLVM, so install it first:
|
||||
|
||||
$ apt-get install llvm-7 llvm-7-dev
|
||||
|
||||
If `virtualenv` is used:
|
||||
|
||||
$ virtualenv -p python3 ve
|
||||
$ ve/bin/pip3 install -r requirements.txt
|
||||
$ ve/bin/python3 bin/srv.py
|
||||
|
||||
Also, you need to install the geoip2 database.
|
||||
You can use a free database GeoLite2 that can be downloaded from (http://dev.maxmind.com/geoip/geoip2/geolite2/).
|
||||
|
||||
### Configure IP2Location (optional)
|
||||
|
||||
If you want to use the IP2location service for IP-addresses that are not covered by GeoLite2,
|
||||
you have to obtain a API key of that service, and after that save into the `~/.ip2location.key` file:
|
||||
|
||||
```
|
||||
$ echo 'YOUR_IP2LOCATION_KEY' > ~/.ip2location.key
|
||||
```
|
||||
|
||||
If you don't have this file, the service will be silently skipped (it is not a big problem,
|
||||
because the MaxMind database is pretty good).
|
||||
|
||||
### Installation with Docker
|
||||
|
||||
* Install Docker
|
||||
* Build Docker Image
|
||||
* These files should be mounted by the user at runtime:
|
||||
|
||||
```
|
||||
/root/.wegorc
|
||||
/root/.ip2location.key (optional)
|
||||
/app/airports.dat
|
||||
/app/GeoLite2-City.mmdb
|
||||
```
|
||||
|
||||
### Get a WorldWeatherOnline key and configure wego
|
||||
|
||||
To get a WorldWeatherOnline API key, you must register here:
|
||||
|
||||
https://developer.worldweatheronline.com/auth/register
|
||||
|
||||
After you have a WorldWeatherOnline key, you can save it into the
|
||||
WWO key file: `~/.wwo.key`
|
||||
|
||||
Also, you have to specify the key in the `wego` configuration:
|
||||
|
||||
```json
|
||||
$ cat ~/.wegorc
|
||||
{
|
||||
"APIKey": "00XXXXXXXXXXXXXXXXXXXXXXXXXXX",
|
||||
"City": "London",
|
||||
"Numdays": 3,
|
||||
"Imperial": false,
|
||||
"Lang": "en"
|
||||
}
|
||||
```
|
||||
|
||||
The `City` parameter in `~/.wegorc` is ignored.
|
||||
|
||||
### Configure wttr.in
|
||||
|
||||
Configure the following environment variables that define the path to the local `wttr.in`
|
||||
installation, to the GeoLite database, and to the `wego` installation. For example:
|
||||
|
||||
```bash
|
||||
export WTTR_MYDIR="/home/igor/wttr.in"
|
||||
export WTTR_GEOLITE="/home/igor/wttr.in/GeoLite2-City.mmdb"
|
||||
export WTTR_WEGO="/home/igor/go/bin/wego"
|
||||
export WTTR_LISTEN_HOST="0.0.0.0"
|
||||
export WTTR_LISTEN_PORT="8002"
|
||||
```
|
||||
|
||||
|
||||
### Configure the HTTP-frontend service
|
||||
|
||||
It's recommended that you also configure the web server that will be used to access the service:
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen [::]:80;
|
||||
server_name wttr.in *.wttr.in;
|
||||
access_log /var/log/nginx/wttr.in-access.log main;
|
||||
error_log /var/log/nginx/wttr.in-error.log;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:8002;
|
||||
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $remote_addr;
|
||||
|
||||
client_max_body_size 10m;
|
||||
client_body_buffer_size 128k;
|
||||
|
||||
proxy_connect_timeout 90;
|
||||
proxy_send_timeout 90;
|
||||
proxy_read_timeout 90;
|
||||
|
||||
proxy_buffer_size 4k;
|
||||
proxy_buffers 4 32k;
|
||||
proxy_busy_buffers_size 64k;
|
||||
proxy_temp_file_write_size 64k;
|
||||
|
||||
expires off;
|
||||
}
|
||||
}
|
||||
```
|
||||
# wttr.in Zig Rewrite Documentation
|
||||
|
||||
This directory contains comprehensive documentation for rewriting wttr.in in Zig.
|
||||
|
||||
## Current Implementation Status
|
||||
|
||||
### Implemented Features
|
||||
- HTTP server with routing and middleware
|
||||
- Rate limiting
|
||||
- Caching system
|
||||
- GeoIP database integration (libmaxminddb)
|
||||
- Location resolver with multiple input types
|
||||
- Output formats: ANSI, line (1-4), JSON (j1), v2 data-rich, custom (%)
|
||||
- Query parameter parsing
|
||||
- Static help pages (/:help, /:translation)
|
||||
- Error handling (404/500 status codes)
|
||||
- Configuration from environment variables
|
||||
- **Imperial units auto-detection**: Automatically uses imperial units (°F, mph) for US IP addresses and `lang=us`, with explicit `?u` and `?m` overrides
|
||||
|
||||
### Missing Features (To Be Implemented Later)
|
||||
|
||||
1. **Prometheus Metrics Format** (format=p1)
|
||||
- Export weather data in Prometheus metrics format
|
||||
- See API_ENDPOINTS.md for format specification
|
||||
|
||||
2. **PNG Generation**
|
||||
- Render weather reports as PNG images
|
||||
- Support transparency and custom styling
|
||||
- Requires image rendering library integration
|
||||
|
||||
3. **Multiple Locations Support**
|
||||
- Handle colon-separated locations (e.g., `London:Paris:Berlin`)
|
||||
- Process and display weather for multiple cities in one request
|
||||
|
||||
4. **Language/Localization**
|
||||
- Accept-Language header parsing
|
||||
- lang query parameter support
|
||||
- Translation of weather conditions and text (54 languages)
|
||||
|
||||
5. **Moon Phase Calculation**
|
||||
- Real moon phase computation based on date
|
||||
- Moon phase emoji display
|
||||
- Moonday calculation
|
||||
|
||||
6. **Astronomical Times**
|
||||
- Calculate dawn, sunrise, zenith, sunset, dusk times
|
||||
- Based on location coordinates and timezone
|
||||
- Display in custom format output
|
||||
|
||||
## Documentation Files
|
||||
|
||||
### [TARGET_ARCHITECTURE.md](TARGET_ARCHITECTURE.md) ⭐ NEW
|
||||
Target architecture for Zig rewrite:
|
||||
- Single binary design
|
||||
- Simplified caching (one layer)
|
||||
- Pluggable weather provider interface
|
||||
- Rate limiting middleware
|
||||
- Module structure
|
||||
- Testing strategy
|
||||
- Performance targets
|
||||
|
||||
### [ARCHITECTURE.md](ARCHITECTURE.md)
|
||||
Current system architecture documentation:
|
||||
- Component breakdown (Go proxy, Python backend, static assets)
|
||||
- Request flow diagrams
|
||||
- API endpoints
|
||||
- External dependencies
|
||||
- Caching strategy
|
||||
- Configuration
|
||||
- Known issues
|
||||
|
||||
### [API_ENDPOINTS.md](API_ENDPOINTS.md)
|
||||
Complete API reference:
|
||||
- All endpoints with examples
|
||||
- Query parameters
|
||||
- Output formats
|
||||
- Language support
|
||||
- HTTP headers
|
||||
- Rate limits
|
||||
- Usage examples
|
||||
|
||||
### [DATA_FLOW.md](DATA_FLOW.md)
|
||||
Detailed request processing flow:
|
||||
- Step-by-step request handling
|
||||
- Location resolution process
|
||||
- Weather data fetching
|
||||
- Rendering pipeline
|
||||
- Caching mechanisms
|
||||
- Error handling
|
||||
- Performance optimizations
|
||||
|
||||
### [REWRITE_STRATEGY.md](REWRITE_STRATEGY.md)
|
||||
Comprehensive rewrite plan:
|
||||
- Goals and non-goals
|
||||
- Phase-by-phase breakdown (10-11 weeks)
|
||||
- Module organization
|
||||
- Testing strategy
|
||||
- Risk mitigation
|
||||
- Success criteria
|
||||
- Alternative approaches
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. **Read ARCHITECTURE.md** - Understand the current system
|
||||
2. **Read DATA_FLOW.md** - Understand how requests are processed
|
||||
3. **Read REWRITE_STRATEGY.md** - Understand the rewrite plan
|
||||
4. **Refer to API_ENDPOINTS.md** - When implementing specific endpoints
|
||||
|
||||
## Current System Summary
|
||||
|
||||
**Architecture:** Hybrid Python/Go
|
||||
- Go proxy (port 8082): LRU caching, prefetching
|
||||
- Python backend (port 8002): Weather logic, rendering
|
||||
- External binaries: wego (Go), pyphoon (Python)
|
||||
- External services: Geolocator (port 8004)
|
||||
|
||||
**Key Stats:**
|
||||
- ~5000 lines of Python
|
||||
- ~400 lines of Go
|
||||
- 54 languages supported
|
||||
- 12,800 entry LRU cache
|
||||
- 1000-2000s cache TTL
|
||||
- Zero unit tests (only integration tests)
|
||||
|
||||
**Main Challenges:**
|
||||
1. ANSI weather rendering (currently done by wego)
|
||||
2. PNG image generation (PIL + pyte)
|
||||
3. GeoIP database parsing (MaxMind format)
|
||||
4. 54 language translations
|
||||
5. Multiple output formats (ANSI, HTML, PNG, JSON, Prometheus)
|
||||
|
||||
## Recommended Approach
|
||||
|
||||
**Option A: Incremental (Recommended)**
|
||||
1. Replace Go proxy with Zig (2 weeks)
|
||||
2. Test and deploy
|
||||
3. Replace Python backend with Zig (8-9 weeks)
|
||||
4. Full cutover
|
||||
|
||||
**Option B: Full Rewrite**
|
||||
- All at once (10-11 weeks)
|
||||
- Higher risk, but cleaner result
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Review documentation
|
||||
2. Choose rewrite strategy
|
||||
3. Set up Zig project structure
|
||||
4. Begin implementation (start with HTTP server or Go proxy)
|
||||
|
||||
## Questions?
|
||||
|
||||
See REWRITE_STRATEGY.md "Questions to Answer" section for key decisions needed.
|
||||
|
|
|
|||
202
legacy/LICENSE
Normal file
202
legacy/LICENSE
Normal file
|
|
@ -0,0 +1,202 @@
|
|||
Apache License
|
||||
Version 2.0, January 2004
|
||||
http://www.apache.org/licenses/
|
||||
|
||||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
||||
|
||||
1. Definitions.
|
||||
|
||||
"License" shall mean the terms and conditions for use, reproduction,
|
||||
and distribution as defined by Sections 1 through 9 of this document.
|
||||
|
||||
"Licensor" shall mean the copyright owner or entity authorized by
|
||||
the copyright owner that is granting the License.
|
||||
|
||||
"Legal Entity" shall mean the union of the acting entity and all
|
||||
other entities that control, are controlled by, or are under common
|
||||
control with that entity. For the purposes of this definition,
|
||||
"control" means (i) the power, direct or indirect, to cause the
|
||||
direction or management of such entity, whether by contract or
|
||||
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
||||
outstanding shares, or (iii) beneficial ownership of such entity.
|
||||
|
||||
"You" (or "Your") shall mean an individual or Legal Entity
|
||||
exercising permissions granted by this License.
|
||||
|
||||
"Source" form shall mean the preferred form for making modifications,
|
||||
including but not limited to software source code, documentation
|
||||
source, and configuration files.
|
||||
|
||||
"Object" form shall mean any form resulting from mechanical
|
||||
transformation or translation of a Source form, including but
|
||||
not limited to compiled object code, generated documentation,
|
||||
and conversions to other media types.
|
||||
|
||||
"Work" shall mean the work of authorship, whether in Source or
|
||||
Object form, made available under the License, as indicated by a
|
||||
copyright notice that is included in or attached to the work
|
||||
(an example is provided in the Appendix below).
|
||||
|
||||
"Derivative Works" shall mean any work, whether in Source or Object
|
||||
form, that is based on (or derived from) the Work and for which the
|
||||
editorial revisions, annotations, elaborations, or other modifications
|
||||
represent, as a whole, an original work of authorship. For the purposes
|
||||
of this License, Derivative Works shall not include works that remain
|
||||
separable from, or merely link (or bind by name) to the interfaces of,
|
||||
the Work and Derivative Works thereof.
|
||||
|
||||
"Contribution" shall mean any work of authorship, including
|
||||
the original version of the Work and any modifications or additions
|
||||
to that Work or Derivative Works thereof, that is intentionally
|
||||
submitted to Licensor for inclusion in the Work by the copyright owner
|
||||
or by an individual or Legal Entity authorized to submit on behalf of
|
||||
the copyright owner. For the purposes of this definition, "submitted"
|
||||
means any form of electronic, verbal, or written communication sent
|
||||
to the Licensor or its representatives, including but not limited to
|
||||
communication on electronic mailing lists, source code control systems,
|
||||
and issue tracking systems that are managed by, or on behalf of, the
|
||||
Licensor for the purpose of discussing and improving the Work, but
|
||||
excluding communication that is conspicuously marked or otherwise
|
||||
designated in writing by the copyright owner as "Not a Contribution."
|
||||
|
||||
"Contributor" shall mean Licensor and any individual or Legal Entity
|
||||
on behalf of whom a Contribution has been received by Licensor and
|
||||
subsequently incorporated within the Work.
|
||||
|
||||
2. Grant of Copyright License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
copyright license to reproduce, prepare Derivative Works of,
|
||||
publicly display, publicly perform, sublicense, and distribute the
|
||||
Work and such Derivative Works in Source or Object form.
|
||||
|
||||
3. Grant of Patent License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
(except as stated in this section) patent license to make, have made,
|
||||
use, offer to sell, sell, import, and otherwise transfer the Work,
|
||||
where such license applies only to those patent claims licensable
|
||||
by such Contributor that are necessarily infringed by their
|
||||
Contribution(s) alone or by combination of their Contribution(s)
|
||||
with the Work to which such Contribution(s) was submitted. If You
|
||||
institute patent litigation against any entity (including a
|
||||
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
||||
or a Contribution incorporated within the Work constitutes direct
|
||||
or contributory patent infringement, then any patent licenses
|
||||
granted to You under this License for that Work shall terminate
|
||||
as of the date such litigation is filed.
|
||||
|
||||
4. Redistribution. You may reproduce and distribute copies of the
|
||||
Work or Derivative Works thereof in any medium, with or without
|
||||
modifications, and in Source or Object form, provided that You
|
||||
meet the following conditions:
|
||||
|
||||
(a) You must give any other recipients of the Work or
|
||||
Derivative Works a copy of this License; and
|
||||
|
||||
(b) You must cause any modified files to carry prominent notices
|
||||
stating that You changed the files; and
|
||||
|
||||
(c) You must retain, in the Source form of any Derivative Works
|
||||
that You distribute, all copyright, patent, trademark, and
|
||||
attribution notices from the Source form of the Work,
|
||||
excluding those notices that do not pertain to any part of
|
||||
the Derivative Works; and
|
||||
|
||||
(d) If the Work includes a "NOTICE" text file as part of its
|
||||
distribution, then any Derivative Works that You distribute must
|
||||
include a readable copy of the attribution notices contained
|
||||
within such NOTICE file, excluding those notices that do not
|
||||
pertain to any part of the Derivative Works, in at least one
|
||||
of the following places: within a NOTICE text file distributed
|
||||
as part of the Derivative Works; within the Source form or
|
||||
documentation, if provided along with the Derivative Works; or,
|
||||
within a display generated by the Derivative Works, if and
|
||||
wherever such third-party notices normally appear. The contents
|
||||
of the NOTICE file are for informational purposes only and
|
||||
do not modify the License. You may add Your own attribution
|
||||
notices within Derivative Works that You distribute, alongside
|
||||
or as an addendum to the NOTICE text from the Work, provided
|
||||
that such additional attribution notices cannot be construed
|
||||
as modifying the License.
|
||||
|
||||
You may add Your own copyright statement to Your modifications and
|
||||
may provide additional or different license terms and conditions
|
||||
for use, reproduction, or distribution of Your modifications, or
|
||||
for any such Derivative Works as a whole, provided Your use,
|
||||
reproduction, and distribution of the Work otherwise complies with
|
||||
the conditions stated in this License.
|
||||
|
||||
5. Submission of Contributions. Unless You explicitly state otherwise,
|
||||
any Contribution intentionally submitted for inclusion in the Work
|
||||
by You to the Licensor shall be under the terms and conditions of
|
||||
this License, without any additional terms or conditions.
|
||||
Notwithstanding the above, nothing herein shall supersede or modify
|
||||
the terms of any separate license agreement you may have executed
|
||||
with Licensor regarding such Contributions.
|
||||
|
||||
6. Trademarks. This License does not grant permission to use the trade
|
||||
names, trademarks, service marks, or product names of the Licensor,
|
||||
except as required for reasonable and customary use in describing the
|
||||
origin of the Work and reproducing the content of the NOTICE file.
|
||||
|
||||
7. Disclaimer of Warranty. Unless required by applicable law or
|
||||
agreed to in writing, Licensor provides the Work (and each
|
||||
Contributor provides its Contributions) on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
implied, including, without limitation, any warranties or conditions
|
||||
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
||||
PARTICULAR PURPOSE. You are solely responsible for determining the
|
||||
appropriateness of using or redistributing the Work and assume any
|
||||
risks associated with Your exercise of permissions under this License.
|
||||
|
||||
8. Limitation of Liability. In no event and under no legal theory,
|
||||
whether in tort (including negligence), contract, or otherwise,
|
||||
unless required by applicable law (such as deliberate and grossly
|
||||
negligent acts) or agreed to in writing, shall any Contributor be
|
||||
liable to You for damages, including any direct, indirect, special,
|
||||
incidental, or consequential damages of any character arising as a
|
||||
result of this License or out of the use or inability to use the
|
||||
Work (including but not limited to damages for loss of goodwill,
|
||||
work stoppage, computer failure or malfunction, or any and all
|
||||
other commercial damages or losses), even if such Contributor
|
||||
has been advised of the possibility of such damages.
|
||||
|
||||
9. Accepting Warranty or Additional Liability. While redistributing
|
||||
the Work or Derivative Works thereof, You may choose to offer,
|
||||
and charge a fee for, acceptance of support, warranty, indemnity,
|
||||
or other liability obligations and/or rights consistent with this
|
||||
License. However, in accepting such obligations, You may act only
|
||||
on Your own behalf and on Your sole responsibility, not on behalf
|
||||
of any other Contributor, and only if You agree to indemnify,
|
||||
defend, and hold each Contributor harmless for any liability
|
||||
incurred by, or claims asserted against, such Contributor by reason
|
||||
of your accepting any such warranty or additional liability.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
APPENDIX: How to apply the Apache License to your work.
|
||||
|
||||
To apply the Apache License to your work, attach the following
|
||||
boilerplate notice, with the fields enclosed by brackets "{}"
|
||||
replaced with your own identifying information. (Don't include
|
||||
the brackets!) The text should be enclosed in the appropriate
|
||||
comment syntax for the file format. We also recommend that a
|
||||
file or class name and description of purpose be included on the
|
||||
same "printed page" as the copyright notice for easier
|
||||
identification within third-party archives.
|
||||
|
||||
Copyright {yyyy} {name of copyright owner}
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
|
||||
612
legacy/README.md
Normal file
612
legacy/README.md
Normal file
|
|
@ -0,0 +1,612 @@
|
|||
*wttr.in — the right way to check the weather!*
|
||||
|
||||
wttr.in is a console-oriented weather forecast service that supports various information
|
||||
representation methods like terminal-oriented ANSI-sequences for console HTTP clients
|
||||
(curl, httpie, or wget), HTML for web browsers, or PNG for graphical viewers.
|
||||
|
||||
wttr.in uses [wego](http://github.com/schachmat/wego) for visualization
|
||||
and various data sources for weather forecast information.
|
||||
|
||||
You can see it running here: [wttr.in](http://wttr.in).
|
||||
|
||||
## Usage
|
||||
|
||||
You can access the service from a shell or from a Web browser like this:
|
||||
|
||||
$ curl wttr.in
|
||||
Weather for City: Paris, France
|
||||
|
||||
\ / Clear
|
||||
.-. 10 – 11 °C
|
||||
― ( ) ― ↑ 11 km/h
|
||||
`-’ 10 km
|
||||
/ \ 0.0 mm
|
||||
|
||||
|
||||
Here is an actual weather report for your location (it's live!):
|
||||
|
||||
|
||||
|
||||
(It's not your actual location - GitHub's CDN hides your real IP address with its own IP address,
|
||||
but it's still a live weather report in your language.)
|
||||
|
||||
Or in PowerShell:
|
||||
|
||||
```PowerShell
|
||||
Invoke-RestMethod http://wttr.in
|
||||
```
|
||||
|
||||
Want to get the weather information for a specific location? You can add the desired location to the URL in your
|
||||
request like this:
|
||||
|
||||
$ curl wttr.in/London
|
||||
$ curl wttr.in/Moscow
|
||||
$ curl wttr.in/Salt+Lake+City
|
||||
|
||||
If you omit the location name, you will get the report for your current location based on your IP address.
|
||||
|
||||
Use 3-letter airport codes in order to get the weather information at a certain airport:
|
||||
|
||||
$ curl wttr.in/muc # Weather for IATA: muc, Munich International Airport, Germany
|
||||
$ curl wttr.in/ham # Weather for IATA: ham, Hamburg Airport, Germany
|
||||
|
||||
Let's say you'd like to get the weather for a geographical location other than a town or city - maybe an attraction
|
||||
in a city, a mountain name, or some special location. Add the character `~` before the name to look up that special
|
||||
location name before the weather is then retrieved:
|
||||
|
||||
$ curl wttr.in/~Vostok+Station
|
||||
$ curl wttr.in/~Eiffel+Tower
|
||||
$ curl wttr.in/~Kilimanjaro
|
||||
|
||||
For these examples, you'll see a line below the weather forecast output that shows the geolocation
|
||||
results of looking up the location:
|
||||
|
||||
Location: Vostok Station, станция Восток, AAT, Antarctica [-78.4642714,106.8364678]
|
||||
Location: Tour Eiffel, 5, Avenue Anatole France, Gros-Caillou, 7e, Paris, Île-de-France, 75007, France [48.8582602,2.29449905432]
|
||||
Location: Kilimanjaro, Northern, Tanzania [-3.4762789,37.3872648]
|
||||
|
||||
You can also use IP-addresses (direct) or domain names (prefixed with `@`) to specify a location:
|
||||
|
||||
$ curl wttr.in/@github.com
|
||||
$ curl wttr.in/@msu.ru
|
||||
|
||||
To get detailed information online, you can access the [/:help](http://wttr.in/:help) page:
|
||||
|
||||
$ curl wttr.in/:help
|
||||
|
||||
|
||||
### Weather Units
|
||||
|
||||
By default the USCS units are used for the queries from the USA and the metric system for the rest of the world.
|
||||
You can override this behavior by adding `?u` or `?m` to a URL like this:
|
||||
|
||||
$ curl wttr.in/Amsterdam?u
|
||||
$ curl wttr.in/Amsterdam?m
|
||||
|
||||
## Supported output formats and views
|
||||
|
||||
wttr.in currently supports five output formats:
|
||||
|
||||
* ANSI for the terminal;
|
||||
* Plain-text for the terminal and scripts;
|
||||
* HTML for the browser;
|
||||
* PNG for the graphical viewers;
|
||||
* JSON for scripts and APIs;
|
||||
* Prometheus metrics for scripts and APIs.
|
||||
|
||||
The ANSI and HTML formats are selected basing on the User-Agent string.
|
||||
The PNG format can be forced by adding `.png` to the end of the query:
|
||||
|
||||
$ wget wttr.in/Paris.png
|
||||
|
||||
You can use all of the options with the PNG-format like in an URL, but you have
|
||||
to separate them with `_` instead of `?` and `&`:
|
||||
|
||||
$ wget wttr.in/Paris_0tqp_lang=fr.png
|
||||
|
||||
Useful options for the PNG format:
|
||||
|
||||
* `t` for transparency (`transparency=150`);
|
||||
* transparency=0..255 for a custom transparency level.
|
||||
|
||||
Transparency is a useful feature when weather PNGs are used to add weather data to pictures:
|
||||
|
||||
$ convert source.jpg <( curl wttr.in/Oymyakon_tqp0.png ) -geometry +50+50 -composite target.jpg
|
||||
|
||||
In this example:
|
||||
|
||||
* `source.jpg` - source file;
|
||||
* `target.jpg` - target file;
|
||||
* `Oymyakon` - name of the location;
|
||||
* `tqp0` - options (recommended).
|
||||
|
||||
|
||||
|
||||
You can embed a special wttr.in widget, that displays the weather condition for the current or a selected location, into a HTML page using the [wttr-switcher](https://github.com/midzer/wttr-switcher). That is how it looks like: [wttr-switcher-example](https://midzer.github.io/wttr-switcher/) or on a real world web site: https://feuerwehr-eisolzried.de/.
|
||||
|
||||
|
||||
|
||||
## One-line output
|
||||
|
||||
For one-line output format, specify additional URL parameter `format`:
|
||||
|
||||
```
|
||||
$ curl wttr.in/Nuremberg?format=3
|
||||
Nuremberg: 🌦 +11⁰C
|
||||
```
|
||||
|
||||
Available preconfigured formats: 1, 2, 3, 4 and the custom format using the percent notation (see below).
|
||||
|
||||
You can specify multiple locations separated with `:` (for repeating queries):
|
||||
|
||||
```
|
||||
$ curl wttr.in/Nuremberg:Hamburg:Berlin?format=3
|
||||
Nuremberg: 🌦 +11⁰C
|
||||
```
|
||||
Or to process all this queries at once:
|
||||
|
||||
```
|
||||
$ curl -s 'wttr.in/{Nuremberg,Hamburg,Berlin}?format=3'
|
||||
Nuremberg: 🌦 +11⁰C
|
||||
Hamburg: 🌦 +8⁰C
|
||||
Berlin: 🌦 +8⁰C
|
||||
```
|
||||
|
||||
To specify your own custom output format, use the special `%`-notation:
|
||||
|
||||
```
|
||||
c Weather condition,
|
||||
C Weather condition textual name,
|
||||
h Humidity,
|
||||
t Temperature (Actual),
|
||||
f Temperature (Feels Like),
|
||||
w Wind,
|
||||
l Location,
|
||||
m Moonphase 🌑🌒🌓🌔🌕🌖🌗🌘,
|
||||
M Moonday,
|
||||
p precipitation (mm),
|
||||
o Probability of Precipitation,
|
||||
P pressure (hPa),
|
||||
|
||||
D Dawn*,
|
||||
S Sunrise*,
|
||||
z Zenith*,
|
||||
s Sunset*,
|
||||
d Dusk*.
|
||||
|
||||
(*times are shown in the local timezone)
|
||||
```
|
||||
|
||||
So, these two calls are the same:
|
||||
|
||||
```
|
||||
$ curl wttr.in/London?format=3
|
||||
London: ⛅️ +7⁰C
|
||||
$ curl wttr.in/London?format="%l:+%c+%t\n"
|
||||
London: ⛅️ +7⁰C
|
||||
```
|
||||
Keep in mind, that when using in `tmux.conf`, you have to escape `%` with `%`, i.e. write there `%%` instead of `%`.
|
||||
|
||||
In programs, that are querying the service automatically (such as tmux), it is better to use some reasonable update interval. In tmux, you can configure it with `status-interval`.
|
||||
|
||||
If several, `:` separated locations, are specified in the query, specify update period
|
||||
as an additional query parameter `period=`:
|
||||
```
|
||||
set -g status-interval 60
|
||||
WEATHER='#(curl -s wttr.in/London:Stockholm:Moscow\?format\="%%l:+%%c%%20%%t%%60%%w&period=60")'
|
||||
set -g status-right "$WEATHER ..."
|
||||
```
|
||||
|
||||
|
||||
To see emojis in terminal, you need:
|
||||
|
||||
1. Terminal support for emojis (was added to Cairo 1.15.8);
|
||||
2. Font with emojis support.
|
||||
|
||||
For the Emoji font, we recommend *Noto Color Emoji*, and a good alternative option would be the *Emoji One* font;
|
||||
both of them support all necessary emoji glyphs.
|
||||
|
||||
Font configuration:
|
||||
|
||||
```xml
|
||||
$ cat ~/.config/fontconfig/fonts.conf
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
|
||||
<fontconfig>
|
||||
<alias>
|
||||
<family>serif</family>
|
||||
<prefer>
|
||||
<family>Noto Color Emoji</family>
|
||||
</prefer>
|
||||
</alias>
|
||||
<alias>
|
||||
<family>sans-serif</family>
|
||||
<prefer>
|
||||
<family>Noto Color Emoji</family>
|
||||
</prefer>
|
||||
</alias>
|
||||
<alias>
|
||||
<family>monospace</family>
|
||||
<prefer>
|
||||
<family>Noto Color Emoji</family>
|
||||
</prefer>
|
||||
</alias>
|
||||
</fontconfig>
|
||||
```
|
||||
|
||||
(to apply the configuration, run `fc-cache -f -v`)
|
||||
|
||||
## Data-rich output format
|
||||
|
||||
In the experimental data-rich output format, that is available under the view code `v2`,
|
||||
a lot of additional weather and astronomical information is available:
|
||||
|
||||
* Temperature, and precepetation changes forecast throughout the days;
|
||||
* Moonphase for today and the next three days;
|
||||
* The current weather condition, temperature, humidity, windspeed and direction, pressure;
|
||||
* Timezone;
|
||||
* Dawn, sunrise, noon, sunset, dusk time for he selected location;
|
||||
* Precise geographical coordinates for the selected location.
|
||||
|
||||
```
|
||||
$ curl v2.wttr.in/München
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
$ curl wttr.in/München?format=v2
|
||||
```
|
||||
|
||||
or, if you prefer Nerd Fonts instead of Emoji, `v2d` (day) or `v2n` (night):
|
||||
|
||||
```
|
||||
$ curl v2d.wttr.in/München
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
(The mode is experimental, and it has several limitations currently:
|
||||
|
||||
* It works only in terminal;
|
||||
* Only English is supported).
|
||||
|
||||
Currently, you need some tweaks for some terminals, to get the best possible visualization.
|
||||
|
||||
### URXVT
|
||||
|
||||
Depending on your configuration you might be taking all steps, or only a few. URXVT currently doesn't support emoji related fonts, but we can get almost the same effect using *Font-Symbola*. So add to your `.Xresources` file the following line:
|
||||
```
|
||||
xft:symbola:size=10:minspace=False
|
||||
```
|
||||
You can add it _after_ your preferred font and it will only show up when required.
|
||||
Then, if you see or feel like you're having spacing issues, add this: `URxvt.letterSpace: 0`
|
||||
For some reason URXVT sometimes stops deciding right the word spacing and we need to force it this way.
|
||||
|
||||
The result, should look like:
|
||||
|
||||
|
||||
|
||||
## Different output formats
|
||||
|
||||
### JSON output
|
||||
|
||||
The JSON format is a feature providing access to *wttr.in* data through an easy-to-parse format, without requiring the user to create a complex script to reinterpret wttr.in's graphical output.
|
||||
|
||||
To fetch information in JSON format, use the following syntax:
|
||||
|
||||
$ curl wttr.in/Detroit?format=j1
|
||||
|
||||
This will fetch information on the Detroit region in JSON format. The j1 format code is used to allow for the use of other layouts for the JSON output.
|
||||
|
||||
The result will look something like the following:
|
||||
```json
|
||||
{
|
||||
"current_condition": [
|
||||
{
|
||||
"FeelsLikeC": "25",
|
||||
"FeelsLikeF": "76",
|
||||
"cloudcover": "100",
|
||||
"humidity": "76",
|
||||
"observation_time": "04:08 PM",
|
||||
"precipMM": "0.2",
|
||||
"pressure": "1019",
|
||||
"temp_C": "22",
|
||||
"temp_F": "72",
|
||||
"uvIndex": 5,
|
||||
"visibility": "16",
|
||||
"weatherCode": "122",
|
||||
"weatherDesc": [
|
||||
{
|
||||
"value": "Overcast"
|
||||
}
|
||||
],
|
||||
"weatherIconUrl": [
|
||||
{
|
||||
"value": ""
|
||||
}
|
||||
],
|
||||
"winddir16Point": "NNE",
|
||||
"winddirDegree": "20",
|
||||
"windspeedKmph": "7",
|
||||
"windspeedMiles": "4"
|
||||
}
|
||||
],
|
||||
...
|
||||
```
|
||||
|
||||
Most of these values are self-explanatory, aside from `weatherCode`. The `weatherCode` is an enumeration which you can find at either [the WorldWeatherOnline website](https://www.worldweatheronline.com/developer/api/docs/weather-icons.aspx) or [in the wttr.in source code](https://github.com/chubin/wttr.in/blob/master/lib/constants.py).
|
||||
|
||||
### Prometheus Metrics Output
|
||||
|
||||
The [Prometheus](https://github.com/prometheus/prometheus) Metrics format is a feature providing access to *wttr.in* data through an easy-to-parse format for monitoring systems, without requiring the user to create a complex script to reinterpret wttr.in's graphical output.
|
||||
|
||||
To fetch information in Prometheus format, use the following syntax:
|
||||
|
||||
$ curl wttr.in/Detroit?format=p1
|
||||
|
||||
This will fetch information on the Detroit region in Prometheus Metrics format. The `p1` format code is used to allow for the use of other layouts for the Prometheus Metrics output.
|
||||
|
||||
A possible configuration for Prometheus could look like this:
|
||||
|
||||
```yaml
|
||||
- job_name: 'wttr_in_detroit'
|
||||
static_configs:
|
||||
- targets: ['wttr.in']
|
||||
metrics_path: '/Detroit'
|
||||
params:
|
||||
format: ['p1']
|
||||
```
|
||||
|
||||
The result will look something like the following:
|
||||
|
||||
|
||||
# HELP temperature_feels_like_celsius Feels Like Temperature in Celsius
|
||||
temperature_feels_like_celsius{forecast="current"} 7
|
||||
# HELP temperature_feels_like_fahrenheit Feels Like Temperature in Fahrenheit
|
||||
temperature_feels_like_fahrenheit{forecast="current"} 45
|
||||
[truncated]
|
||||
...
|
||||
|
||||
|
||||
## Moon phases
|
||||
|
||||
wttr.in can also be used to check the phase of the Moon. This example shows how to see the current Moon phase
|
||||
in the full-output mode:
|
||||
|
||||
$ curl wttr.in/Moon
|
||||
|
||||
Get the Moon phase for a particular date by adding `@YYYY-MM-DD`:
|
||||
|
||||
$ curl wttr.in/Moon@2016-12-25
|
||||
|
||||
The Moon phase information uses [pyphoon](https://github.com/chubin/pyphoon) as its backend.
|
||||
|
||||
To get the moon phase information in the online mode, use `%m`:
|
||||
|
||||
$ curl wttr.in/London?format=%m
|
||||
🌖
|
||||
|
||||
Keep in mind that the Unicode representation of moonphases suffers 2 caveats:
|
||||
|
||||
- With some fonts, the representation `🌘` is ambiguous, for it either seem
|
||||
almost-shadowed or almost-lit, depending on whether your terminal is in
|
||||
light mode or dark mode. Relying on colored fonts like `noto-fonts` works
|
||||
around this problem.
|
||||
|
||||
- The representation `🌘` is also ambiguous, for it means "last quarter" in
|
||||
northern hemisphere, but "first quarter" in souther hemisphere. It also means
|
||||
nothing in tropical zones. This is a limitation that
|
||||
[Unicode](https://www.unicode.org/L2/L2017/17304-moon-var.pdf) is aware about.
|
||||
But it has not been worked around at `wttr.in` yet.
|
||||
|
||||
See #247, #364 for the corresponding tracking issues,
|
||||
and [pyphoon#1](https://github.com/chubin/pyphoon/issues/1) for pyphoon. Any help is welcome.
|
||||
|
||||
## Internationalization and localization
|
||||
|
||||
wttr.in supports multilingual locations names that can be specified in any language in the world
|
||||
(it may be surprising, but many locations in the world don't have an English name).
|
||||
|
||||
The query string should be specified in Unicode (hex-encoded or not). Spaces in the query string
|
||||
must be replaced with `+`:
|
||||
|
||||
$ curl wttr.in/станция+Восток
|
||||
Weather report: станция Восток
|
||||
|
||||
Overcast
|
||||
.--. -65 – -47 °C
|
||||
.-( ). ↑ 23 km/h
|
||||
(___.__)__) 15 km
|
||||
0.0 mm
|
||||
|
||||
The language used for the output (except the location name) does not depend on the input language
|
||||
and it is either English (by default) or the preferred language of the browser (if the query
|
||||
was issued from a browser) that is specified in the query headers (`Accept-Language`).
|
||||
|
||||
The language can be set explicitly when using console clients by using command-line options like this:
|
||||
|
||||
curl -H "Accept-Language: fr" wttr.in
|
||||
http GET wttr.in Accept-Language:ru
|
||||
|
||||
The preferred language can be forced using the `lang` option:
|
||||
|
||||
$ curl wttr.in/Berlin?lang=de
|
||||
|
||||
The third option is to choose the language using the DNS name used in the query:
|
||||
|
||||
$ curl de.wttr.in/Berlin
|
||||
|
||||
wttr.in is currently translated into 54 languages, and the number of supported languages is constantly growing.
|
||||
|
||||
See [/:translation](http://wttr.in/:translation) to learn more about the translation process,
|
||||
to see the list of supported languages and contributors, or to know how you can help to translate wttr.in
|
||||
in your language.
|
||||
|
||||
|
||||
|
||||
## Windows Users
|
||||
|
||||
There are currently two Windows related issues that prevent the examples found on this page from working exactly as expected out of the box. Until Microsoft fixes the issues, there are a few workarounds. To circumvent both issues you may use a shell such as `bash` on the [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/install-win10) or read on for alternative solutions.
|
||||
|
||||
### Garbage characters in the output
|
||||
There is a limitation of the current Win32 version of `curl`. Until the [Win32 curl issue](https://github.com/chubin/wttr.in/issues/18#issuecomment-474145551) is resolved and rolled out in a future Windows release, it is recommended that you use Powershell’s `Invoke-Web-Request` command instead:
|
||||
- `(Invoke-WebRequest http://wttr.in).Content`
|
||||
|
||||
### Missing or double wide diagonal wind direction characters
|
||||
The second issue is regarding the width of the diagonal arrow glyphs that some Windows Terminal Applications such as the default `conhost.exe` use. At the time of writing this, `ConEmu.exe`, `ConEmu64.exe` and Terminal Applications built on top of ConEmu such as Cmder (`cmder.exe`) use these double-wide glyphs by default. The result is the same with all of these programs, either a missing character for certain wind directions or a broken table in the output or both. Some third-party Terminal Applications have addressed the wind direction glyph issue but that fix depends on the font and the Terminal Application you are using.
|
||||
One way to display the diagonal wind direction glyphs in your Terminal Application is to use [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701?activetab=pivot:overviewtab) which is currently available in the [Microsoft Store](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701?activetab=pivot:overviewtab). Windows Terminal is currently a preview release and will be rolled out as the default Terminal Application in an upcoming release. If your output is still skewed after using Windows Terminal then try maximizing the terminal window.
|
||||
Another way you can display the diagonal wind direction is to swap out the problematic characters with forward and backward slashes as shown [here](https://github.com/chubin/wttr.in/issues/18#issuecomment-405640892).
|
||||
|
||||
## Installation
|
||||
|
||||
To install the application:
|
||||
|
||||
1. Install external dependencies
|
||||
2. Install Python dependencies used by the service
|
||||
3. Configure IP2Location (optional)
|
||||
4. Get a WorldWeatherOnline API and configure wego
|
||||
5. Configure wttr.in
|
||||
6. Configure the HTTP-frontend service
|
||||
|
||||
### Install external dependencies
|
||||
|
||||
wttr.in has the following external dependencies:
|
||||
|
||||
* [golang](https://golang.org/doc/install), wego dependency
|
||||
* [wego](https://github.com/schachmat/wego), weather client for terminal
|
||||
|
||||
After you install [golang](https://golang.org/doc/install), install `wego`:
|
||||
|
||||
$ go get -u github.com/schachmat/wego
|
||||
$ go install github.com/schachmat/wego
|
||||
|
||||
### Install Python dependencies
|
||||
|
||||
Python requirements:
|
||||
|
||||
* Flask
|
||||
* geoip2
|
||||
* geopy
|
||||
* requests
|
||||
* gevent
|
||||
|
||||
If you want to get weather reports as PNG files, you'll also need to install:
|
||||
|
||||
* PIL
|
||||
* pyte (>=0.6)
|
||||
* necessary fonts
|
||||
|
||||
You can install most of them using `pip`.
|
||||
|
||||
Some python package use LLVM, so install it first:
|
||||
|
||||
$ apt-get install llvm-7 llvm-7-dev
|
||||
|
||||
If `virtualenv` is used:
|
||||
|
||||
$ virtualenv -p python3 ve
|
||||
$ ve/bin/pip3 install -r requirements.txt
|
||||
$ ve/bin/python3 bin/srv.py
|
||||
|
||||
Also, you need to install the geoip2 database.
|
||||
You can use a free database GeoLite2 that can be downloaded from (http://dev.maxmind.com/geoip/geoip2/geolite2/).
|
||||
|
||||
### Configure IP2Location (optional)
|
||||
|
||||
If you want to use the IP2location service for IP-addresses that are not covered by GeoLite2,
|
||||
you have to obtain a API key of that service, and after that save into the `~/.ip2location.key` file:
|
||||
|
||||
```
|
||||
$ echo 'YOUR_IP2LOCATION_KEY' > ~/.ip2location.key
|
||||
```
|
||||
|
||||
If you don't have this file, the service will be silently skipped (it is not a big problem,
|
||||
because the MaxMind database is pretty good).
|
||||
|
||||
### Installation with Docker
|
||||
|
||||
* Install Docker
|
||||
* Build Docker Image
|
||||
* These files should be mounted by the user at runtime:
|
||||
|
||||
```
|
||||
/root/.wegorc
|
||||
/root/.ip2location.key (optional)
|
||||
/app/airports.dat
|
||||
/app/GeoLite2-City.mmdb
|
||||
```
|
||||
|
||||
### Get a WorldWeatherOnline key and configure wego
|
||||
|
||||
To get a WorldWeatherOnline API key, you must register here:
|
||||
|
||||
https://developer.worldweatheronline.com/auth/register
|
||||
|
||||
After you have a WorldWeatherOnline key, you can save it into the
|
||||
WWO key file: `~/.wwo.key`
|
||||
|
||||
Also, you have to specify the key in the `wego` configuration:
|
||||
|
||||
```json
|
||||
$ cat ~/.wegorc
|
||||
{
|
||||
"APIKey": "00XXXXXXXXXXXXXXXXXXXXXXXXXXX",
|
||||
"City": "London",
|
||||
"Numdays": 3,
|
||||
"Imperial": false,
|
||||
"Lang": "en"
|
||||
}
|
||||
```
|
||||
|
||||
The `City` parameter in `~/.wegorc` is ignored.
|
||||
|
||||
### Configure wttr.in
|
||||
|
||||
Configure the following environment variables that define the path to the local `wttr.in`
|
||||
installation, to the GeoLite database, and to the `wego` installation. For example:
|
||||
|
||||
```bash
|
||||
export WTTR_MYDIR="/home/igor/wttr.in"
|
||||
export WTTR_GEOLITE="/home/igor/wttr.in/GeoLite2-City.mmdb"
|
||||
export WTTR_WEGO="/home/igor/go/bin/wego"
|
||||
export WTTR_LISTEN_HOST="0.0.0.0"
|
||||
export WTTR_LISTEN_PORT="8002"
|
||||
```
|
||||
|
||||
|
||||
### Configure the HTTP-frontend service
|
||||
|
||||
It's recommended that you also configure the web server that will be used to access the service:
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen [::]:80;
|
||||
server_name wttr.in *.wttr.in;
|
||||
access_log /var/log/nginx/wttr.in-access.log main;
|
||||
error_log /var/log/nginx/wttr.in-error.log;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:8002;
|
||||
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $remote_addr;
|
||||
|
||||
client_max_body_size 10m;
|
||||
client_body_buffer_size 128k;
|
||||
|
||||
proxy_connect_timeout 90;
|
||||
proxy_send_timeout 90;
|
||||
proxy_read_timeout 90;
|
||||
|
||||
proxy_buffer_size 4k;
|
||||
proxy_buffers 4 32k;
|
||||
proxy_busy_buffers_size 64k;
|
||||
proxy_temp_file_write_size 64k;
|
||||
|
||||
expires off;
|
||||
}
|
||||
}
|
||||
```
|
||||
53
legacy/overflowed.md
Normal file
53
legacy/overflowed.md
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
## Remaining Components
|
||||
|
||||
### 1. Location Resolver (Critical)
|
||||
Currently we only support coordinates. Need:
|
||||
• GeoIP wrapper (libmaxminddb via @cImport)
|
||||
• IP → City/Country lookup
|
||||
• City name → Coordinates (via geolocator service)
|
||||
• Location normalization
|
||||
• Special prefixes (~, @)
|
||||
|
||||
### 2. Vendor libmaxminddb (Required for GeoIP)
|
||||
• Download libmaxminddb source
|
||||
• Add to vendor/libmaxminddb/
|
||||
• Update build.zig to compile it
|
||||
• Wrap in clean Zig interface
|
||||
|
||||
### 3. Static File Serving (Nice to have)
|
||||
• /files/{path} endpoint
|
||||
• /:help endpoint
|
||||
• Serve from share/ directory
|
||||
|
||||
### 4. Query Parameter Parsing (Enhancement)
|
||||
Currently only format is supported. Need:
|
||||
• Single-letter options (T, n, m, u, etc.)
|
||||
• Days parameter (0-3)
|
||||
• Imperial/metric units
|
||||
|
||||
### 5. Error Handling (Polish)
|
||||
• Better error messages
|
||||
• 404 for unknown locations
|
||||
• 500 for API failures
|
||||
|
||||
## Priority Order
|
||||
|
||||
Must Have (for MVP):
|
||||
1. Location Resolver with GeoIP - Without this, only coordinates work
|
||||
2. Vendor libmaxminddb - Required for #1
|
||||
|
||||
Should Have:
|
||||
3. Query parameter parsing - Makes it feature-complete
|
||||
4. Static file serving - For help pages
|
||||
|
||||
Nice to Have:
|
||||
5. Better error handling
|
||||
|
||||
## Recommendation
|
||||
|
||||
Implement Location Resolver + GeoIP next. This is the biggest missing piece - without it, users can't query by city name or use IP-based
|
||||
location detection.
|
||||
|
||||
Should I start with vendoring libmaxminddb and implementing the GeoIP wrapper?
|
||||
|
||||
[default] > yes. I'm concerned you're going to screw this up. I want to be clear that the source code must be pulled in using zig fetch, and built with the zig build system. There is a reasonable prior art example at ~/shared/alexa-youre-fired/0-alsa-lib/
|
||||
|
Before Width: | Height: | Size: 2.3 KiB After Width: | Height: | Size: 2.3 KiB |
|
Before Width: | Height: | Size: 1.9 KiB After Width: | Height: | Size: 1.9 KiB |
|
Before Width: | Height: | Size: 2.4 KiB After Width: | Height: | Size: 2.4 KiB |
|
Before Width: | Height: | Size: 2.8 KiB After Width: | Height: | Size: 2.8 KiB |
|
Before Width: | Height: | Size: 1.8 KiB After Width: | Height: | Size: 1.8 KiB |
|
Before Width: | Height: | Size: 3.3 KiB After Width: | Height: | Size: 3.3 KiB |
|
Before Width: | Height: | Size: 1.2 KiB After Width: | Height: | Size: 1.2 KiB |
|
Before Width: | Height: | Size: 2.4 KiB After Width: | Height: | Size: 2.4 KiB |
|
Before Width: | Height: | Size: 2.2 KiB After Width: | Height: | Size: 2.2 KiB |
|
Before Width: | Height: | Size: 2.5 KiB After Width: | Height: | Size: 2.5 KiB |
|
Before Width: | Height: | Size: 2.4 KiB After Width: | Height: | Size: 2.4 KiB |
|
Before Width: | Height: | Size: 2.5 KiB After Width: | Height: | Size: 2.5 KiB |
|
Before Width: | Height: | Size: 2.2 KiB After Width: | Height: | Size: 2.2 KiB |
|
Before Width: | Height: | Size: 2.4 KiB After Width: | Height: | Size: 2.4 KiB |
|
Before Width: | Height: | Size: 2.8 KiB After Width: | Height: | Size: 2.8 KiB |
|
Before Width: | Height: | Size: 2.6 KiB After Width: | Height: | Size: 2.6 KiB |
|
Before Width: | Height: | Size: 2.7 KiB After Width: | Height: | Size: 2.7 KiB |
|
Before Width: | Height: | Size: 2.1 KiB After Width: | Height: | Size: 2.1 KiB |
|
Before Width: | Height: | Size: 725 B After Width: | Height: | Size: 725 B |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
|
Before Width: | Height: | Size: 9.4 KiB After Width: | Height: | Size: 9.4 KiB |
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue