Comments 20
Не совсем ясно…
Зашел на сайт, выбрал Уфу — вижу: Не больше 2-х машин на горизонте, а где именно то? на какой дороге?
Зашел на сайт, выбрал Уфу — вижу: Не больше 2-х машин на горизонте, а где именно то? на какой дороге?
А в PC версию есть планы добавить пробки?
GEOS, конечно, чуть ли не стандарт, но когда я решил заглянуть в его исходники, я ужаснулся неоптимальности… практически всего.
Так что либо искать другие хорошие библиотеки (которых нет), либо да, писать собственные решения.
Так что либо искать другие хорошие библиотеки (которых нет), либо да, писать собственные решения.
А kd-tree не подошло?
Вариант с K-D деревом рассматривался, но так и не попробовали.
Удалось достаточно быстро посмотреть, как с задачей справляется pmr quadtree, на нём и остановились.
Удалось достаточно быстро посмотреть, как с задачей справляется pmr quadtree, на нём и остановились.
Мы решали похожую задачу. Есть 200к точек. Нужно найти ближайшую точку для пользователя в заданном радиусе.
Создание дерева 2сек, 30к выборок == 1 сек на моем слабеньком ноуте. Писали на Java, использовали готовое KD-tree. Реализация решения заняла 2 часа.
Нас производительность устраивала, потому не оптимизировали. Но путей для оптимизации там море. Уверен, что вполне можно было бы подобраться к Вашему решению, может как-то выделю время…
Создание дерева 2сек, 30к выборок == 1 сек на моем слабеньком ноуте. Писали на Java, использовали готовое KD-tree. Реализация решения заняла 2 часа.
Нас производительность устраивала, потому не оптимизировали. Но путей для оптимизации там море. Уверен, что вполне можно было бы подобраться к Вашему решению, может как-то выделю время…
Плоховаты ваши пробки пока, на Яндексе гораздо правдивее. Бердское шоссе возле ул. Русской на юг в вечер пятницы забито и стоит, а по вашим данным почему-то там скорость 50 км/ч.
А можно я задам вопрос по роутингу, но чуть в сторону от темы статьи?
У вас граф роутинга — отдельно хранящаяся и редактируемая сущность, или его топология хранится в той же базе, что и вся остальная топология, а для работы с графом извлекается из нее? То есть на практическом примере: если в городе Н построили новую улицу, она вносится в одно единственное место для хранения, или в два (и более) разных?
Хочется понять, на что ваш сервис больше похож архитектурно — на Яндекс или на OpenStreetMap.
У вас граф роутинга — отдельно хранящаяся и редактируемая сущность, или его топология хранится в той же базе, что и вся остальная топология, а для работы с графом извлекается из нее? То есть на практическом примере: если в городе Н построили новую улицу, она вносится в одно единственное место для хранения, или в два (и более) разных?
Хочется понять, на что ваш сервис больше похож архитектурно — на Яндекс или на OpenStreetMap.
Хочется понять, на что ваш сервис больше похож архитектурно — на Яндекс или на OpenStreetMap.
Архитектура Яндекса на месте не стоит и бурно развивается: blog.yandex.ru/post/72397/
Чтобы оперативно исправлять ошибки, дорожный граф и дороги должны храниться в одной и той же базе и редактироваться одним и тем же инструментом.
Скажите честно, вы — чиновник или SEOшник?
Я задал вполне конкретный вопрос по поводу архитектуры 2GIS.
Вы ответили, но ваш ответ состоит из:
— цитаты из моего вопроса;
— хвалебной фразы про Яндекс со ссылкой на их статью (которая не имеет к моему вопросу ни малейшего отношения по простой причине — там про роутинг ничего не написано);
— указания на общий факт, который лично мне и так известен, а к упомянутому выше вами Яндексу не имеет также никакого отношения.
Вы что-то хотели мне сообщить или цель комментария — ссылка на блог Яндекса?
Я задал вполне конкретный вопрос по поводу архитектуры 2GIS.
Вы ответили, но ваш ответ состоит из:
— цитаты из моего вопроса;
— хвалебной фразы про Яндекс со ссылкой на их статью (которая не имеет к моему вопросу ни малейшего отношения по простой причине — там про роутинг ничего не написано);
— указания на общий факт, который лично мне и так известен, а к упомянутому выше вами Яндексу не имеет также никакого отношения.
Вы что-то хотели мне сообщить или цель комментария — ссылка на блог Яндекса?
Скажите честно, вы — чиновник или SEOшник?
Я программист.
Я задал вполне конкретный вопрос по поводу архитектуры 2GIS. Вы ответили, но ваш ответ состоит из:
Про 2GIS я вам ответить не могу, так как там не работаю и устройства их системы не знаю. Однако в вашем вопросе содержится ошибочное утверждение, по поводу которого я и написал.
хвалебной фразы про Яндекс со ссылкой на их статью (которая не имеет к моему вопросу ни малейшего отношения по простой причине — там про роутинг ничего не написано)
Про роутинг действительно не написано. Написано про весь процесс подготовки картографических данных. Он был полностью переработан и у Яндекса теперь есть инфраструктура для быстрой публикации обновлений. К дорожному графу и маршрутизации это тоже относится.
указания на общий факт, который лично мне и так известен, а к упомянутому выше вами Яндексу не имеет также никакого отношения.
Ваши сведения устарели. Можете сопоставить«общий факт» и наличие инфраструктуры для быстрой публикации обновлений.
Быструю публикацию обновлений картинки карты они умели. Граф править вручную — тоже (после того как им в публичном месте на грубую ошибку или неактуальность указали — тут, на Хабре, был пример год назад с дублером Дмитровского шоссе в Москве). В статье, на которую вы ссылаетесь, есть текст:
Из него абсолютно не следует, что теперь хранение и редактирование осуществляется так, как вы описали (и как я имел в виду, приводя пример OSM), есть только общие слова о «полной переработке» — что они конкретно значат, мне неизвестно.
А вам?
Более того, потыкав в известные мне лично «проблемные» места я все еще вижу, что местами соединение улиц нарисовано, а маршрут прокладывается не через это соединение (хотя нет там никаких запретов точно). Хотя совпадение линий графа и линий карты все же улучшилось, это я признаю как факт. Так что создается впечатление, что что-то переписали (да, прогресс), но полного порядка еще нет.
В процессе работы над мировой картой мы полностью переписали ядро Яндекс.Карт. Благодаря этому у нас появилась возможность внедрить единый дизайн, а также инфраструктура для быстрой публикации обновлений. Теперь вносить изменения и исправлять неточности на Яндекс.Картах стало гораздо проще.
Из него абсолютно не следует, что теперь хранение и редактирование осуществляется так, как вы описали (и как я имел в виду, приводя пример OSM), есть только общие слова о «полной переработке» — что они конкретно значат, мне неизвестно.
А вам?
Более того, потыкав в известные мне лично «проблемные» места я все еще вижу, что местами соединение улиц нарисовано, а маршрут прокладывается не через это соединение (хотя нет там никаких запретов точно). Хотя совпадение линий графа и линий карты все же улучшилось, это я признаю как факт. Так что создается впечатление, что что-то переписали (да, прогресс), но полного порядка еще нет.
Из него абсолютно не следует, что теперь хранение и редактирование осуществляется так, как вы описали (и как я имел в виду, приводя пример OSM)
Тем не менее, оно именно такое. И это позволяет намного оперативнее и качественнее реагировать на фидбек пользователей.
Более того, потыкав в известные мне лично «проблемные» места я все еще вижу, что местами соединение улиц нарисовано, а маршрут прокладывается не через это соединение (хотя нет там никаких запретов точно). Хотя совпадение линий графа и линий карты все же улучшилось, это я признаю как факт. Так что создается впечатление, что что-то переписали (да, прогресс), но полного порядка еще нет.
Вы спрашивали про хранение и редактирование данных в едином месте. Это то, с чем работают картографы, мастер реплика. Если в неё будут ходить все сервисы, то и производительность будет никакая и единая точка отказа получится. Кроме того, для разных задач данные выгодно хранить в разном виде, со всякими дополнительными индексами. Это приводит к тому, что версии данных на разных сервисах могут немного отличаться. И чем чаще делаются релизы, тем меньше таких нестыковок.
В ОСМ, который вы ставите в пример, используется тот же самый подход. Характерные артефакты можно также найти и на гуглокартах.
Тем не менее, оно именно такое.
Как это должно было быть понятно из процитированного фрагмента статьи в блоге Яндекса и того, что вы неписали?
Вы спрашивали про хранение и редактирование данных в едином месте.
Для начала, я не спрашивал про то, как это устроено в Яндексе.
Далее, то что вы описываете, мне прекрасно известно.
Могу даже ткнуть пальцем в map.project-osrm.org/ где дата и время импорта графа написана в явном виде на закладке Configuration (обновления происходят раз в сутки), а тайловая картинка (по крайней мере, на слое osm.org) обновляется практически в реальном времени. И данные берутся изначально из одной общей базы, а только отрисовываются и конвертируются для роутинга и т.п. отдельно.
Это несколько отличается от ситуации, когда эти данные даже происхождение могут иметь разное, так? Вот потому я Яндекс и приводил как «плохой пример». Если даже сейчас все несколько иначе, тем не менее, раньше было так. Удивлен вашему упорству по выставлению Яндекса в выгодном свете. Не стали бы вы развивать тему — на ровном месте (когда по сути вопроса сказать было нечего) — не пришлось бы тратить время на ерунду.
В единой базе, в своем слое (слой дорожного графа).
Sign up to leave a comment.
Использование квадродеревьев при расчёте пробок 2ГИС