]> Anuna Research Pty Ltd

hugo@anuna.io https://codeberg.org/anuna/saywhere

geocoding geolocation coordinates geohash BIP-39 This document specifies SayWhere, an open-source system for encoding geographic coordinates (latitude, longitude, and optional altitude) into human-memorable word phrases and decoding them back to coordinates. The system provides deterministic, reversible encoding with two-layer error detection (per-word parity and optional terminal word-phrase checksum) and supports three-dimensional positioning for multi-level structures. SayWhere introduces hierarchical variable-length phrases with true prefix relationships, enabling precision scaling from regional (1 word) to meter-level accuracy (6 words). The system uses the Bitcoin Improvement Proposal 39 (BIP-39) mnemonic wordlist for multilingual support and geohash spatial indexing for efficient location encoding.

Introduction

Motivation Geographic coordinates (latitude, longitude) are precise but difficult to communicate verbally or memorize. A typical coordinate pair such as (40.7128, -74.0060) requires exact decimal precision and is prone to transcription errors. SayWhere addresses this by encoding coordinates into memorable word phrases while maintaining precision, determinism, and providing error detection capabilities. This challenge becomes critical in natural disasters and emergency response scenarios, where communication infrastructure may be compromised and rapid verbal location sharing essential for coordinating rescue operations. Word-based location phrases can be communicated over radio, written on paper, or relayed through human chains without requiring functional GPS devices or internet connectivity. Traditional postal addresses do not always provide the level of precision desired, assume a built environment, and often require some tacit knowledge of that built environment. Existing proprietary systems use closed algorithms, lack transparency and require a centralized service to resolve word phrases creating a single point of failure which is unaceptable in critical environments. Plus Codes use alphanumeric strings that are harder to communicate verbally. Traditional geohash uses Base32 strings that are not human-memorable. SayWhere provides an open, transparent alternative with hierarchical structure, optional altitude, multi-lingual support, and error detection.

Design Goals Deterministic: Same coordinates always produce identical word phrases Reversible: Word phrases can be decoded back to original coordinates Human-Friendly: Words are common, easy to spell, and phonetically distinct Error Detection: Two-layer validation with per-word parity and optional terminal checksum tp validate a word phrase. 3D Support: Optional altitude component for vertical positioning Open Standard: Public domain algorithm based on established prior art with no proprietary restrictions Hierarchical: Variable-length phrases (1-6 words) with true prefix relationships

Comparison to Existing Systems Proprietary word-based systems: Closed algorithms, fixed-length (typically 3 words), no error detection, no altitude support Plus Codes: Alphanumeric (not word-based), harder to communicate verbally Geohash: Base32 strings, not human-memorable SayWhere: Open source, hierarchical word phrases, 3D support, two-layer error detection (LSB parity + optional terminal checksum), true prefix relationships, hand-verifiable checksums

Technical Differentiation SayWhere is built upon established open technologies as prior art: Geohash (Niemeyer, 2008): Spatial indexing system using base-32 strings BIP-39 (Palatinus et al., 2013): Mnemonic wordlist standard with 2,048 words SayWhere combines geohash spatial indexing with BIP-39 word encoding to create hierarchical variable-length phrases. This differs from fixed-length proprietary systems that use cell-based integer decomposition approaches. The use of geohash as the intermediate representation (rather than proprietary integer encoding) and the hierarchical prefix relationships are key distinguishing features.

Terminology

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Core Concepts

Hierarchical Word Phrase:

Variable-length sequence of words (1-N words) representing location with increasing precision

Prefix Relationship:

Shorter phrases represent a bounded area that contain all longer phrases with the same prefix

Location Words:

Words encoding the position of cell within a base32 cell grid (excluding checksum and altitude)

Checksum Word:

Optional terminal validation word from a distinct 32-word vocabulary for phrase-level error detection

Altitude Units:

Optional numeric component for vertical position

Wordlist:

An ordered array of words used for encoding/decoding (BIP-39 standard)

Precision Level:

Spatial resolution determined by phrase length

Geohash:

A geocoding system using base32 strings for spatial indexing

Phrase Types

Hierarchical Phrase:

Pure spatial encoding without terminal checksum (maintains prefix relationships)

