Пересмотр структуры для порталов и пересадок

[simgislab]

From @Zverik on September 16, 2013 7:14

Порталы и пересадки — суть одно и то же: пешеходный переход из точки A в точку B. Для пересадок A и B — идентификаторы станций, для порталов B — выход. При этом ограничения по направлению важны там и там: например, между станциями на пересадке может быть однонаправленный эскалатор.

Таблица portals.csv будет отдана только под описание выходов: останутся столбцы id_entrance;name;lat;lon. Привязывать выходы к станциям возможно не везде, но для удобство в поле name можно хранить название станции (я так и делаю).

Идентификаторы выходов должны быть в одном пространстве с идентификаторами станций, т.е. не пересекаться с ними. Это можно сделать постобработкой данных google docs.

Таблицу interchanges.csv нужно переименовать в routes.csv (так проще), состав колонок до max_width (см. #18) будет таким: id_from;id_to;direction;name. Здесь идентификаторы могут быть как станций, так и выходов. Кроме того, могут быть фиктивные идентификаторы для обозначения промежуточных точек: например, для выходов в подземные переходы можно разбить путь до двери и путь до поверхности.

При необходимости (хотя есть ли она?) можно добавить таблицу для фиктивных идентификаторов virtual.csv со столбцами id_virtual;name.

Copied from original issue: nextgis/metro4all#20

[simgislab]

From @BishopGIS on September 16, 2013 7:48

Мне подход не нравится. Сейчас в мобильном приложении данные считываются в 2 массива. Для поиска препятствий для входа идет обход одного массива, для пересадок - другого. Если их соединить, то обход будет занимать гораздо больше времени + сложнее определять, где входы, а где пересадки (сейчас это разделено на уровне файлов и проблем с этим нет).
Возможно стоит заполнять данные в одном месте (хотя и здесь не вижу удобства), но на выходе надо генерировать 2 csv файла.

[simgislab]

From @Zverik on September 16, 2013 9:4

Я всё, включая станции, входы и роутинг между ними, рисую в josm, поэтому для меня особой разницы нет. Вопрос в сложных случаях: например, очень часто на пересадочных станциях входы нельзя однозначно отнести к какой-либо станции. Поэтому в portals.csv столбец с идентификатором станции запутывает. Плюс получаются три сущности, особо не отличающиеся друг от друга: станции, входы, виртуальные узлы. Все они имеют идентификаторы, названия (или комментарии), координаты. Я предлагаю хранить их в трёх разных файлах похожей структуры.

Как разрабочик приложения, ты должен с радостью принимать такие изменения структуры: по сути, вместо разрозненных таблиц получаешь готовый роутинговый граф, где всё хранится в правильных местах. Тип узла остаётся лишь атрибутом, всё остальное самоочевидно: набор рёбер, у каждого пешеходные атрибуты, плюс рёбра для роутинга между станциями в отдельном файле (в идеале — направленные, см. #19). Откуда здесь «гораздо больше времени»? Какая разница, разделено на уровне файлов или атрибутов, ты же всё равно всё в память грузишь?

[simgislab]

Сейчас есть структура и она худо-бедно работает. У нас этим занимается чуть ли не 5 человек. Оптимизировать, переходить на другую - нет времени. Всё это будем делать потом, если проект выстрелит и появятся серьезные причины всё это оптимизировать.

[simgislab]

From @BishopGIS on September 16, 2013 9:15

Нет там никакого графа. Каждый идентификатор входа должен быть привязан к идентификатору станции (надо принять командирское решение к какой конкретно). Так принято изначально и ничего изменить нельзя. Я уже писал, что в перспективе нужно уходить от графа станций к графу препятствий от входа одной станции и до выхода другой.
Пока же, сделано - как сделано.
Как разработчик приложения повторюсь, что поиск в массиве из 200 элементов в 2 раза быстрее, чем из 400. В массиве portals ищутся данные при выборе станции отправления и прибытия, в interchanges при отображении графа. Выполнять поиск по всем данным - лишние и не нужные циклы.

[simgislab]

From @Zverik on September 16, 2013 9:26

200, 400... 🤦. Я понимаю, если бы 40000. Я предлагаю как раз что планируется — связать всё в единый граф, а не хранить два (потенциально — три) разных. Нынешняя же ситуация приводит к невозможности адекватно смоделировать, например, узел Восстания-Маяковская: там, по сути, есть третья фиктивная станция с выходом на вокзал. Или узел технологического института, где два выхода, и оба — в один зал. Вроде, в Москве Комсомольская обладает такой же топологией. Короче, усложнён роутинг, усложнена работа для сборщиков данных, усложнено понимание для пользователей, и лишь из-за того, что решение принималось в спешке, и не смотря на то, что второй файл появился только вчера, уже поздно что-то менять.

Извините, я не программист в этом проекте, и не обязательно меня слушать. Я понимаю, что сроки очень жёсткие, и проще заставить сборщиков данных заполнять лишние 100500 строк таблиц, чем изменить алгоритмы. Просто больно смотреть на нынешние структуры данных.

[simgislab]

From @BishopGIS on September 16, 2013 11:34

Это как раз мне больно смотреть, как все было сделано. Если бы с самого начала делался граф по препятствиям, то схемы можно было вообще генерировать автоматом (экономия кучи времени). И нормальный был бы граф не по станциям, а от входа до выхода. Но структуру заложили вы, сделав весь Питер. Результат интерпретации такой структуры в ПО вот такой.

[simgislab]

From @Zverik on September 16, 2013 11:54

Схемы нельзя генерировать автоматом, иначе они будут некрасивы. И не вижу, как это связано с невозможностью генерировать граф от входа до выхода. Этот тикет, как раз, делает его построение возможным.