export type CoordSource = 'telegram-native' | 'feishu-native' | 'dingtalk-link-amap' | 'dingtalk-link-tencent' | 'dingtalk-link-baidu' | 'dingtalk-link-unknown' | 'h5-browser-geolocation' | 'web-admin';
export interface NormalizeResult {
    /** Latitude in WGS-84 after any conversion. */
    lat: number;
    /** Longitude in WGS-84. */
    lng: number;
    /** Which conversion was applied. Useful for log post-mortems. */
    applied: 'none' | 'gcj02-to-wgs84' | 'bd09-to-wgs84';
    /** True iff the input was outside the China bbox (conversions skipped
     *  there because GCJ-02 is only defined for in-China coords). */
    outOfChina: boolean;
}
/**
 * Convert any incoming (lat, lng) to WGS-84 based on what we know about
 * the source. Adapters route every native coord through this. Defaults
 * favor "trust the payload as WGS-84" because that's the safer assumption
 * when the source is ambiguous — applying an inverse GCJ offset to a
 * value that's actually already WGS produces a 500m-1km error, while
 * pass-through on actual GCJ leaves the user with the same ~1km error
 * but in a recoverable direction. Both error modes get the user roughly
 * the right country / city; an `AGIM_*_COORDS_GCJ02=1` env flag flips
 * the default for any source whose users tell us their device DOES apply
 * the offset (Apple devices in China + Chinese region most often).
 */
/** Plan C (2026-05-22): caller can force the source coord-system,
 *  bypassing the env-flag heuristic. Used by IM adapters that have
 *  looked up a per-user preference (see core/user-coord-prefs.ts). */
export interface NormalizeOptions {
    /** Pre-known source coord-system, e.g. learned from the user's
     *  earlier `#wgs` / `#gcj` / `#bd` reply. When set, all other
     *  heuristics are ignored. */
    force?: 'wgs84' | 'gcj02' | 'bd09';
}
export declare function normalizeIncomingCoords(source: CoordSource, lat: number, lng: number, opts?: NormalizeOptions): NormalizeResult;
/** WGS-84 → GCJ-02. */
export declare function wgs84ToGcj02(lat: number, lng: number): {
    lat: number;
    lng: number;
};
/** GCJ-02 → WGS-84 (Newton iteration; converges to sub-meter in 3 passes). */
export declare function gcj02ToWgs84(lat: number, lng: number): {
    lat: number;
    lng: number;
};
/**
 * Baidu BD-09 → GCJ-02. BD-09 is GCJ-02 plus an additional radial offset
 * applied by Baidu. The math is well-known (cf. open-source `coordtransform`
 * libraries); we lift the formula verbatim and add a comment so the next
 * reader doesn't have to derive it.
 */
export declare function bd09ToGcj02(lat: number, lng: number): {
    lat: number;
    lng: number;
};
/** GCJ-02 → Baidu BD-09 (forward; closed form). */
export declare function gcj02ToBd09(lat: number, lng: number): {
    lat: number;
    lng: number;
};
/** BD-09 → WGS-84 via GCJ-02 intermediate. */
export declare function bd09ToWgs84(lat: number, lng: number): {
    lat: number;
    lng: number;
};
/** WGS-84 → BD-09 via GCJ-02 intermediate. Useful for building Baidu
 *  Maps URLs from our WGS-stored coords. */
export declare function wgs84ToBd09(lat: number, lng: number): {
    lat: number;
    lng: number;
};
/** GCJ-02 offset is only defined for mainland China + the bbox below.
 *  Outside, every conversion in this module is a no-op pass-through. */
export declare function outOfChina(lat: number, lng: number): boolean;
//# sourceMappingURL=coord-systems.d.ts.map