Validated Phrase:

Includes terminal checksum word for phrase-level error detection

3D Phrase:

Includes altitude component for vertical positioning

System Architecture

Encoding Pipeline The encoding process transforms geographic coordinates into word phrases through the following pipeline: Input validation: Verify latitude [-90, 90], longitude [-180, 180], altitude [-30000, 30000] Geohash generation: Convert coordinates to base32 geohash string Chunk processing: Split geohash into 2-character chunks (10 bits each) Parity calculation: Add 1-bit LSB parity to each chunk Word mapping: Map 11-bit values (10 data + 1 parity) to BIP-39 wordlist Phrase assembly: Join location words with dots for hierarchical structure Optional: Compute and append CRC-8 terminal checksum word from 32-word vocabulary

Decoding Pipeline The decoding process reverses the encoding to recover coordinates: Phrase parsing: Split on dots, validate word format Checksum detection: Identify and separate terminal checksum word (if present) Word lookup: Find each location word in BIP-39 wordlist to get 11-bit index LSB parity validation: Verify 1-bit parity for each location word Terminal checksum validation: If present, validate phrase-level checksum Chunk extraction: Extract 10-bit chunk value from each location word Geohash reconstruction: Concatenate chunks to form geohash string Coordinate decoding: Decode geohash to latitude/longitude with bounds

Format Specifications

Hierarchical Format Hierarchical phrases maintain true prefix relationships:

Key Property: Each shorter phrase represents an area containing all longer phrases with the same prefix. Error Detection: Two independent layers: 1. Each location word contains a built-in LSB parity bit for single-word error detection 2. Optional terminal checksum word validates the entire phrase (with ~3% False Negative) With Terminal Checksum: ~~~~ grape.column.hip.seal # Validated 3-word phrase ~~~~ Where "seal" is from the 32-word checksum vocabulary and validates "grape.column.hip".

Precision vs. Length Table Precision is constrained by geohash spatial indexing: Words Geohash Chars Grid Dimensions Avg Size Use Case 1 2 1,252km × 624km ~900km Country/Large Region 2 4 39.1km × 19.5km ~28km City 3 6 1.2km × 609m ~900m Neighborhood 4 8 38.2m × 19m ~27m Building 5 10 1.2m × 59.5cm ~90cm Room/Precise Position 6 12 3.7cm × 1.9cm ~2.7cm Sub-Meter Precision 7 14 1.2mm × 0.6mm ~0.85mm Millimeter Precision 8 16 37μm × 19μm ~27μm Micron-Level Precision Key Insight: The 2,048-word BIP-39 vocabulary provides sufficient combinations for encoding geohash data. Each word encodes 2 geohash characters (10 bits) plus 1 parity bit, utilizing the full 11-bit address space. Extensibility: The hierarchical encoding pattern can be extended beyond 6 words as measurement devices and positioning technologies improve. The algorithm supports phrases of any length, with each additional word adding approximately 2 geohash characters of precision. Future applications with centimeter or millimeter-accurate positioning systems can use 7, 8, or more words while maintaining full backward compatibility with shorter phrases.

Wordlist Specification

BIP-39 Wordlist (REQUIRED) SayWhere uses the BIP-39 mnemonic wordlist as its standard wordlist. This provides significant advantages: Size: Exactly 2,048 words (11 bits) - perfect for encoding 2 geohash characters (10 bits) + 1 parity bit Battle-tested: Used by millions in cryptocurrency wallets since 2013 Multilingual: Official wordlists in 9 languages Widely distributed: BIP-39 wordlists are embedded in countless applications and hardware devices worldwide, ensuring availability and consistency Open source: No licensing restrictions Existing ecosystem: Libraries available in all major languages

Requirements A compliant wordlist MUST satisfy these criteria: Size: Exactly 2,048 words (index 0 to 2,047) Character Set: Lowercase ASCII letters [a-z] only Length: Each word 3-8 characters (BIP-39 standard) Uniqueness: No duplicate words Ordering: Stable ordering (indices never change within a version) Phonetic Distinctness: First 4 letters must be unique (BIP-39 property) Family-Friendly: No profanity or offensive terms

File Format Wordlists MUST be stored in JSON format:

