Как создать сервис по оценке транспортной доступности новостроек при горящих дедлайнах

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет, Habr! Меня зовут Руслан Габдрахманов, я руководитель команды разработки информационных систем в «МосТрансПроекте». Сегодня расскажу, как мы создавали городской сервис «Узнай про ЖК», упрощающий выбор квартиры в новостройке. 

По статистике количество сделок по купле продаже квартир в Москве растет. Выбирая себе новый дом, каждый из нас обращает внимание на транспортную доступность: это один из важнейших критериев при выборе жилья. Есть ли рядом метро или МЦК? Сколько идти пешком? Есть ли рядом автобусная остановка? А что с парковками? А социальная инфраструктура – поликлиники, детские сады? Где погулять с собакой?

Раньше каждый раз приходилось залезать в поисковики, самостоятельно прикидывая, насколько удобно тот или иной дом расположен. Некоторое время назад родилась идея: почему бы не собрать воедино информацию обо всех ЖК (новых и строящихся), создав городскую систему оценки их транспортной доступности. 

Идея – это, конечно, неплохо, но вопрос в реализации. Ведь институт работал над системой оценки ЖК на протяжении нескольких лет, но в начале 2022 года по ряду причин мы остались без команды разработки. А дедлайн был, на секундочку, сентябрь. Нужно было срочно набирать новую команду, и процесс этот, конечно, требовал времени.

Наработки с прошлой команды остались, но фактически все пришлось делать с нуля. Обсуждение новой концепции и методики, смысла и дизайна сервиса заняло примерно 2-3 месяца. В какой-то момент мы отказались от всевозможных сложных надстроек, обсуждавшихся ранее (к примеру, планировались некие личные кабинеты для застройщиков): решили просто оценивать новостройки, их местоположение, ранжировать их внутри рейтингов, мотивируя застройщиков строить еще более удобное жилье. С дизайном нам очень помогало креативное бюро ONY, с которыми мы заключили партнерское соглашение по работе с сервисом. Захватывающую историю про то, как придумывали саму методику оценки ЖК, расскажем в отдельной статье – этот кейс действительно стоит того.

Параллельно я анализировал то, что уже было сделано ранее. Был частично готов Backend и Frontend, но бекенд был написан на go. Мы посмотрели на рынок зарплат и те условия, которые мы могли на тот момент выдвигать, и в итоге приняли решение переделать все на php. Фронт решили делать на react.js, потому что кандидатов на рынке с этим стеком было больше. При создании баз данных мы переиспользовали наработки прошлой команды, они были сделаны на базе postgresql + postgis. Для удобства решили положить сервис сразу в docker, чтобы упростить разворачивание сервиса на серверах и машинах разработчиков + упростить соседство с другими проектами на машинах там, где это потребуется. Для документации по разрабатываемому API использовали swagger + создали общие коллекции для postman. Фронтенд решили сделать в виде SPA для того, чтобы всё точно быстро работало в браузерах пользователей, хотя это и накладывало на нас определённые ограничения в разработке.

По ходу пьесы пришлось решать много разных задач, порой нетривиальных. Нам, например, нужны были данные о расположении разных объектов – парковок, остановок, парков, станций метро, МЦК и т.д. Оказалось, что все это собрано в разных дата-сетах, принадлежащих разным городским структурам, и поженить их в один было непросто. Одна и та же парковка, например, могла быть в одном и том же месте в трех разных дата-сетах и по-разному оформлена. Нужно было разбираться, это один и тот же объект или три похожих рядом. И так было почти по всем данным. Мы пробовали разрабатывать методики очистки данных, но от них впоследствии отказались, так как нашли более изящное решение (о нем расскажу чуть позже). 

Еще одна проблема – это проекция данных или, другими словами, метод записи координат объектов. Этих проекций очень много разных видов и все сервисы используют разные (например, WGS84 или Pulkovo 1942). Когда мы начали все данные накладывать на одну подложку, начались откровенные косяки. Потому что одни объекты из одного дата-сета размещались изначально под одну систему (например, под карты «Яндекса»), другие, к примеру, под Open Street Map или Google. Когда ты все это соединяешь вместе и кладешь на одну подложку, часть данных «едет»: например, остановка внутри дома оказывается или посреди дороги. 

Следующий вопрос – это маршрутизатор. Это, грубо говоря, программа, которая анализирует весь граф дорог, пешеходных путей, видов транспорта, позволяя строить путь от точки А в точку Б. Собственного инструмента у нас не было, времени на то, чтобы разработать свое, не оставалось. Здесь нам пригодилась помощь наших партнеров 2ГИС с уже готовой картой и маршрутизатором. Всю «петрушку» данных, которая у нас была по итогам работы с дата-сетами, мы адаптировали под единую подложку 2ГИС. У них, кстати, был свой дата-сет из остановок, парковок и т.д. - мы написали скрипты, сметчили их данные с нашими, положили на общую основу. Получилось неплохо. Партнерством с 2ГИС мы также частично закрыли некоторые вопросы с проекцией данных, съезжающими остановками и т.д. 

