@ferrybig/cgeodata-reader
    Preparing search index...

    Interface SearchOptions

    Options for search().

    interface SearchOptions {
        level?: PlaceLevel;
        country?: number;
        region?: number;
        limit?: number;
        sort?: boolean;
        areaTieBreak?: boolean | "auto";
    }

    Hierarchy (View Summary)

    Index
    level?: PlaceLevel

    Only places of this level.

    country?: number

    Only places inside this country (by id); the country itself included.

    region?: number

    Only places inside this region (by id); the region itself included.

    limit?: number

    Stop after this many matches.

    sort?: boolean

    Rank matches by relevance instead of id order (Appendix B.5): an exact name match outranks a match on a whole word of the name, which outranks a plain substring match, each tier further split by whether the query's own spelling (not just its folded form) matched; among equal matches, a country outranks a city, which outranks a region. limit still applies, but to the top of the ranked list rather than the first N found in id order -- so with sort the whole match set has to be scored before anything is yielded, since the best match isn't necessarily the first one found.

    areaTieBreak?: boolean | "auto"

    With sort, whether to break ties by area (Appendix B.5.1): among equally good matches, larger places first, so "berlin" puts Berlin, Germany ahead of the many small Berlins in the United States, while a province still follows its own same-named city. Areas come from a locate index (useLocateIndex()):

    • "auto" (the default): by area when a locate index is attached, otherwise by Appendix B.5's plain order. Unlike everything else an index does, attaching one therefore changes the order of results (never which places match).
    • true: by area; rejects without a locate index.
    • false: Appendix B.5's plain order, index or not.