Available Wordlists BIP-39 provides wordlists in the following languages: English Spanish French Italian Japanese Korean Chinese (Simplified) Chinese (Traditional) Czech Portuguese

Versioning Wordlist versions MUST follow semantic versioning (MAJOR.MINOR.PATCH): MAJOR: Incompatible changes (words removed/reordered) MINOR: Backward-compatible additions PATCH: Bug fixes (typo corrections) Critical: Encoding and decoding MUST use the same wordlist version.

Encoding Algorithm

Hierarchical Encoding

Input Parameters

Algorithm Steps Step 1: Validate Input

90.0: RAISE ERROR "Invalid latitude" IF longitude < -180.0 OR longitude > 180.0: RAISE ERROR "Invalid longitude" IF max_precision < 1 OR max_precision > 6: RAISE ERROR "max_precision must be 1-6" IF length(wordlist) != 2048: RAISE ERROR "Invalid wordlist size" ]]>

Step 2: Generate Full Geohash

Step 3: Chunk-Based Word Generation

Step 4: Build Hierarchical Phrases

Example Execution Input: New York City (40.7128, -74.0060), max_precision = 3

Prefix Guarantee: Each phrase is a proper prefix of all subsequent phrases. This ensures true spatial hierarchy where shorter phrases represent areas that contain all locations with longer matching prefixes.

Decoding Algorithm

Hierarchical Decoding (RECOMMENDED)

Input Parameters

Algorithm Steps Step 1: Parse Phrase

6: RAISE ERROR "Invalid hierarchical phrase length (must be 1-6 words)" FOR each word IN words: IF NOT is_lowercase_alphabetic(word): RAISE ERROR "Invalid word format" IF length(word) < 3 OR length(word) > 8: RAISE ERROR "Word length out of BIP-39 range" ]]>

Step 2: Decode Each Word with Checksum Validation

> 1 # 0-1023 # Validate checksum expected_checksum = popcount(chunk_value) MOD 2 IF checksum_bit != expected_checksum: RAISE ERROR "Checksum validation failed for word: " + word # Convert chunk value back to 2 geohash characters char1_index = chunk_value / 32 # Integer division char2_index = chunk_value MOD 32 chunk = base32_alphabet[char1_index] + base32_alphabet[char2_index] RETURN chunk END FUNCTION ]]>

Step 3: Reconstruct Geohash

Step 4: Decode Geohash to Coordinates

Step 5: Return Result

Hierarchical Properties

Prefix Relationships SayWhere hierarchical phrases exhibit true spatial prefix relationships:

Mathematical Property: If phrase A is a prefix of phrase B, then the spatial area of A contains the spatial area of B.

Spatial Containment Containment Guarantee: Any location encoded as "grape.column.hip.thought.pull" will always be contained within the spatial bounds of: "grape.column.hip.thought" (more precise) "grape.column.hip" (less precise) "grape.column" (even less precise) "grape" (least precise)

Use Cases

Progressive Disclosure

Search and Filtering

Checksum Computation

Design Philosophy SayWhere uses per-word parity checksums for error detection. Each word contains a built-in 1-bit parity checksum in its LSB. This provides error detection while maintaining hierarchical prefix relationships.

Per-Word Parity Checksum

Purpose Built-in per-word validation that: Detects single-bit errors in each word independently Maintains hierarchical prefix relationships Requires no additional checksum words Works for phrases of any length (1-6 words)

Algorithm Each word in the BIP-39 wordlist (2,048 words = 11 bits) encodes: 10 bits: Geohash chunk data (2 base32 characters) 1 bit: Parity checksum (LSB)

> 1 # Recalculate expected parity expected_parity = popcount(chunk_value) MOD 2 RETURN stored_parity == expected_parity END FUNCTION ]]>

Properties Error Detection: Detects any odd number of bit flips in the 10-bit chunk Probability: 50% chance of detecting even number of bit flips No False Positives: Valid words always pass parity check Zero Overhead: No additional words required Prefix Preserving: Shorter phrases remain valid prefixes

Optional Terminal Checksum

