nip/weather-data

[samthomson]

DRAFT & WIP

I've started playing around with building weather stations. I will keep building / refining (with others - you?) the next months. It makes sense to be to have one kind for the weather station and one kind for each weather station reading. (A list of weather stations eg I operate, could also be handy - put that doesn't need to be reinvented here). Wisdom / collaboration is welcome, and appreciated 🙏 You can see some data being consumed here (from a proto kind): https://weather.shakespeare.wtf

[vitorpamplona]

Move the json in content to tags to get rid of yet another parser

[derekross]

i look forward to having weather stations all over the world. you should also link the PoC website.

[samthomson]

thanks @vitorpamplona. I first thought to have everything in tags, but then thought I'd put some high level things in tags and then fine grained data in content/json. Do you think its ok to have potentially a whole bunch of tags?

[vitorpamplona]

Do you think its ok to have potentially a whole bunch of tags?

Yep. That's ok. We have events with over 5000 tags.

[alltheseas]

why not: consider g tag/geohash for location, as defined in nip-52.

https://grokipedia.com/page/Geohash

[samthomson]

@alltheseas good idea. Updated.

[alltheseas]

A few more comments:

1. I see kind-30001 - NIP-51.md calls this kind deprecated. Not sure what the right kind is. Maybe this is a new weather-station specific kind? You mention this can be sorted at the end, so that works.
2. Since weather station/measurements are distinct/new kinds to all of nostr, NIP-31 alt tag could be useful to advise what this is.
3. Add pressure - dont recall what the real world unit of measurement is (mb?)
4. Add wind speed (kt/knots)
5. Add wind direction (see https://windy.app/blog/what-is-wind-direction.html)
6. add rain (in/mm)
7. add waves - significant wave height (ft/m) and period (seconds)
8. add wave direction (can use same approach as wind direction)
9. dealing with broken/faulty sensors - what happens if a sensor fails? what's the notation for null/no data?
10. timestamps - the happy path here is that the nostr JSON blob created at timestamp is also the timestamp for the observed data. An unhappy paths is that we have an offline weather station for whatever reason, which could mean that when back online the station publishes data observed at a different time and/or mass/batch submits stored / recorded data etc.

In a standard kind-1 note we have the following example: "created_at": 1766813498, which per NIP-01 is defined as "created_at": <unix timestamp in seconds>.

So maybe we add a "observed_at": <unix timestamp in seconds> in the case of unhappy paths of JSON creation timestamp differing from met station observation timestamp.

[vitorpamplona]

Re NIP-51, you probably want to choose your own kind for this.

[alltheseas]

On wave height - on second thought metocean sensors should be assumed to record, and share raw data. Therefore wave height should be just raw wave height, not significant wave height. Hs can be calculated after.