Создание функционала поиска локаций, автодополнения адресов или аналитики по геоданным требует надежной и актуальной базы населенных пунктов. Под «реестром городов мира» обычно понимают структурированные наборы данных, содержащие названия городов на разных языках, координаты (широту и долготу), принадлежность к странам и регионам, а также население и временные зоны. В этой статье мы подробно разберем основные источники получения таких данных, их форматы, лицензии и особенности интеграции в современные проекты.

Основные глобальные источники данных

Существует несколько авторитетных проектов, которые являются «золотым стандартом» для геоданных. Большинство коммерческих и открытых баз производны от них.

GeoNames — фундамент открытых геоданных

GeoNames (geonames.org) — это самый известный и масштабный открытый географический справочник. Он содержит более 11 миллионов названий географических объектов, из которых около 5 миллионов — это населенные пункты.

• Особенности: Данные агрегируются из множества официальных источников (нац. картографические службы, почтовые службы) и дополняются пользователями (вики-принцип).
• Атрибуты: Название (ASCII, локальное, альтернативные), координаты (WGS84), класс объекта (P — populated place), код страны (ISO-3166), коды административно-территориального деления (ADM1, ADM2…), население, высота, временная зона.
• Форматы: Текстовые файлы (TSV/CSV), доступные для скачивания по странам или целиком (allCountries.zip), а также веб-сервисы (REST API, JSON, XML).
• Лицензия: Creative Commons Attribution 4.0 (CC BY 4.0). Требуется указание авторства.
• Нюансы: В «сыром» дампе много дублей, исторических названий и мелких населенных пунктов (хутора, ферм). Для продакшена требуется чистка и дедупликация.

OpenStreetMap (OSM) и выгрузки

Проект OpenStreetMap предоставляет наиболее детализированные и актуальные данные о границах городов, полигонах зданий и адресной системе.

• Источники выгрузок: Geofabrik (по странам/регионам), BBBike (вырезки по городам), Planet.osm (весь мир).
• Инструменты обработки: osmium-tool, osm2pgsql (для PostgreSQL/PostGIS), ogr2ogr (GDAL).
• Плюсы: Высокая точность границ, мультиязычность (теги name:en, name:ru, name:ko и т.д.), актуальность (обновления каждую минуту).
• Минусы: Сложность парсинга (PBF формат), отсутствие единой таблицы «город — координаты» (нужно фильтровать по тегам place=city/town/village/hamlet), тяжелый вес полной планеты (>60 Гб сжатого).

Natural Earth Data — для картографирования и визуализации

Если задача — отобразить города на карте мира в малых масштабах, Natural Earth (naturalearthdata.com), лучший выбор.

• Содержит векторы (Shapefile, GeoPackage) для «Populated Places» в трех масштабах: 1:10m, 1:50m, 1:110m.
• Данные обобщены (упрощены), очищены от шума, идеально подходят для веб-карт (Leaflet, Mapbox, OpenLayers).
• Лицензия: Public Domain.

Специализированные и коммерческие базы данных

Для задач, требующих гарантированного качества, поддержки почтовых индексов, телефонных кодов или SLA, используются коммерческие продукты.

GeoDataSource / World Cities Database

Часто рекомендуется в сообществах разработчиков (например, на Хабр Q&A или Яндекс Кью) как источник качественных координат основных городов.

• Есть бесплатная версия (обычно ограничена по количеству городов или атрибутам) и платные редакции (Basic, Premium, Gold).
• Форматы: CSV, SQL (MySQL, PostgreSQL, MS SQL), Excel.
• Включают: широту/долготу, регион, страну, временную зону, код телефона, почтовый индекс (в платных версиях).

WorldCityDB.com

Онлайн-сервис, позиционирующий себя как исчерпывающий справочник по городам любой страны. Предоставляет API и дампы данных.

Русскоязычные агрегаторы, продающие базы «Страны, регионы, города, улицы, почтовые индексы».

• Удобны для проектов, ориентированных на РФ и СНГ (есть ФИАС/КЛАДР соответствия).
• По отзывам разработчиков, качество «мирового» покрытия может быть ниже, чем у GeoNames/OSM (отсутствуют мелкие страны вроде Эль-Сальвадора или Эритреи в некоторых дампах).
• Форматы: SQL, CSV, Excel, JSON.

Готовые решения для разработчиков (GitHub, NPM, PyPI)

Не хочется парсить дампы вручную? Используйте готовые пакеты, которые уже сделали за вас работу по очистке и структурированию.

• Legostaev/contry_region_city (GitHub): Популярный репозиторий с SQL-дампом стран, регионов и городов. Часто цитируется на форумах веб-строительства как быстрое стартовое решение.
• NPM пакеты: cities, world-cities, @geodata/cities — JSON/JS массивы с городами, координатами и кодами стран. Удобны для фронтенда (автокомплит) или серверлесс-функций.
• Python пакеты: geopy (геокодер, использует разные провайдеры), pycountry (страны/регионы), cities-light (Django-приложение с моделями и данными из GeoNames).
• VK API (database.getCities): Упоминается на StackOverflow как источник структурированного JSON со списком городов. Требует токена и соблюдения лимитов API. Данные хороши для СНГ, но покрытие мира может быть неполным.

Сравнительная таблица популярных источников

Технические аспекты интеграции

Выбор формата хранения