Purpose An optional terminal checksum word MAY be appended to any phrase to provide phrase-level error detection for transmission errors. The terminal checksum: Uses a distinct 32-word vocabulary (auto-detectable) Validates the entire phrase (word substitution, omission, transposition) Provides near-uniform distribution for optimal error detection Complements per-word LSB parity for two-layer error detection

Checksum Wordlist The terminal checksum uses a 32-word vocabulary distinct from the BIP-39 location wordlist:

These words are: - Distinct: Never overlap with BIP-39 location words - Memorable: Colors and animals are universally understood - Phonetically clear: Easy to communicate verbally over radio/phone

CRC-8 Algorithm For systems with computational capability (phones, computers, calculators), use CRC-8 for optimal error detection:

> (10 - bit)) AND 1 byte_index = bit_position / 8 # Integer division bit_in_byte = bit_position MOD 8 bytes[byte_index] |= (bit_value << (7 - bit_in_byte)) bit_position = bit_position + 1 END FOR END FOR # Step 3: Compute CRC-8 using lookup table crc = 0xFF # Initial value FOR byte IN bytes: index = crc XOR byte crc = CRC8_TABLE[index] END FOR # Step 4: Map to checksum word checksum_index = crc MOD 32 RETURN CHECKSUM_32[checksum_index] END FUNCTION ]]>

The CRC-8 lookup table (256 bytes) is provided in the reference implementation. Properties: - Distribution: Chi-square = 18.85 (essentially perfect uniform distribution) - Error Detection: 96.9% (theoretical maximum) - Computation: Fast with lookup table (~10 operations per byte) - Implementation: Available in all programming languages Key Insight: Computing CRC over word indices rather than strings eliminates structural biases from dots and letter frequencies, achieving near-perfect uniformity (chi-square of 18.85 vs target of 44.3 for uniform distribution).

Examples Example 1: New York City ~~~~ Location: "grape.column.hip" CRC-8 Calculation: Word indices: [814, 366, 863] Packed bytes: [0xCC, 0xDB, 0x6F] CRC-8 (polynomial 0x07, init 0xFF): 0x1E Checksum index: 0x1E % 32 = 30 Checksum: CHECKSUM_32[30] = "seal" Result: "grape.column.hip.seal" ~~~~ Example 2: London ~~~~ Location: "kit.puzzle" CRC-8 Calculation: Word indices: [1004, 1434] Packed bytes: [0xFA, 0xD5, 0x00] CRC-8 (polynomial 0x07, init 0xFF): 0xA4 Checksum index: 0xA4 % 32 = 4 Checksum: CHECKSUM_32[4] = "orange" Result: "kit.puzzle.orange" ~~~~

Encoding with Terminal Checksum To create a validated phrase:

Decoding with Checksum Detection Decoders MUST automatically detect and validate terminal checksums:

Error Detection Capabilities The terminal checksum detects: Word substitution: "grape" misheard as "grace" Word omission: "grape.column.hip" → "grape.hip" Word transposition: "grape.column" → "column.grape" Word addition: Unintended extra words Detection Rate: 5-bit checksum provides ~97% detection of transmission errors (1/32 false negative rate).

Two-Layer Error Detection Terminal checksum and per-word LSB parity work together: Layer Scope Detects When Checked LSB Parity Per-word Bit corruption in individual words During word decode Terminal Checksum Whole phrase Wrong word, order, omissions After all words decoded Example: Error caught by terminal checksum ~~~~ Sent: "grape.column.hip.seal" Received: "grape.color.hip.seal" (column → color)

LSB parity passes (both valid BIP-39 words) # Terminal checksum fails: expected = compute_terminal_checksum(["grape", "color", "hip"]) → "whale" received = "seal" # Error detected! ✗ ~~~~

Field Verification (BACKUP) The following simplified checksum MAY be calculated and verified in emergency situations using printed reference cards:

Use Cases Emergency Response ~~~~ Hiker (over radio): "My location is grape column hip seal" Dispatcher: validates checksum System: ✓ Checksum valid - location confirmed Dispatcher: "Coordinates confirmed, dispatching rescue team" ~~~~ Error Detection ~~~~ Sent: "grape.column.hip.seal" Received: "grape.hip.seal" (word dropped) System calculates: Expected: compute_terminal_checksum(["grape", "hip"]) → "yellow" Received: "seal" ✗ Mismatch - transmission error detected Response: "Please repeat location, checksum error detected" ~~~~

