It would be interesting to interlace the latitude and longitude bits in such a way that any prefix is a valid code of reduced resolution, and you can add arbitrarily many digits for increased precision. I think geohash does this? Or does reducing precision give you a geohash that isn't a prefix? Anyway...
Each digit of such a code might be roughly equivalent to one decimal digit of both latitude and longitude. For example, maybe the first three digits would get you to within about a nautical mile.
But that's dumb. While short codes are nice, a short code that only gets you within a mile is mostly useless. It would be better to use a suffix than a prefix. You can still get arbitrary precision with a decimal point.
First, specify a fixed "unit" of precision. Say 10m. Any short code is assumed to be the least significant digits. If my math is right, you could specify any point closer than 2 km +/- 10 m using maybe 2 digits. Most buildings in most cities will need maybe 3-5 digits.
You could invite somebody from the same city to your house, telling them you live at YA9. Their GPS would assume that the missing prefix digits match their current location. If you want to give them the location of the centerpiece on your dining room table, you could add a decimal point and more precision: YA9.7R.
You could even use short-codes that look like Mapcodes: US-DC, YA9. The location provides the context for the missing prefix digits. But you always have the option of specifing the full code to avoid ambiguity or lookup tables.
One problem is the check digit. Maybe there's a way to interlace the check bits too, so you don't need a full check digit for every code. Is there a checksum algorithm where a prefix of the checksum is a checksum of a prefix? That obviously couldn't detect a one-digit typo. Or, maybe just put a check digit at end. All codes become 2 digits minimum. The checksum algorithm wouldn't need to be fancy since you can assume the rest of the digits based on your current location.
Another easily fixed problem is mentioned on the Geohash wikipedia page: locations near the equator and prime meridian could have wildly different codes than other locations nearby. The solution to that is easy: Translate lat/lon into a different system. Translate latitude into a number from 0 to 180, with 0 being the south pole. Similarly translate longitude to a number from 0 to 360, with 0 being at the international date line. Then encode those translated numbers. Nobody would ever see those intermediate numbers. You always display either lat/lon or the code, but the translation ensures that you don't have vastly different codes for nearby places (at least in any place with a significant number of people).
Check out Military Grid Reference System (MGRS) [1], referenced in the article. Increasing the number of digits increases the precision of the location.
It would be interesting to interlace the latitude and longitude bits in such a way that any prefix is a valid code of reduced resolution, and you can add arbitrarily many digits for increased precision. I think geohash does this? Or does reducing precision give you a geohash that isn't a prefix? Anyway...
Each digit of such a code might be roughly equivalent to one decimal digit of both latitude and longitude. For example, maybe the first three digits would get you to within about a nautical mile.
But that's dumb. While short codes are nice, a short code that only gets you within a mile is mostly useless. It would be better to use a suffix than a prefix. You can still get arbitrary precision with a decimal point.
First, specify a fixed "unit" of precision. Say 10m. Any short code is assumed to be the least significant digits. If my math is right, you could specify any point closer than 2 km +/- 10 m using maybe 2 digits. Most buildings in most cities will need maybe 3-5 digits.
You could invite somebody from the same city to your house, telling them you live at YA9. Their GPS would assume that the missing prefix digits match their current location. If you want to give them the location of the centerpiece on your dining room table, you could add a decimal point and more precision: YA9.7R.
You could even use short-codes that look like Mapcodes: US-DC, YA9. The location provides the context for the missing prefix digits. But you always have the option of specifing the full code to avoid ambiguity or lookup tables.
One problem is the check digit. Maybe there's a way to interlace the check bits too, so you don't need a full check digit for every code. Is there a checksum algorithm where a prefix of the checksum is a checksum of a prefix? That obviously couldn't detect a one-digit typo. Or, maybe just put a check digit at end. All codes become 2 digits minimum. The checksum algorithm wouldn't need to be fancy since you can assume the rest of the digits based on your current location.
Another easily fixed problem is mentioned on the Geohash wikipedia page: locations near the equator and prime meridian could have wildly different codes than other locations nearby. The solution to that is easy: Translate lat/lon into a different system. Translate latitude into a number from 0 to 180, with 0 being the south pole. Similarly translate longitude to a number from 0 to 360, with 0 being at the international date line. Then encode those translated numbers. Nobody would ever see those intermediate numbers. You always display either lat/lon or the code, but the translation ensures that you don't have vastly different codes for nearby places (at least in any place with a significant number of people).