1. Реляционные БД (PostgreSQL + PostGIS, MySQL): Стандарт для бэкенда. Позволяет делать пространственные запросы (ST_DWithin, найти города в радиусе N км), индексировать по префиксам названий (GIN/GiST/trigram) для автокомплита.
2. Поисковые движки (Elasticsearch, OpenSearch, Meilisearch, Typesense): Идеальны для реализации «умного» поиска с опечатками, синонимами и ранжированием по населению. Данные из SQL/CSV индексируются один раз.
3. In-memory / Embedded (Redis, SQLite, блоб JSON в коде): Подходит для небольших списков (топ-10k городов) или клиентской части (React Native, браузер).

Структура таблицы (Best Practice)

CREATE TABLE cities (
 id BIGINT PRIMARY KEY, -- GeoNames ID или свой
 country_code CHAR(2) NOT NULL, -- ISO 3166-1 alpha-2
 admin1_code VARCHAR(20), -- Код региона (область/штат)
 admin2_code VARCHAR(80), -- Код района
 name VARCHAR(200) NOT NULL, -- Основное название (локальное или EN)
 ascii_name VARCHAR(200), -- Транслитерация
 alternatenames TEXT, -- JSON массив или текст через запятую: "Москва,Moscow,Moskau..."
 latitude DOUBLE PRECISION NOT NULL,
 longitude DOUBLE PRECISION NOT NULL,
 population BIGINT DEFAULT 0,
 timezone VARCHAR(50), -- IANA tz database name (Europe/Moscow)
 feature_class CHAR(1), -- P (city), PPL (populated place)
 feature_code VARCHAR(10), -- PPLA (capital), PPLC (capital of country)
 geom GEOGRAPHY(POINT, 4326) -- Для PostGIS
);
CREATE INDEX idx_cities_name_trgm ON cities USING GIN (name gin_trgm_ops);
CREATE INDEX idx_cities_geom ON cities USING GIST (geom);

Проблема мультиязычности

Для функции поиска «на разных языках» (корейский, немецкий, английский — как в запросе на Reddit) критически важно поле alternatenames.

• В GeoNames это отдельный файл alternateNamesV2.txt (или колонка в основном дампе), содержащий миллионы строк: geonameid, isoLanguage, alternate name, isPreferredName, isShortName, isColloquial, isHistoric.
• Стратегия: выгрузить только нужные языки (ru, en, de, ko, zh…) в отдельную таблицу city_names(city_id, lang, name, is_preferred) и джойнить при поиске;

Актуальность и обновления

• GeoNames: Ежедневные дифф-выгрузки (modifications-YYYY-MM-DD.txt). Можно настраивать cron-задачу на применение изменений.
• OSM: Минутные/часовые/дневные реплики (файлы .osc.gz). Требуют инструментов вроде osm2pgsql --append.
• Коммерческие базы: Обычно квартальные или полугодовые релизы. Обновление — замена всего дампа.

Юридические аспекты и лицензирование

Внимание: перед использованием в коммерческом продукте внимательно изучите лицензию.

• CC BY 4.0 (GeoNames): Обязательно сохраняйте атрибуцию (ссылку на geonames.org) в интерфейсе приложения или в документации API.
• ODbL (OpenStreetMap): Требует ShareAlike (производная база должна быть открытой под той же лицензией) и атрибуции. Если вы используете OSM только для геокодинга (не распространяете базу), риски ниже, но юристы часто рекомендуют консультироваться.
• MIT / Apache 2.0 / Public Domain (GitHub репозитории, Natural Earth): Максимальная свобода, можно использовать в проприетарном ПО без открытия кода.
• Коммерческие лицензии: Запрещают перераспространение «сырых» данных клиентам. Обычно разрешают использование внутри SaaS.

Рекомендации по выбору для типичных сценариев

Чек-лист перед запуском в продакшн

1. Дедупликация: Убрали ли вы дубликаты (например, «Москва» и «Moscow» как разные строки без связи)?
2. Нормализация имен: Приведены ли имена к NFC (Unicode normalization) для корректного поиска?
3. Фильтрация по населению: Отсеяли ли вы хутора/фермы с населением 0-10 человек, если нужен только «город»?
4. Координаты: Все ли точки попадают в границы заявленной страны (проверка ST_Contains по полигону страны)?
5. Временные зоны: Соответствуют ли IANA TZ ID координатам (проверка через tzwhere или аналоги)?
6. Индексы: Созданы ли триграммные индексы для ILIKE '%query%' или настроен полнотекстовый поиск?
7. Атрибуция: Размещена ли ссылка на источник данных в футере/About/документации API?

Выбор «реестра городов мира» — это всегда компромисс между полнотой покрытия, актуальностью, стоимостью владения (инженерное время на парсинг/поддержку vs лицензионные платежи) и юридическими ограничениями.

Для 90% веб-проектов, требующих поиск города по названию на нескольких языках, оптимальным стартом является: скачивание дампа GeoNames, фильтрация по feature_class='P' и population > 1000, выгрузка альтернативных имен для целевых языков, загрузка в PostgreSQL с расширением pg_trgm или в Meilisearch/Typesense. Это дает профессиональное качество поиска за нулевую стоимость лицензии и предсказуемые затраты на инфраструктуру.

Если проект масштабируется до навигации, логистики или работы с полигонами границ — миграция на стек PostGIS + OpenStreetMap становится неизбежной. Для энтерпрайз-задач с жесткими требованиями к точности почтовых индексов и телефонов — покупка коммерческой базы (GeoDataSource, MaxMind) сэкономит месяцы работы команды данных.