Altitude Support

Design Philosophy SayWhere altitude components are expressed as unitless integers representing quantized steps. The step size is a configuration parameter, not part of the phrase itself. Rationale: Unitless values maintain: Phrase brevity: ".20" vs ".60m" or ".20meters" Simplicity: Consistent with horizontal coordinate abstraction Flexibility: Applications can choose appropriate step sizes without breaking compatibility Voice-friendly: Easier to communicate "twenty" than "twenty meters"

Quantization Altitude MUST be quantized to fixed-step increments:

Standard step configurations: Use Case Step Size Example Input Encoded Units Notes Buildings 3.0m 60.0m .20 Typical floor height Drones 1.0m 60.0m .60 Precise vertical control Aircraft 100.0m 6000.0m .60 Flight levels (FL060) Mining/Caves 5.0m -50.0m .-10 Underground operations

Range Limits

URN Format

Specification SayWhere defines a canonical URN format ( compliant):

Components urn:saywhere - Namespace identifier (fixed) {language} - ISO 639-1 language code (2 lowercase letters) {word1}.{word2}.{word3}.{checksum} - Word phrase {altitude} - OPTIONAL signed integer altitude units (unitless) The terminal checksum is MUST be from a distinct wordlist to the location words to enable the parser to determine if the final word in the word phrase is a location word or the terminal checksum.

Examples

Parsing Grammar (ABNF)

Security Considerations This section follows the guidelines in for security considerations in protocol specifications.

Location Privacy SayWhere phrases encode precise geographic locations and can reveal sensitive information about individuals' whereabouts. Privacy considerations include: Data Minimization: Implementations SHOULD NOT log or store phrases without explicit user consent User Awareness: Users SHOULD be warned that phrases reveal precise physical locations that persist over time Sharing Controls: Applications SHOULD implement access controls before transmitting or displaying location phrases Hierarchical Disclosure: Applications can leverage hierarchical phrases to enable progressive disclosure, sharing only the precision level necessary for the use case Pervasive Monitoring: Per , implementations should consider that location data transmission may be subject to pervasive monitoring attacks Location phrases shared in public forums, radio communications, or other non-confidential channels should be considered public information accessible to any party.

Checksum Limitations SayWhere provides two layers of error detection (per-word LSB parity and optional terminal checksum), but neither provides security: No Authentication: Checksums do NOT provide cryptographic authentication or integrity protection Accidental Errors Only: Checksums ONLY detect accidental transmission/transcription errors, not deliberate tampering Not Security Critical: Do not rely on checksums for security-critical applications requiring authenticated location data Malicious Modification: An attacker can easily generate valid phrases with correct checksums for arbitrary locations Limited Entropy: Terminal checksum uses only 5 bits (32 values), providing ~3% false negative rate The terminal checksum is designed for error detection (communication integrity), not security (adversarial protection). Applications requiring authenticated location assertions should implement additional cryptographic signatures or message authentication codes.

Wordlist Integrity Implementations depend on wordlist consistency for correct operation: Verification Required: Implementations MUST verify wordlist integrity using cryptographic checksums (SHA-256 or better recommended) Corruption Impact: Corrupted or modified wordlists produce incorrect encodings that may place users in unintended or dangerous locations Supply Chain Security: Consider signing wordlist files for distribution and verifying signatures before use Version Control: Implementations should verify the wordlist version matches the expected version for the encoding/decoding operation A compromised wordlist could enable man-in-the-middle attacks where locations are systematically mistranslated.

Denial of Service Implementations should protect against resource exhaustion: Rate Limiting: Implementations SHOULD rate-limit encoding/decoding operations, particularly in network-facing services Batch Size Limits: Batch operations SHOULD enforce maximum size limits to prevent memory exhaustion Early Validation: Invalid input SHOULD be rejected early in processing to avoid expensive computation

IANA Considerations This section follows the guidelines in for IANA considerations sections. This document requests the registration of the "saywhere" URN namespace in the "Uniform Resource Names (URN) Namespaces" registry, in accordance with the procedures defined in .

