Oddbean new post about login | logout How do people about introducing a [wgs84] tag? It would contain the decimal latitude and longitude as strings. My first idea was to use GeoJSON. However it expects numbers, whereas tags have to be strings (and it reverses lat & lon which is stupid). https://img.sprovoost.nl/2a06ac2492dca2a86ac177df3f8b220ea8c737472e19ffa3f597c4bae2c648e4.png nostr:nevent1qvzqqqqqqypzp5aa32yv8zyw6e4hdtupdgpg7mg5nws3qpsh3z8snet2s9esda8jqyvhwumn8ghj7mn0wd68ytnnwpex7an0daehgtnwdshsqgqlcff7dc6505nsqwk7nwmuyapr5enamzs549jw2rcqgdmzp5rd35descnf
There already is a geohash tag, which Amethyst supports already. Maybe this is what you're looking for?
Geohash is nice and I use it, but I'd also like to use the straight-forward decimal coordinates.
The [g] tags are geohash, at decreasing resolution levels. I'm not sure if the latter is very useful, perhaps it makes it easier to query relays? cc @Vitor Pamplona
It's the only way to query as relays don't offer startsWith queries.
/cc @arkinox @Nathan Day What is the wsg84 spec? 👀
It's not really a spec for notation, it just describes the common coordinate system: https://en.m.wikipedia.org/wiki/World_Geodetic_System
What's the use case? Is it possible to accurately convert from geohash to wgs84? Also see discussion on the numberless Places NIP here: https://github.com/nostr-protocol/nips/pull/927
Pictures typically have coordinates in the exif info. It makes sense to preserve those in a widely used standard format. Geohash is nice *in addition* but it might not even exist in five years.
Hello again Sjors! To introduce a new tag or some other protocol improvement, you can make a PR on the nostr-protocol/nips repository. Then, to get it merged it typically needs a general approval and to be implemented in at least 2 clients and 1 relay. Having been in many geo discussion, I can tell you that privacy would be the top concern for having a wgs84 tag that pinpoints a location. Most photo uploading services on nostr (if not all) scrub exif data for privacy. But I can see legitimate reasons for broadcasting a coordinate, so if you can assuage the privacy concerns then it could be a useful addition. I will mention that in the deep github lore around the g tag I recall it being said that any geo data could be put in there, not just geohashes. Nobody does this AFAIK, but you could technically just put a wgs84 coord in the g tag.
I agree exif info should be stripped from photos by default. They were in my Instagram archive, so my Instablossom script uses them both directly and to generate the geohash. When posting a note (with or without a photo) a client should ask if the user wants to share their location, e.g. @Amethyst does this. It can then obtain the location from either the device GPS or from the photo exif data (before removing it). The photo may have been taken in the past so these are not always the same location. But then the question is how to share the location. If the user is ok with an exact location, e.g. because it's a tourist snapshot so it's not sensitive, then wgs84 exact coordinates seem like the right default. If the user wants to be more careful, they may want to use an inaccurate geohash. Amethyst picks roughly a city size resolution (5km) which is a good default. In that case wgs84 should not be used, because there's no good convention on how to round decimal coordinates. This would lead to confusion when trying to plot images on a map. Back in the day Instagram even had three modus for the user: no location, rough location and accurate location. When location is set to high accuracy, it makes sense to use both standards: wgs84 for general purpose mapping tools, and a geohash at multiple zoom levels for easier search on relays. You could also recommend a single geohash, at the highest resolution a user is comfortable with. However that would require relays to implement the spec as well. Either by supporting startsWith() string matching or by using something like ST_GeoHash in Postgres. Especially the latter seems like a rather heavy requirement. The redundant tags don't use that much space. I do plan to open a PR once I'm a bit more familiar with earlier work and gathered some feedback. Should this be a new NIP or expand nip-52?
When you see multiple geohashes on an event, it's actually kind of a hack that is necessary so that when zooming in a map a given event is visblible at various levels without too much extra work. But this wasn't anticipated when the g tag was added to the protocol. The g tag might only be referenced in nip 52 but it was around before that; it never came from a NIP but was just kinda added at some point. So I don't think it needs to be part of NIP 52. Probably a new NIP, but because it's just a tag storing data and doesn't prescribe any new behavior to the protocol, a NIP may not be necessary. Just start using it! 🫡
I know it predates Nostr, I've heard about it before though hadn't seen it used. https://en.m.wikipedia.org/wiki/Geohash I also changed my script to use it: https://git.sprovoost.nl/sjors/instablossom/src/commit/35435296003f6de9229b30a4998fa3cea8443fee/main.ts#L157 But I'll have to re-run it on a fresh @instasjors npub.
