/**
 * <om-overlay> — sparse, rich geo-anchored HTML (spec: "Module Breakdown /
 * Overlay Renderer", "Overlay System — Three-Way Split"). Rendered in
 * shadow DOM for style isolation, same as <om-widget>. Inline-only by
 * design — no `type` resolution, no `registerOverlay` (see spec's own
 * rationale: a `<template>` shared across maps, or the future React
 * component, already serve reuse).
 *
 * Positioning is centrally rAF-batched by OmMapElement (one flush handles
 * every registered overlay's `viewport.project()` + DOM write per frame,
 * "coalescing multiple events per frame into one DOM pass") — this class
 * never schedules its own rAF, just exposes `updatePosition()` for the map
 * to call.
 */
import { HTMLElementBase } from "../env";
import type { MapViewport } from "../basemap";
import type { Selection } from "../selection";
export declare class OmOverlayElement extends HTMLElementBase {
    private root;
    private mapEl;
    private content;
    /** The authored light-DOM markup, captured once, before any interpolation — the source every interpolation pass re-runs against. */
    private template;
    /**
     * The last selection-derived anchor this overlay actually used — only
     * meaningful (and only ever updated) when a `layer` attribute scopes this
     * overlay to one layer's selections. Without scoping, multiple overlays
     * all sharing the one global `ctx.selection` (a click-shown popup on one
     * layer, a hover-shown tooltip on another) fight over the same value: the
     * MOST RECENT selection wins regardless of which overlay it was meant
     * for, so a click on layer A yanks layer B's already-open overlay to the
     * click point (and vice versa) — visible as the overlay jumping to the
     * wrong place, then fighting deck.gl's own picking for the pointer
     * underneath it. With `layer` set, a non-matching selection (including a
     * null one — hover-out elsewhere) is treated as "not my concern" and
     * simply doesn't update this remembered anchor; only a matching
     * selection moves it, and only an explicit `visible="false"` hides it.
     */
    /**
     * A 3rd (z) component survives here specifically for the projection at
     * the bottom of `updatePosition` — a selection's real elevation (a depth
     * pick against terrain/3D content, see `Selection.coordinate`'s own doc
     * comment) matters for WHERE on screen the anchor lands under a pitched
     * camera, even though this class only ever positions in 2D. Dropping it
     * (projecting at an implied z=0) put a tooltip over an elevated pick tens
     * to hundreds of pixels from the actual cursor — the anchor was correct
     * in lng/lat, just projected as if the picked surface were at sea level.
     */
    private lastAnchor;
    /** Cached [w, h] for `clip-to-map` (offsetWidth forces layout; flushes run per pointer move) — invalidated by setContent. */
    private clipSizeCache;
    /** Memoized feature anchor — recomputed only when the layer's data reference or the target id changes (live layers swap data). */
    private featureAnchorCache;
    connectedCallback(): void;
    disconnectedCallback(): void;
    /**
     * Replaces the overlay's content template (used by the internal, runtime-
     * managed tooltip overlay the `show-tooltip` action drives — see
     * actions.ts — which clones a different author-referenced `<template>`
     * per call rather than being authored once like a normal `<om-overlay>`).
     */
    setContent(html: string): void;
    /**
     * `anchor-layer="regions" anchor-feature-id="mission"` — anchored to a
     * FEATURE (bbox center for polygons/lines, the point itself for flat
     * rows) instead of a hardcoded coordinate, so the overlay follows the
     * data. Resolved against the layer's live IR on each flush, memoized by
     * data reference; empty data (still loading) resolves quietly and
     * retries on the next flush.
     */
    private resolveFeatureAnchor;
    /**
     * Overlays with no interactive content default to `pointer-events: none`
     * — there's nothing in them to click/hover, so letting them sit on top of
     * the deck.gl canvas would only ever cost picking, never gain anything.
     * That matters most for a hover-anchored overlay (any `anchor-from=
     * "selection"` overlay shown from a hover behavior, like the built-in
     * tooltip mechanism): it renders directly over the hovered point, and
     * without this, moving the cursor toward the overlay hands mouse events
     * to this DOM element instead of the canvas underneath — deck.gl loses
     * the hover pick, the overlay hides, the canvas is exposed again, the
     * same pick re-fires, and the cycle repeats as a visible flicker. An
     * overlay WITH interactive content (a `data-emit` close button, say)
     * keeps normal pointer-events so that content stays clickable.
     */
    private updatePointerEvents;
    /**
     * Called by OmMapElement's batched flush on every viewport/selection
     * change. Resolves the anchor coordinate (`anchor-from="selection"` or a
     * static `anchor="[lng,lat]"`), culls off-screen/behind-camera anchors,
     * and re-interpolates `{{field}}` tokens against the current selection.
     */
    /**
     * Screen rect for collision-dim (spec: "Overlap avoidance") — null when
     * hidden (via COMPUTED visibility, so author CSS/class hiding counts too,
     * not just our inline write) or when this is transient runtime chrome
     * (`__onlymapjs-` tooltip/trace/draw preview, which glides on hover and
     * must not flicker widgets). Only stable author popups drive dimming.
     */
    getVisibleRect(): DOMRect | null;
    updatePosition(viewport: MapViewport | undefined, selection: Selection | null, pickType?: "hover" | "click"): void;
}