meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
2.99k stars 715 forks source link

[Feature Request]: Lat/Lon as an int vs a GeoHash #3319

Closed nothingmn closed 4 months ago

nothingmn commented 4 months ago

Platform

NRF52, ESP32

Description

Just was hoping to provide some light feedback on the way we represent the location..

Lat and Lon are integer values. Im assuming to save space, the team might want to consider using a GeoHash instead.

https://www.movable-type.co.uk/scripts/geohash.html

Using only 12 characters you get an accuracy of less than 40mm, and save far more space than using 2 x integer values

The algorithm to convert to/from a GeoHash and traditional lat/lon is very wide spread and many tools like Grafana support a GeoHash location representation.

garthvh commented 4 months ago

Not sure we want to depend on GeoHash for the root location data, and all the apps would have to convert back to do anything with it anyways. We do have a essentially unused google plus code display option, looks like this might be easier than that is.

thebentern commented 4 months ago

Looks interesting. I'll dig into a bit. It's something we'd have to discuss for 3.0 since it would be a big breaking change for protocol, firmware, and clients.

nothingmn commented 4 months ago

I do suspect its a breaking change, maybe vNext could include both lat/lon and geohash, then vNext+1 we just deprecate lat/lon. Seems like a gradual transition would be a good idea.

IMHO, having devices+apps+etc. convert to/from geohash's isn't all that difficult ..but will take time..,

of course this is in the interest of saving bandwidth...

50 characters "longitudeI":"-1329735422" "latitudeI":"672633768"

20 characters: "pos":"aaaaaaaaaaaa"

GUVWAF commented 4 months ago

50 characters "longitudeI":"-1329735422" "latitudeI":"672633768" 20 characters: "pos":"aaaaaaaaaaaa"

This is the output after protobuf decoding, but it is not how it is actually sent over the air. Denoting a field like "longitudeI" will only use a couple of bits. How many bits do you need per GeoHash character? The current value is a 32-bit integer (4 bytes), so we have full precision with only 8 bytes.

Edit: looks like the GeoHash symbol is in base 32, so using 5 bits. With 12 characters you'll use 60 bits instead of 64 what we use now. Don't think it's worth using a different encoding then.