Public
Script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
import { blob } from "https://esm.town/v/std/blob?v=12";
import { nominatimSearch } from "https://esm.town/v/stevekrouse/nominatimSearch";
import { nowcastPMAQISeverity } from "https://esm.town/v/stevekrouse/nowcastPMAQISeverity";
import { openAQLocation as findOpenAQLocation } from "https://esm.town/v/stevekrouse/openAQLocation";
import { openAqNowcastAQI } from "https://esm.town/v/stevekrouse/openAqNowcastAQI";
const cacheKey = location => "easyAQI_locationID_cache_" + encodeURIComponent(location);
export async function easyAQI({ location }: {
location: string;
}) {
let openAQLocation = await blob.getJSON(cacheKey(location));
if (!openAQLocation) {
const [geo] = await nominatimSearch({
q: location,
});
console.log("Searching for openAQ stations near: " + geo.display_name);
openAQLocation = await findOpenAQLocation({
lat: parseFloat(geo.lat),
lon: parseFloat(geo.lon),
});
await blob.setJSON(cacheKey(location), { name: openAQLocation.name, id: openAQLocation.id });
}
console.log("Pulling pm2.5 from station: " + openAQLocation.name);
const aqi = await openAqNowcastAQI({
location_id: openAQLocation.id,
});
return { aqi, severity: nowcastPMAQISeverity(aqi) };
}
Val Town is a social website to write and deploy JavaScript.
Build APIs and schedule functions from your browser.
v5 was merged from the PR "Add a cache for the openai location" by stevekrouse
May 30, 2024
Doing a triple-lookup for every run ("human-friendly" location name to lat/lng, lat/lng to list of stations, individual station data) is a decent amount of overhead, and more possibilities for an individual request to fail.
I'd recommend using val.town's SQLite feature to create a table matching
LOCATION
values to "openAQLocation IDs". Thus, if the location never changes for a user (likely), the first two queries can be skipped most runs.Great idea! What do you think of this implementation? https://www.val.town/pulls/bf6db21e-1d03-11ef-a060-cab58f78796a
That looks wonderful! Since your example "location" value has spaces in it, likely most users will follow suit. That means your blob cache key will have underscores for the first part of the key, and then spaces for the last half. That's not too big a deal, but you may want to do some light sanitizing on the user's input to make it consistent (all lower-case, all whitespaces to underscores, all non-alphanumeric characters removed) and a little more human-friendly if a user uses the "admin" tools to browse their blob objects.
great idea!
done and merged :)