URN Namespace Registration Per Section 6, the following registration template is provided:

Namespace ID:

saywhere

Registration Information:

Version 1, 2025-10-12

Declared registrant:

SayWhere Contributors

Anuna Research Pty Ltd

Email: contact@saywhere.org

URI: https://codeberg.org/anuna/saywhere

Declaration of syntactic structure:

See Section 9 of this document

Relevant ancillary documentation:

This document serves as the specification for the saywhere URN namespace

Identifier uniqueness considerations:

Uniqueness is guaranteed by the deterministic encoding algorithm specified in this document. Each unique geographic coordinate (latitude, longitude, altitude) and wordlist language combination produces a unique URN.

Identifier persistence considerations:

SayWhere URNs remain valid and decodable as long as the corresponding wordlist version is available. Wordlists follow semantic versioning and are maintained in public repositories for long-term availability.

Process of identifier assignment:

SayWhere URNs are not centrally assigned. Any party can generate a valid SayWhere URN by applying the deterministic encoding algorithm specified in this document to geographic coordinates.

Process for identifier resolution:

SayWhere URNs are decoded to geographic coordinates using the deterministic decoding algorithm specified in Section 7 of this document. Resolution requires access to the appropriate wordlist version.

Rules for Lexical Equivalence:

Two SayWhere URNs are lexically equivalent if and only if they are identical after Unicode normalization (NFC) and case normalization (lowercase). The comparison is case-insensitive and performed on Unicode-normalized strings.

Conformance with URN Syntax:

SayWhere URNs conform to the URN syntax specified in . The syntax is formally defined using ABNF in Section 9 of this document.

Validation mechanism:

Validation consists of: (1) syntax validation per the ABNF grammar, (2) verification that each location word exists in the specified language wordlist, (3) validation of per-word LSB parity checksums, and (4) if present, validation of the terminal checksum word as specified in Section 10.

Scope:

Global

Implementation Guidance

Performance Optimization In-Memory Wordlist:

Testing Requirements Implementations MUST pass: All test vectors in Roundtrip tests (encode → decode → verify coordinates match) Per-word LSB parity validation tests Terminal checksum validation tests (detection and validation) Error handling tests (both parity and checksum errors) Boundary condition tests (poles, dateline, altitude extremes) Altitude quantization tests (different step sizes) Checksum error detection tests (substitution, omission, transposition)

Reference Implementation A reference implementation in Scheme (Guile) is available for testing and validation purposes. This implementation is provided as an example and is not required for conformance: Repository: https://codeberg.org/anuna/saywhere License: GNU GPL v3 Implementations in other languages that pass the test vectors in are considered conformant.

Web Application Demo An interactive web application is available for exploring SayWhere encoding and decoding: Demo: https://saywhere.org/grape/column/hip The demo allows users to: Visualize hierarchical phrase resolution on an interactive map Encode coordinates to word phrases Decode word phrases to geographic locations Explore the spatial containment relationships between different precision levels Test error detection capabilities

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Geohash Algorithm Details

Encoding Pseudocode

mid: bits.append(1) lon_min = mid ELSE: bits.append(0) lon_max = mid ELSE: mid = (lat_min + lat_max) / 2 IF latitude > mid: bits.append(1) lat_min = mid ELSE: bits.append(0) lat_max = mid is_longitude = NOT is_longitude # Convert bits to base32 string base32_chars = "0123456789bcdefghjkmnpqrstuvwxyz" geohash = "" FOR i = 0 TO length(bits) STEP 5: chunk = bits[i:i+5] value = binary_to_decimal(chunk) geohash += base32_chars[value] RETURN geohash END FUNCTION ]]>

Test Vectors

Hierarchical Encoding Test Cases

Test Case 1: New York City

Test Case 2: London

Test Case 3: Equator Crossing

Test Case 4: With Terminal Checksum

Acknowledgments The SayWhere system uses the geohash algorithm created by Gustavo Niemeyer and the BIP-39 wordlist developed by the Bitcoin community. The altitude component was taken from the Geowords implementation by mfrank. We thank these contributors for their foundational work. Special thanks to the open-source community for feedback and testing of the SayWhere implementation.