מיקום חנות ב-1C-Bitrix: הגדרה ומיון

תארו לעצמכם: משתמש נכנס לעמוד 'חנויות' ורואה רשימה של 30 כתובות ממוינות לפי סדר אלפביתי. הוא גר במינסק, אבל חמש הראשונות הן מוסקבה. הלקוח עוזב למתחרה שיש לו גיאולוקציה עובדת. נתקלנו במשימה הזו עשרות פעמים: לקוח מיקטרינבורג רואה חנות בסנט פטרסבורג ראשונה, כי לביטריקס אין מיון מובנה לפי מרחק. מציאת החנות הקרובה ביותר—שנראית טריוויאלית—מסתכמת בדיוק הקואורדינטות, האחסון ואלגוריתם החישוב. ב-1C-Bitrix, בעיה זו נפתרת על ידי שילוב של גיאולוקציית IP למיון ראשוני ו-API של הדפדפן לדיוק של עד 50 מטר. אנו משלבים את מודול הגיאולוקציה ומספקים רכיב מוכן עם תיעוד, המותאם לרשת שלכם. עם שיפור זה, שיעור ההמרה של ביקורים פיזיים בדרך כלל עולה ב-15–20%. העלות נקבעת לאחר ניתוח הדרישות הספציפיות שלכם—החיסכון בהשוואה ליישום עצמי ברור.

כיצד לאחסן קואורדינטות חנות בביטריקס?

בביטריקס, חנויות מאוחסנות בשני מקומות בהתאם לפונקציונליות שבה משתמשים.

• מודול המכירות, נקודות מסחר: טבלת b_sale_store עם שדות ID, TITLE, ADDRESS, GPS_N (קו רוחב), GPS_S (קו אורך). זהו המבנה הסטנדרטי לנקודות איסוף. לדוגמה, עבור רשת של 200 חנויות, השדות כבר ממולאים במהלך אינטגרציית 1C—פשוט השתמשו בהם.

• בלוק מידע של חנות: אם חנויות הן אלמנטים של בלוק מידע, קואורדינטות בדרך כלל מאוחסנות במאפייני משתמש. לחישוב מרחק, יש צורך בקואורדינטות מספריות. אם הן מאוחסנות כמחרוזת כמו "53.9045, 27.5615", יש לנתח אותן במהלך שאילתות—וזה לא נוח. הגישה הנכונה היא לאחסן קו רוחב וקו אורך בשני מאפיינים מספריים נפרדים, או להשתמש ב-b_sale_store.GPS_N / b_sale_store.GPS_S.

הבחירה בין אחסון במודול המכירות לבין בלוק מידע תלויה בארכיטקטורה. עבור נקודות איסוף, טבלת location נוחה יותר: שדות קואורדינטות כבר קיימים, שאילתות מהירות, ואינטגרציה עם 1C דרך CommerceML עובדת ישירות מהקופסה. עם זאת, אם חנויות הן אלמנטים של בלוק מידע עם מאפיינים נוספים (שעות פעילות, אנשי קשר, תמונות), קל יותר להוסיף שני מאפיינים מספריים לקו רוחב וקו אורך. במקרה זה, שאילתות רצות פי 3-4 מהר יותר מאשר עם אחסון מחרוזת.

מה לבחור: גיאולוקציית IP או גיאולוקציית דפדפן?

לכל שיטה יש את החוזקות והחולשות שלה. הטבלה שלהלן משווה פרמטרים מרכזיים.

גיאולוקציית דפדפן מדויקת אך דורשת הרשאת משתמש והיא אסינכרונית—לא ניתן להשתמש בה בעיבוד בצד השרת. גיאולוקציית IP עובדת ללא הרשאה; הדיוק הוא ברמת עיר/אזור. לביטריקס יש מודול \Bitrix\Main\Service\GeoIp\Manager::getLocationByIp() מובנה עם מסד נתונים של GeoIP. השיטה $location = \Bitrix\Main\Service\GeoIp\Manager::getLocationByIp( \Bitrix\Main\Context::getCurrent()->getRequest()->getRemoteAddress() ); $userLat = $location['LATITUDE'] ?? null; $userLon = $location['LONGITUDE'] ?? null; מחזירה קואורדינטות משוערות.

$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, ניתן גם להשתמש בהרחבה 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; עם earthdistance, שהיא מהירה יותר עבור קבוצות נקודות גדולות. כדי לקרוא SQL גולמי דרך Bitrix ORM, השתמשו ב-cube. אין ביטוי האוורסין מובנה ב-D7 ORM; תצטרכו להשתמש ב-\Bitrix\Main\Application::getConnection()->query() עם SQL גולמי או שאילתה מקורית.

צד לקוח: שני שלבים

1. בטעינת העמוד—הצגת חנויות ממוינות לפי גיאולוקציית IP (מיון בצד השרת, מיידי).
2. לאחר קבלת קואורדינטות מדויקות דרך ExpressionField—מיון מחדש באמצעות בקשת AJAX לרכיב עם פרמטרים navigator.geolocation.getCurrentPosition() ו-lat.

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 קורא 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)); }); מ-GET, מבצע את ה-SQL עם האוורסין, ומחזיר JSON. בביטריקס, זה מיושם דרך רכיב עם פרמטר lat או נקודת קצה מותאמת אישית ב-lon.

שלבי יישום לגיאולוקציה

1. ביקורת נתוני חנות נוכחיים—בדיקת שלמות קואורדינטות, נקודות פעילות.
2. יצירה או שינוי של בלוקי מידע / נקודות מסחר—הוספת מאפיינים מספריים לקו רוחב וקו אורך.
3. יישום שאילתת SQL עם נוסחת האוורסין—למיון לפי מרחק.
4. אינטגרציית גיאולוקציית IP דרך ajax_mode = Y—לטעינה ראשונית.
5. יצירת נקודת קצה AJAX לגיאולוקציית דפדפן—למיון מחדש מדויק.
6. פיתוח רכיב תצוגה ומיון—תוך התחשבות במטמון.
7. שמירת תוצאה במטמון עבור כל זוג קואורדינטות—על ידי עיגול ל-0.01 מעלות להקטנת שאילתות ייחודיות.
8. מסירת הגדרות ותיעוד.

מה כלול בעבודה

• ביקורת נקודות מסחר וקואורדינטות קיימות
• שינוי בלוק מידע או טבלאות לאחסון קואורדינטות מספריות
• יישום שאילתת SQL עם נוסחת האוורסין (עם אפשרות להרחבת earthdistance)
• אינטגרציית גיאולוקציית IP דרך /local/ajax/
• פיתוח נקודת קצה AJAX לגיאולוקציית דפדפן
• יצירת רכיב תצוגה עם מיון דינמי ומטמון מתויג
• הגדרת מטמון עם עיגול קואורדינטות
• מסירת תיעוד והדרכת צוות

אופטימיזציות להאצת שאילתות

לצוות שלנו יש ניסיון של למעלה מ-5 שנים בפיתוח 1C-Bitrix. יישמנו גיאולוקציה עבור רשתות הנעות בין 5 ל-300 חנויות. פעם אחת, הגדרנו את הרכיב עבור רשת ארצית ב-3 ימים: גיאולוקציית IP בטעינה, ואז גיאולוקציית דפדפן—שיעור ההמרה של ביקורים פיזיים עלה ב-15%. אנו מספקים אחריות על הקוד ומציעים תמיכה לאחר היישום. צרו קשר לייעוץ—נעריך את הפרויקט שלכם ונציע לוח זמנים של 2 עד 5 ימים.