Геоуодинг

Бюджет: 5000 UAH Срок: 4 дня

Здравствуйте. Разбираюсь в геокодинге/реверсе, OSM (Nominatim) и Mapbox, а также в нормальной “админке” через полигоны (PostGIS / point-in-polygon), из-за чего как раз и перестают происходить “улёты” в другой район/за город.

По вашему описанию проблема типовая: вы пытаетесь получать район/город из ответа геокодера (или reverse) — а это эвристика, из-за чего 10–15% точек всегда будут ошибаться, особенно на границах и при неполных адресах. Универсальное решение — разделить задачи:

адрес → координата (forward geocoding),

координата → город/район (строго по полигонам, point-in-polygon), а не “как вернул геокодер”.Чтобы оценить объём и предложить точное решение, нужно:

10–20 примеров “уехавших” объектов: исходный адрес/город + координаты, куда ставит сейчас;

какие города/страны, и какие данные у карточки гарантированно есть (город? район? индекс?);

где храните данные и чем рисуете карту (PostGIS есть/нет, стек фронта).

После этого дам план работ по этапам и сделаю фикс так, чтобы адрес/город/район определялись максимально стабильно и воспроизводимо, без ручной отрисовки для каждого города. Развернуть

Бюджет: 5000 UAH Срок: 3 дня

Здравствуйте!

Я подробно ознакомилась с вашей задачей. Проблема знакома — сталкивалась с подобным при работе с OSM Nominatim и Mapbox. Вот мое видение:

Почему объекты "летят" на чужие маркеры:

Nominatim возвращает центроид ближайшего найденного объекта, а не точный адрес. Если адрес не найден на уровне дома — он "прыгает" на центр улицы, района или даже города. Это и есть ваши 15% промахов.

Проблема с геокодинг-пирамидой — классический fallback дом → улица → район → город требует валидации на каждом уровне. Нужно проверять importance и class/type в ответе Nominatim, а не просто брать первый результат.

Районы без полигонов — согласна, рисовать вручную для каждого города нереально. Решение: использовать административные границы из OSM (relation boundaries, admin_level=9-10) или GeoJSON районов из открытых источников (data.gov.ua имеет границы для большинства городов). Это даст point-in-polygon проверку без ручной работы.

Мой план:

Аудит текущего pipeline: посмотрю как именно идет fallback и где теряется точность
Добавлю валидацию по boundingbox и type из Nominatim — отсею "широкие" результаты
Подключу обратный геокодинг для перекрестной проверки (координаты → адрес → сравнение с оригиналом)
Для районов — подтяну OSM boundaries через Overpass API или готовые GeoJSON, сделаю point-in-polygon
Настрою confidence score: каждый результат получит оценку точности, чтобы вы видели где 100% совпадение, а где нужна ручная проверка
Результат: 95-98% точность вместо текущих 85%.

У меня есть опыт с Nominatim API, Mapbox Geocoding, Overpass API, Turf.js (геопространственные операции), PostGIS.

Срок: 2-3 дня
Цена: 5000 грн

Готова обсудить детали и посмотреть на текущий код. Развернуть

Бюджет: 5000 UAH Срок: 3 дня

Здравствуйте! Ваш проект выглядит очень интересным. Я готов начать работу немедленно и обеспечить высокое качество.

Бюджет: 5000 UAH Срок: 2 дня

Это типичная история, когда геокодер работает «по строке» без жестких ограничений и без проверки по полигонам.
Чтобы оценить объем и сроки, нужны детали:
География и какие именно «районы» (уровень).
Формат входных данных: отдельные поля или одна строка.
Примеры 5–10 проблемных адресов + что сейчас возвращают Nominatim/Mapbox.
Ожидаемый выход: точка, адрес, район, город, доп. поля.
Ограничения по стеку и инфраструктуре.
Если хотите, сделаю аудит текущего пайплайна и предложу фикс с тестами на вашем наборе кейсов.