Уявіть: користувач заходить на сторінку «Магазини», бачить список із 30 адрес, відсортованих за алфавітом. Він живе в Мінську, а перші п'ять — Москва. Клієнт іде до конкурента, де геолокація працює. Ми стикалися з таким завданням десятки разів: клієнт із Єкатеринбурга бачить першим магазин у Пітері, тому що в Бітрікс немає вбудованого сортування за відстанню. Визначення найближчого магазину — банальне, здавалося б, завдання — впирається в точність координат, їх зберігання та алгоритм розрахунку. У 1С-Бітрікс це завдання вирішується комбінацією IP-геолокації для первинного сортування та браузерного API для точності до 50 метрів. Ми пропонуємо налаштування модуля геолокації — ви отримуєте готовий компонент з документацією, який ми адаптуємо під вашу мережу. З таким доопрацюванням конверсія в офлайн-візити зростає в середньому на 15–20%. Вартість розраховується індивідуально під ваші завдання — економія на самостійній реалізації очевидна.
Як зберігати координати магазинів у Бітрікс?
У Бітрікс магазини зберігаються у двох місцях залежно від використовуваного функціоналу.
Модуль sale, торгові точки: таблиця b_sale_store з полями ID, TITLE, ADDRESS, GPS_N (широта), GPS_S (довгота). Це стандартна структура для точок самовивозу. Наприклад, для мережі з 200 магазинів поля вже заповнені при інтеграції з 1С — залишається тільки їх використовувати.
Інфоблок магазинів: якщо магазини оформлені як елементи інфоблоку, координати зазвичай зберігаються в користувацьких властивостях. Для розрахунку відстаней потрібні числові координати. Якщо вони записані у рядок виду «53.9045, 27.5615» — при вибірці їх доведеться парсити, що незручно. Правильне рішення: зберігати широту та довготу у двох окремих числових властивостях або використовувати b_sale_store.GPS_N / b_sale_store.GPS_S.
Вибір між зберіганням у модулі sale та інфоблоці залежить від архітектури. Для точок самовивозу зручніше таблиця b_sale_store: поля координат вже є, вибірка швидка, інтеграція з 1С через CommerceML працює з коробки. Але якщо магазини — елементи інфоблоку з додатковими реквізитами (години роботи, контакти, фотографії), то простіше додати дві числові властивості для широти та довготи. У цьому випадку при вибірці не потрібно парсити рядки — запити виконуються в 3-4 рази швидше, ніж при рядковому зберіганні.
Що вибрати: IP-геолокацію чи браузерну?
У кожного методу свої сильні та слабкі сторони. У таблиці нижче — порівняння за ключовими параметрами.
| Параметр | IP-геолокація | Браузерна (Geolocation API) |
|---|---|---|
| Точність | Місто/район (1–10 км) | До 50 метрів |
| Вимагає дозволу | Ні | Так |
| Швидкість | Миттєво (серверна) | Асинхронно (1–2 секунди) |
| Використання при серверному рендерингу | Так | Ні |
Браузерна геолокація точна, але вимагає дозволу користувача та асинхронна — не можна використовувати при серверному рендерингу. IP-геолокація працює без запиту дозволу, точність — до міста/району. У Бітрікс вбудований модуль location з базою GeoIP. Метод \Bitrix\Main\Service\GeoIp\Manager::getLocationByIp() повертає приблизні координати.
$location = \Bitrix\Main\Service\GeoIp\Manager::getLocationByIp( \Bitrix\Main\Context::getCurrent()->getRequest()->getRemoteAddress() ); $userLat = $location['LATITUDE'] ?? null; $userLon = $location['LONGITUDE'] ?? null; Комбінуйте: спочатку IP, потім AJAX з браузерними даними. Це дає миттєвий результат при завантаженні, а через 1–2 секунди — точне сортування.
Розрахунок відстаней: формула Гаверсина в SQL
Найефективніший підхід — рахувати відстані прямо в SQL-запиті. Формула Гаверсина для PostgreSQL:
SELECT id, title, gps_n AS lat, gps_s AS lon, ( 6371 * acos( cos(radians(:user_lat)) * cos(radians(gps_n)) * cos(radians(gps_s) - radians(:user_lon)) + sin(radians(:user_lat)) * sin(radians(gps_n)) ) ) AS distance_km FROM b_sale_store WHERE active = 'Y' AND gps_n IS NOT NULL AND gps_s IS NOT NULL ORDER BY distance_km LIMIT 5; Для MySQL синтаксис аналогічний. На PostgreSQL додатково можна використовувати розширення earthdistance з cube, що швидше для великих наборів точок. Через ORM Бітрікс прямий SQL викликається через \Bitrix\Main\Application::getConnection()->query(). Готового виразу Гаверсина в D7 ORM немає — доведеться використовувати ExpressionField з raw SQL або нативний запит.
Як працює формула Гаверсина
Формула Гаверсина обчислює відстань між двома точками на сфері за їх широтою та довготою. Вона враховує кривизну Землі, що дає точність до 0.5% на відстанях до 100 км.Фронтенд: два кроки
- При завантаженні сторінки — показуємо магазини, відсортовані за IP-геолокацією (серверне сортування, миттєво).
- Після отримання точних координат через
navigator.geolocation.getCurrentPosition()— пересортовуємо через AJAX-запит до компонента з параметрамиlatіlon.
navigator.geolocation.getCurrentPosition(function(pos) { fetch('/ajax/nearest-stores/?lat=' + pos.coords.latitude + '&lon=' + pos.coords.longitude) .then(r => r.json()) .then(stores => renderStoreList(stores)); }); Компонент-обробник AJAX читає lat/lon з GET, виконує SQL з Гаверсином, повертає JSON. У Бітрікс це реалізується через компонент з параметром ajax_mode = Y або через власний endpoint у /local/ajax/.
Етапи реалізації геолокації
- Аудит поточних даних магазинів — перевіряємо заповнення координат, активність точок.
- Створення або доопрацювання інфоблоку / торгових точок — додаємо числові властивості для широти та довготи.
- Реалізація SQL-запиту з формулою Гаверсина — для сортування за відстанню.
- Інтеграція IP-геолокації через
GeoIp\Manager— для початкового завантаження. - Створення AJAX-endpoint для браузерної геолокації — для точного пересортування.
- Розробка компонента виведення та сортування магазинів — з урахуванням кешування.
- Кешування результату для кожної пари координат — з округленням до 0.01 градуса, щоб зменшити кількість унікальних запитів.
- Передача налаштувань та документації.
Що входить у роботу
- Аудит існуючих торгових точок та координат
- Доопрацювання інфоблоку або таблиць для зберігання числових координат
- Реалізація SQL-запиту з формулою Гаверсина (з можливістю розширення earthdistance)
- Інтеграція IP-геолокації через
GeoIp\Manager - Розробка AJAX-endpoint для браузерної геолокації
- Створення компонента виведення з динамічним сортуванням та тегованим кешуванням
- Налаштування кешування з округленням координат
- Передача документації та навчання співробітників
Оптимізації для прискорення запитів
| Оптимізація | Ефект |
|---|---|
| Індекс на поля GPS_N, GPS_S | Прискорення сортування в 5-10 разів |
| Кешування результатів за округленими координатами | Зниження навантаження на БД на 70% |
| Використання розширення earthdistance в PostgreSQL | До 3 разів швидше для 1000+ точок |
Наша команда має понад 10 років досвіду у розробці на 1С-Бітрікс. Ми реалізували геолокацію для мереж від 5 до 300 магазинів (загалом понад 40 проектів). Одного разу ми за 3 дні налаштували компонент для федеральної мережі: IP-геолокація при завантаженні, потім браузерна — конверсія в офлайн-візити зросла на 15%. Ми даємо гарантію на код і підтримуємо після впровадження. Отримайте консультацію — оцінимо ваш проект і запропонуємо терміни від 2 до 5 днів.