Периодически приходилось вручную «донастраивать» получившиеся карты. У нас, к примеру, был случай, когда остановка автобуса находилась вроде бы в пешей доступности (и показывалась, как «ближайшая» к конкретному ЖК), а по факту была вообще на другой стороне реки. Другой курьез –когда среди ближайших к одному из домов «социальных» объектов наш рейтинг показал наркологический центр. Этот баг мы исправили сужением выборки: теперь в пешей доступности показываются только поликлиники и больницы общего профиля.

Теперь про то, откуда мы брали информацию про дома и ЖК. Мы пробовали много разных подходов. Сначала мы запрашивали информацию у стройкомплекса Москвы, но этого оказалось недостаточно: там хорошая проектная документация, но она не всегда хорошо ложится на карту. Потом писали парсеры «Циана», каких-то еще источников данных. В итоге получился вариант из серии «всего понемногу». Мы все это вручную собрали, обработали, сформировали итоговый список домов для оценки. Эта работа, кстати, и сейчас так происходит – у нас есть отдельные люди, мониторящие новостройки и пополняющие базу данных. Здесь сразу надо оговорится, что из-за сжатых сроков запуска мы взяли дома, сданные после 2021 года включительно или которые будут сданы в ближайшее время. 

Итого. Чистый срок разработки сервиса составил месяцев пять, но поскольку дата релиза несколько раз смещалась, мы постоянно вносили какие-то правки и улучшения. В январе 2023 года, наконец, запустились в режиме MVP. Подробно описывать, как устроены получившиеся рейтинги и система оценки здесь не буду – все подробности есть на https://uznai.mos.ru/.

Что будет с сервисом дальше?

Во-первых, в систему постоянно добавляются новые объекты, это процесс никогда не останавливался. В идеальном мире нам бы хотелось оценить буквально каждое жилое здание в Москве. Также планируем расширять список наших партнеров – скоро наш модуль появится в Единой информационной системе жилищного строительства, идут переговоры с другими агрегаторами недвижимости. 

Планируем добавить разных «фишек». Например, тепловую карту, которая покажет, насколько далеко можно дойти за 5-10 минут от той или иной точки. Эта такая прикольная и полезная штука, дающая представление о состоянии пешеходной инфраструктуры в конкретном районе. 

Думаем и про различные «тонкие» настройки. Сегодня «Узнай про ЖК» построен на базе центростремительной модели, иными словами, мы исходим из того, что утром все едут на работу в центр, а вечером из центра. Действительно, большинство людей (60-70%, мы это видим по матрице корреспонденций) передвигаются именно так. При этом жители определенных районов в центр почти не ездят: они там живут и работают, за пределы редко выезжают. На каком-то этапе, еще до релиза, мы обсуждали, что с этим делать и как учитывать, но в рамках МVP решения пока оставили центростремительную модель. Возможно, в начале следующего года методика в этой части изменится и можно будет задавать персональные настройки адреса работы.

Есть еще один момент, связанный с остановками городского транспорта. Сейчас наличие остановки в принципе рядом с домом дает «плюс» дому и, соответственно, более высокий балл. Но на самом деле ценность у них разная. Например, одна остановка находится совсем рядом с домом, но через нее проходит только один маршрут в соседний район и обратно. А в 10 минутах есть другая остановка, через которую проходит 10 разных маршрутов, благодаря которым можно добраться оттуда до любой точки Москвы. Есть ведь разница? Мы это понимали еще до релиза, но тогда сознательно пошли по пути упрощения. Это мы тоже хотим поменять: более гибко учитывать и оценивать «качество» транспортных объектов. 

Работа над проектом «Узнай про ЖК» дала нам, конечно, почву для дальнейших размышлений. Проблема с объединением дата-сетов, о которой я рассказывал выше, навела нас на мысль провести полную инвентаризацию данных внутри транспортного комплекса – так родился проект Data Project, которым мы сегодня активно занимаемся. О нем мы уже рассказали здесь

Источник: https://habr.com/ru/companies/mostransproekt/articles/782256/


Интересные статьи

Интересные статьи

Благодаря фидам поисковые алгоритмы показывали пользователям товары, которые больше всего соответствуют их запросам. Они включают информацию о продуктах и помогают экономить время при создании объявле...
Словарь - это абстрактный тип данных, который связывает ключи со значениями. Его ещё называют ассоциативный массив, карта, таблица символов, коллекция. Будет две статьи на эту тему, где мы покажем шес...
Критическая уязвимость в Java, в библиотеке log4j, которая используется в тысячах сервисов, начиная от Minecraft и заканчивая Apple Cloud, быстро превращается в серьезную угрозу для организаций по...
У меня скоро день рождения и я решил таки дописать статью, которую задумал лет 8 назад. Лучше поздняк пометаться, чем никогда, да и закрыть гештальт напрочь. Хотя сейчас ...
Для тех, кто интересуется темой автоматизации на iOS, у меня две новости — хорошая и плохая. Хорошая: в iOS-приложении для платных сервисов используется только одна точка интеграции — in-app purc...