1C-Bitrix Store Locator Development (Map of Shops/Offices)

We often encounter a task: a client asks to add a map with points of sale to the site, but standard Bitrix tools don't allow implementing geolocation search, filtering, and clustering. The result: the user enters a city but sees a list of addresses without a map — poor UX. To solve this, we develop a custom store locator based on infoblocks and a mapping API. Our experience: 10+ years in Bitrix development, 100+ completed projects.

A user wants to quickly find the nearest store and build a route. Without a map, this is impossible. We create a component that stores point coordinates, displays them on a map with clustering, allows filtering by type and city, and also determines the user's location.

How does the store locator on Bitrix work?

Each point of sale is an infoblock element. Key properties — coordinates (LAT/LNG), address, phone, working hours. We add geocoding: when creating a point, coordinates are automatically filled via the Yandex.Geocoder API. This eliminates manual entry and errors.

Why is it important to store coordinates in the infoblock?

Storing LAT/LNG in the infoblock allows performing spatial queries on the PHP side — for example, searching for points within a radius from the user. Without this, you would have to generate coordinates on the fly, which is slow and unreliable. Infoblocks v2.0 with numeric properties give accuracy up to 6 decimal places — enough to identify a specific building.

Storing point of sale data

Minimum set of infoblock element properties:

We get coordinates through geocoding when saving an element. Example event handler OnBeforeIBlockElementAdd:

AddEventHandler('iblock', 'OnBeforeIBlockElementAdd', 'geocodeStoreAddress'); function geocodeStoreAddress(&$arFields) { if ($arFields['IBLOCK_ID'] !== IBLOCK_STORES_ID) return; $address = urlencode($arFields['PROPERTIES']['ADDRESS']['VALUE']); $http = new \Bitrix\Main\Web\HttpClient(); $response = $http->get("https://geocode-maps.yandex.ru/1.x/?apikey=KEY&format=json&geocode=$address"); $data = json_decode($response, true); $coords = $data['response']['GeoObjectCollection']['featureMember'][0]['GeoObject']['Point']['pos']; [$lng, $lat] = explode(' ', $coords); $arFields['PROPERTIES']['LAT']['VALUE'] = $lat; $arFields['PROPERTIES']['LNG']['VALUE'] = $lng; } 

Yandex.Geocoder API is used free of charge up to 25,000 requests per day.

Choosing a mapping API

Comparison of popular solutions:

For Russian projects we use Yandex.Maps — detailed coverage and built-in clustering. Clustering improves performance by 5 times with 200+ points.

Component architecture

The component consists of a PHP backend and a JS frontend. The backend gets the list of points from the infoblock, optionally filters by city or radius. Data is passed to JS via JSON in the script or via an AJAX endpoint.

$res = CIBlockElement::GetList( [], ['IBLOCK_ID' => IBLOCK_STORES_ID, 'ACTIVE' => 'Y'], false, false, ['ID', 'NAME', 'PROPERTY_LAT', 'PROPERTY_LNG', 'PROPERTY_ADDRESS', 'PROPERTY_PHONE', 'PROPERTY_WORKING_HOURS', 'PROPERTY_POINT_TYPE'] ); $points = []; while ($el = $res->GetNext()) { $points[] = [ 'id' => $el['ID'], 'name' => $el['NAME'], 'lat' => (float)$el['PROPERTY_LAT_VALUE'], 'lng' => (float)$el['PROPERTY_LNG_VALUE'], 'address' => $el['PROPERTY_ADDRESS_VALUE'], 'phone' => $el['PROPERTY_PHONE_VALUE'], 'hours' => $el['PROPERTY_WORKING_HOURS_VALUE'], 'type' => $el['PROPERTY_POINT_TYPE_VALUE'], ]; } 

The frontend initializes the map, adds markers with clustering, implements search and filtering. Clustering is mandatory with 50+ points — without it the map lags.

// Yandex.Maps API 3.0 const map = new ymaps3.YMap(document.getElementById('map'), { location: { center: [37.617, 55.755], zoom: 10 } }); const clusterer = new ymaps3.YMapClusterer({ ... }); 

Performance with 500+ points

With a large number of points, passing the entire array in JS is inefficient. Solution:

• Paginated AJAX: load points within the visible map bounds, load more on panning.
• Server-side radius search: filtering in SQL using the haversine formula or PostGIS (if PostgreSQL).
• Caching: the point list rarely changes, cache for 1 hour in b_cache.

SELECT *, (6371 * acos(cos(radians(:lat)) * cos(radians(lat)) * cos(radians(lng) - radians(:lng)) + sin(radians(:lat)) * sin(radians(lat)))) AS distance FROM b_iblock_element_prop_... HAVING distance < :radius ORDER BY distance