Застосунок гірськолижного курорту: карта, скі-пас, GPS-трек

Мобільний застосунок гірськолижного курорту: де ламається

Мобільний застосунок гірськолижного курорту перевіряється не в демо, а на схилі. Карта трас у застосунку довантажує тайли по мережі, а в улоговині та біля верхньої станції зв'язку немає — екран віддає сірі плитки саме в той момент, коли турист вирішує, куди їхати.

Нижче рівня старту телефон переходить у холодний режим, і запит на довантаження просто завершується за таймаутом.

Дорожче за все обходиться збій скі-паса на підйомнику: застосунок читає мітку по радіоканалу, але система встигла вивантажити його з пам'яті, радіомодуль у спокої, а черга невідправлених проходів ніде не збережена.

Черга на підйомнику зростає, частина проходів не враховується — і курорт дізнається про це від туриста, а не зі своєї статистики.

GPS-трек губиться в улоговині: супутники видно, але запис іде лише при живому з'єднанні, а фонова робота жорстко обмежена операційною системою.

Трек рветься, перепад висот і швидкість рахуються неправильно, цифри в особистому кабінеті розходяться з реальним катанням — і довіра до застосунку падає швидше, ніж виправляється помилка.

Корінь усіх трьох відмов один: офлайн-режим на схилі проєктують як тимчасовий виняток, хоча це основний сценарій. Карта, скі-пас і трек мають працювати від локальних даних і синхронізуватися, коли зв'язок з'явиться. Розбираємо, як це закривається на рівні архітектури.

Що дає рішення: карта трас, скі-пас, треки туристів

Карту курорту користувач відкриває на морозі й часто без мережі, тому фрагменти карти та шари трас попередньо завантажуються при першому запуску й лежать у локальному кеші, а оновлення підтягуються невеликими порціями.

Відкриття карти вкладається в секунду-півтори замість п'яти-семи при постійному підвантаженні з мережі, і схема залишається живою там, де зв'язок зникає.

До плавності лінії треку люди звикли за спортивними сервісами на кшталт Strava — розриви та «стрибки» вони читають як поломку застосунку, а не як особливість гір.

Електронний скі-пас у застосунку — окрема відповідальність: ідентифікатор перепустки зберігається на пристрої, прохід підтверджується офлайн, а події накопичуються в черзі й довантажуються, коли мережа повернулася.

Турнікет не «сліпне» при обриві зв'язку, частка успішних проходів тримається вище 99%, і розбір інцидентів на підйомниках перестає бути щоденним завданням підтримки.

Трекінг туриста на схилі будується на буферизації: точки пишуться на пристрій, йдуть пачками при появі мережі, дублі відсікаються за ідентифікаторами.

Частка втрачених треків падає з десятків відсотків до одиниць, а служба безпеки бачить останнє відоме місцеположення, навіть якщо людина пішла в «мертву» зону.

Високий сезон — це пікові вихідні, коли навантаження зростає в рази за годину. Горизонтальне масштабування, кеш на межі та розділення термінових і фонових запитів тримають відгук рівним, тому звернень до підтримки з формулюванням «застосунок не працює» стає на порядок менше.

Способи реалізації: нативна збірка, оболонка, веб-версія

Вибір варіанта визначається трьома умовами: робота при від'ємних температурах, автономність без мережі на схилі та прямий зв'язок зі зчитувачами скі-пасів на турнікетах.

Нативний застосунок отримує доступ до модулів зв'язку та енергозбереження — карта залишається чутливою на морозі, а заряд не йде за половину дня катання.

Кросплатформна збірка дешевша в супроводі, але частина системних обмежень знімається лише окремими модулями під кожну платформу.

Ключове питання — наскільки близько застосунок підходить до обладнання. Зчитування скі-паса, перевірка права проходу та запис події потребують або нативного шару, або готового набору від постачальника турнікетів.

Веб-версія хороша як вітрина, розклади та продаж скі-пасів, але робота без мережі й зі зчитувачем у ній урізана.

На практиці частіше беруть змішану схему: продаж та інформація — веб, схил і доступ на підйомники — нативне ядро. Так сумісність із системами доступу не залежить від обмежень платформи.

Етапи роботи: від аудиту трас до передачі доступів

Робота починається з аудиту даних про підйомники та траси: з'ясовуємо, які системи курорту віддають стан черг, статуси відкриття та розклади, з якою частотою, у якому форматі й хто власник кожного поля.

Паралельно фіксуємо картографічну основу — чиї тайли та схеми трас використовуємо, як часто вони змінюються і що робити, коли розходяться з реальністю на схилі.

