Comments 6
А обрабатываете ли вы отдельно станции с выходом/пересадкой в центре платформы?
Ого, интересная задумка! В своё время, когда мы пилили Яндекс.Метро 3.0, помнится, от такой подсказки решили отказаться из-за возможной путаницы: направо из вагона - это куда, прямо из вагона направо по платформе или из вестибюля направо в переход? Плюс такие интересные вещи как лестничный сход над путями (который в идеале "прямо из вагона", а в неидеале - хоть направо, хоть налево, хоть в обход, если вагон прямо под ним), сходы посередине платформы тоже могут оказаться плюс-минус от "ближе к хвосту".
Во-первых, сервер чаще всего ищет маршруты быстрее, чем мобильное приложение (даже с учетом задержек сети из-за большой разницы в производительности сервера и смартфона).
Простите, а что из себя у вас (в плане исходного кода) представляет схема метро? Она может быть представлена как граф или БД станций, линий, трансферов и линков? Если да, то на любом, даже самом слоупочном смартфоне построение оптимального маршрута займёт доли секунды. Обращение к серверу здесь только в минус. Хотя бы потому что при нестабильном, но формально присутствующем соединении программа будет пытаться долго и упорно достучаться до сервера вместо того чтобы обсчитать всё локально.
Во-вторых, данные по городам на серверах обновляются чаще, чем на устройствах пользователей, поэтому они более актуальны (информация о маршрутах, их расписании, перекрытиях на дорогах и прочее).
Это можно реализовать путём фонового обновления данных при наличии подключения.
Вспомним продуктовые требования: необходимо учитывать, что платформа в метро может быть «перевернутой», поэтому в файле роутинга у каждой платформы должен быть задан булевый атрибут is_reversed
Не понял, для чего это нужно. Разве не для каждой пересадки в отдельности указывается направление и вагоны? Если так, то это вообще не нужно. Если не так, то как в общем случае определяется направление выхода - есть параметры типов станций?
Чё-то дичь накрутили :) Если вы сажаете человека в последний вагон — то ему выходить налево, если в первый — то ему выходить направо. В случае перевернутой платформы — наоборот. Для решения задачи достаточно было передать на клиент значение is_reversed и всё.
Вы статью-то читали? Так же и сделали, добавили одно поле. Просто за счёт того, что 2гис работает и в офлайне, и в онлайне, мало просто поменять бэк, фронт и мобильные клиенты, нужны ещё исправления в формате данных и паковщике пакетов данных, с учетом обратной совместимости и зоопарка версий приложения, платформ и данных. А потом как-то уметь протестировать эти компоненты вместе. А потом ещё нужно проследить, что релизы всех этих вещей (которые все в разное время) ничего не сломали, ни на новых клиентах, ни на старых, ни в офлайне, ни в онлайне, и чтобы не менять серьезно версию пакетов, с возможным заделом на прямую совместимость в будущем (иначе придётся раздавать кучу версий тяжелых пакетов, несовместимых между собой и потратить состояние на серверы)
Вот об этом статья.
В вашем городе все станции одинаковые, мелкого заложения с двумя вестибюлями и без пересадок?
Из вагона направо: как работают подсказки 2ГИС