Почему GPT понимает карты иначе, чем текст
Языковая модель не «видит» пространство. Она оперирует токенами, но в обучающей выборке было миллионов пар: описание → геометрия, координаты → свойства, задача → код. GPT восстанавливает паттерны картографического мышления: проекции, топологию, иерархию объектов, семантику тегов OSM.
Ключевое отличие от обычного текста — структурная жёсткость. В промте для карты порядок слоёв, система координат, уровень детализации и формат выхода не négociable. Пропуск любого параметра даёт галлюцинацию: несуществующие теги, сломанную топологию, не ту проекцию.
Хороший картографический промт — это техническое задание в естественном языке с явными ограничениями и примером ожидаемой структуры.
Анатомия рабочего промта: 5 обязательных блоков
Роль и контекст
Кто ты: GIS-аналитик, картограф, разработчик карт. Задача: векторная карта, растр, анализ, код. Входные данные: что есть на входе.
Пространственные ограничения
BBox или полигон AOI, CRS (EPSG:4326 / 3857 / локальный), уровень зума или масштаб, допуск точности.
Семантика объектов
Теги OSM / атрибуты слоя, фильтры по классам, иерархия: Poi → Building → Landuse → Boundary. Что включать, что исключать.
Формат и структура выхода
GeoJSON / TopoJSON / SVG / WKT / CSV / PyQGIS / Folium / Mapbox GL JS. Схема свойств, вложенность, именование полей.
Проверка и валидация
Требование валидного GeoJSON, корректной топологии, отсутствия самопересечений, соответствия схеме. Пример теста.
5 паттернов промтов для любых картографических задач
Библиотека: 12 готовых промт-шаблонов
Каждый шаблон — копируй, подставь свои параметры, запускай. Сгруппированы по типу выхода: данные, код, стиль, анализ.
Плохой промт vs Хороший промт: разбор на примере
Сделай карту кафе в Москве
• Галлюцинированные координаты • Нет CRS — по умолчанию WGS84, но неявно • Свойства: только name • Формат: «вот JSON» — часто с trailing commas • Нет проверки валидности
- Нет AOI — охват не определён
- Нет фильтра по тегам OSM
- Нет требования к схеме свойств
- Нет формата выхода
- Нет инструкции валидации
Сгенерируй GeoJSON кафе Центрального АО Москвы
«Ты — GIS-аналитик. Сгенерируй FeatureCollection amenity=cafe в полигоне Центрального АО Москвы (приложен GeoJSON). CRS: EPSG:4326. Свойства: id (uuid), name, cuisine, opening_hours, wheelchair, addr:*, phone, website, rating (1-5). Минимум 30 объектов. Выход — ТОЛЬКО валидный JSON. После генерации: проверь через geojsonhint, убедись что все точки внутри полигона.»
- Явный AOI (полигон, не BBox)
- Чёткий тег OSM
- Полная схема properties
- Количественная цель (минимум 30)
- Валидация: geojsonhint + in-polygon test
Частые режимы отказа: почему промт даёт мусор
Галлюцинированные теги OSM
Модель придумывает shop:coffee вместо amenity:cafe + cuisine:coffee_shop. Лечится: явно перечисли нужные ключи в промте или дай ссылку на wiki.openstreetmap.org.
Сломанная топология
Self-intersecting полигоны, дырки там, где не надо, MultiPolygon вместо Polygon. Лечится: добавь требование ST_MakeValid / buffer(0) в шаге валидации промта.
Не та проекция
Координаты в Web Mercator (EPSG:3857) вместо WGS84 (EPSG:4326) или наоборот. Лечится: всегда пиши CRS в промте и требуй его в выходе.
Переполнение контекста
Запрос 10 000 объектов упирается в лимит токенов — JSON обрывается посередине. Лечится: проси постранично (cursor/offset) или сразу код для выгрузки через Overpass/OSM API.
Игнорирование CRS при расчётах
Буфер в градусах вместо метров, площадь в градусах². Лечится: в CoT-промте требуй проецировать в метрическую СК перед любым измерительным действием.
Смешение векторного и растрового мышления
Просьба «сделать теплокарту» без указания: hexbin / H3 / kernel density / rasterize. Лечится: указывай алгоритм и параметры (resolution, radius, weight field).
Сохрани шпаргалку. Начни с паттерна №1 — он закрывает 60% рутинных задач. Остальное — комбинации тех же блоков.