1. Аудит даних про підйомники та траси. Збираємо перелік джерел, звіряємо ідентифікатори підйомників і трас з фактичними табличками на місцевості, домовляємося про правило пріоритету, якщо ручна правка диспетчера суперечить вивантаженню.
2. Схема обміну із системами курорту. Описуємо контракти: що запитуємо, що кешуємо локально, як перевіряємо справжність скі-паса і що показуємо гостю, якщо зв'язку немає.
3. Карта та офлайн-шар. Збираємо стилі, зони, шари небезпеки та точки інтересу, рахуємо вагу пакета так, щоб застосунок завантажувався по мобільній мережі й відкривався за -20 °C без мережі.
4. Збірка та автотести. Розводимо модулі карти, скі-паса та треку, покриваємо перевірками розбір станів підйомників, склейку GPS-треку та відновлення після розриву.
5. Перевірка на схилі. Виїзд із реальними підйомниками: холод, рукавички, перехід між вишками зв'язку, звірка записаного треку з еталонним логом і розбір розбіжностей за підйомами та спусками.
6. Передача доступів. Віддаємо репозиторії, ключі підпису, акаунти магазинів, доступи до систем курорту, схему обміну та інструкцію для чергового — із записом навчальної сесії.

Після кожного етапу фіксуємо результат у документі, який залишається у замовника: він же стає основою для наступної ітерації, коли курорт змінює траси або додає підйомник.

Комплект передачі: схеми, регламенти, доступи, документація

Застосунок курорту тримається не на екранах, а на зв'язках із внутрішніми системами: продаж скі-пасів, турнікети, довідник трас, прокат. Якщо ці зв'язки описані лише в листуванні, кожне оновлення схилів або тарифів упирається в простій. Тому в комплект передачі ми кладемо документи, за якими ваша служба працює без нас.

• Схема інтеграцій: які системи обмінюються даними, у якому форматі, з якою періодичністю і що відбувається при недоступності джерела.
• Документація на застосунок: склад модулів, вимоги до середовища збірки, список зовнішніх залежностей і порядок випуску в магазини застосунків.
• Ролі та доступи в панелі: матриця «роль — розділ — дія» для прокату, диспетчера схилів, маркетингу та підтримки; окремо — хто має право змінювати тарифи та публікувати статус траси.
• Регламент оновлення карти: звідки береться підкладка, як завантажуються шари трас і підйомників, хто погоджує і як перевіряється коректність до публікації.
• Інструкція для служби прокату: зміна, видача та повернення інвентарю, позначка пошкоджень, розбір спірних списань.
• Регламент випуску та відкату: хто підписує оновлення, як повернути попередню версію, якщо збірка ламає карту, оплату або скі-пас.
• Точки контролю та оповіщень: що перевіряється, при яких порогах іде сигнал і кому він адресований уночі.

Документи пишемо під ваші процеси — з назвами ваших відділів і реальними обліковими записами. Після передачі залишаємося на зв'язку за регламентом супроводу, щоб логіку не доводилося відновлювати за кодом.

Кейс: карта трас і скі-пас для гірського курорту

Курорт із кількома зонами катання та десятками трас прийшов із двома пов'язаними проблемами: гість на схилі не розумів, де він перебуває і як повернутися до потрібного підйомника, а прохід через турнікет залежав від якості зв'язку.

Пластиковий скі-пас при втраті відновлювали лише в касі, а карта трас підвантажувалася із сервера — у роумінгу та на морозі вона або не відкривалася, або відкривалася вже після того, як людина встигала поїхати не туди.

Що змінили

Карту перевели в офлайн-пакет: векторні шари трас, підйомників і точок харчування завантажуються на пристрій і оновлюються при появі зв'язку, тому на екрані вона з'являється миттєво і працює без мережі.

Скі-пас прив'язали до профілю гостя, а події проходу почали накопичуватися в локальній черзі: якщо зв'язку немає, прохід все одно фіксується і йде на сервер пізніше, без повторного прикладання.

Той самий скі-пас поклали в Apple Wallet — гостю не потрібен пластик, а турнікету не потрібен постійний канал до сервера.

Метрики до та після

Навантаження на підтримку перестало зростати разом із потоком гостей: питання «де я» та «не працює скі-пас» пішли з першої лінії, а решта звернень стосується переважно повернень та абонементів.

Цей кейс гірськолижного курорту задав нам типовий набір рішень — офлайн-карта, скі-пас у профілі, прохід, стійкий до втрати зв'язку, — і ми переносимо його на схожі об'єкти: від невеликих схилів до курортів із кількома зонами катання.

Чим офлайн-карта відрізняється від онлайн-підвантаження даних?

Офлайн-карта — це пакет тайлів і схеми трас, який лежить у файловому сховищі застосунку і не залежить від мережі.

Він завантажується один раз перед поїздкою, розпаковується локально і малюється з пам'яті пристрою; онлайн-підвантаження натомість запитує тайли в міру руху і при кожній зміні масштабу.

На схилі стабільного каналу немає: рельєф, ліс, перевантаження мережі в годину пік на підйомнику обривають з'єднання на хвилини. У цей момент онлайн-карта недомальовується — тайли приходять із затримкою або не приходять зовсім, а трек отримує розриви, які потім не відновити.

Оновлення офлайн-пакета — окремий крок: застосунок звіряє версію локального набору із серверною, забирає лише змінені ділянки по каналу, що з'явився, і підміняє файл після перевірки цілісності.

Турист не потрапляє в ситуацію, коли карта завантажена наполовину: або працює попередня версія, або нова цілком.

У сховищі на пристрої тримаємо схему трас і підйомників, точки інтересу, довідник і службові шари — це одиниці мегабайт, вони не конкурують із фото та відео.

Трек і позначки пишуться в локальну чергу і йдуть на сервер при першій доступній мережі, тому втрата сигналу на схилі не перетворюється на втрачені дані.

Для туриста різниця видна в перші секунди: офлайн-карта відкривається миттєво й однаково в підйомнику, в лісі та в низині, пошук траси та точки збору працюють без очікування. Онлайн-режим залишаємо довідковим шарам — погода, розклад, акції, — які не критичні в момент руху.

Часті технічні питання до старту робіт

Перед стартом зазвичай перевіряють три речі: як застосунок поводиться поза зоною покриття, хто оновлює схему трас кожного сезону і чи доведеться міняти обладнання на підйомниках. Нижче — відповіді в тому вигляді, у якому ми обговорюємо їх на етапі оцінки.

Що відбувається, коли траси змінюють кожного сезону?

Схема трас, рівні складності та точки інтересу зберігаються як дані, а не як частина коду. Нова конфігурація завантажується із сервера, і застосунок підхоплює її без перевипуску в магазинах застосунків. Для служби курорту робимо простий редактор — правки вносяться без участі розробника.

Як застосунок пов'язаний із системою скі-пасів?

Підключаємося до тієї системи доступу, що вже працює на підйомниках, і читаємо статус скі-паса через її штатні точки доступу. Міняти турнікети та перевипускати картки не потрібно — застосунок вбудовується в наявний контур.

Хто відповідає за оновлення після запуску?

Випуск під нові версії мобільних ОС, моніторинг збоїв, оновлення даних про траси та чергування у високий сезон. Регламент і час реакції фіксуємо в договорі супроводу до старту робіт.

Обговоримо задачу та повернемося з оцінкою і планом

Щоб обговорити задачу та повернутися з оцінкою і планом робіт, а не із загальними міркуваннями, нам потрібні вихідні дані для старту. Нижче — мінімум, який знімає більшість невідомих; якщо чогось не знайдеться, підкажемо, чим замінити і як зібрати це по ходу проєкту.

• Схема трас із прив'язкою до місцевості: межі ділянок, перепади висот, точки старту та фінішу підйомників — на них будується і карта, і запис треку.
• Правила та обмеження курорту: закриті зони, лавинна обстановка, розклад підйомників — від них залежить логіка оповіщень на схилі.
• Доступ до системи контролю доступу та скі-пасів: тестовий контур, вивантаження проходів, спосіб перевірки справжності носія. Без цього не зібрати ні баланс, ні статистику катання.
• Перелік сценаріїв, важливих саме вам: купівля скі-паса, трек, погода, оповіщення, бронь лижної школи — розкладемо їх за етапами та оцінимо кожен.
• Контакт служби експлуатації на стороні курорту: людина, яка знає, як працює обладнання на підйомниках і до кого звертатися при збої.
• Матеріали бренду та вимоги до оформлення, якщо застосунок виходить під вашим ім'ям.
• Чинні системи продажів, обліку клієнтів і погодний сервіс — назвіть ті, що вже використовуються, і ми погодимо формат обміну даними.

Зі свого боку розберемо те, що ви надіслали, уточнимо спірні місця та повернемося з етапами, строками і складом робіт по кожному. Опишіть задачу — відповімо з конкретикою по вашому курорту.