А, дак у вас претензии к заголовку:) Ну обмана по прежнему никакого нет, способ представления данных может быть разным. Ну и если всё таки хочется увидеть миллион на одной картиночке (ну вы понимаете, что это будет соответствующий зум и симплификация данных), то вот вам ещё одна картиночка, но вряд ли она вам понравится. Это 1180 тыс зданий Москвы и МО.
Пример выше - это не "точка а вместо 5 домов". Это "столбик" в месте расположения каждого дома. Т.е. каждый дом - ячейка грида. Вот детальный зум, чтоб было понятно:
Ну а если хочется прям сами дома, то специально для вас есть вот такой пример. Тут прям контуры зданий, цветовое кодирование соответствует кол-ву организаций в здании.
С бека на фронт уходят прям реально сотни тысяч и миллионы объектов. Сейчас ограничение около 3 миллионов. Фронт способен отрисовать и такое, например, в визуализации точками или гридами / гексами малого размера, просто это будет уже не так шустро.
В данный момент с бекенда уходит json, просто для большого объёма данных (когда в результате больше 10 000 объектов) он готовится в фоне, и на клиент фактически отдаётся файл. Упаковка его в бинарный формат - вариант на будущее. И вы правы, это точно сократит время на фронте.
Никто не запрещает, используйте). В LocationLayer просто точка рисуется шэйдером в указанной координате, и она анимированная. В исходники библиотеки можно заглянуть, там всё относительно просто.
Секретов тут никаких нет. Обращаемся в администрацию ТЦ / аэропорта, согласовываем возможность публикации этих данных, получаем от них всё что есть — инженерные, пожарные планы, схемы и т.д. Ну и дальше по схемам специалисты всё отрисовывают.
В дальнейшем наши специалисты пешком обходят ТЦ и вносят необходимые корректировки.
Получить прям сырые геоданные возможности сейчас нет. Вообще, мы данные продаем, в том числе и геоданные. Но конкретно для физ. лиц сейчас есть только сервис с данными по организациям.
Да, вы правы, была версия для КПК в 2006 году. Поправил в статье, что готовилась мобильная версия для смартфонов, чтоб не было неоднозначностей.
А по поводу бурного роста я же не говорил, что он начался с моим приходом. Рост может продолжаться довольно долго ведь. В начале 2010 года у нас было порядка 20 крупных городов, сейчас — больше 120, да и география стран то же расширилась. RND состоял из нескольких десятков человек, сейчас в несколько раз больше. Не вижу здесь противоречий).
Проблем с модификацией структуры не было. Тут нужно иметь ввиду, что продукт растаскивали на отдельные сервисы, и количество доработок постепенно уменьшалось.
Ну а сам процесс внесения изменений происходил с поддержкой обратной совместимости: структура расширялась. Добавляем этажность в здании — новая колонка. Добавляем входы на карту — новая таблица.
Так что вносить изменения в один момент конечно же не приходилось. Фича спокойно реализовывалась в DGPP, и если новые данные появлялись и их нужно было доставлять до внешних продуктов, что само собой происходило не всегда, то требовалась поддержка в экспорте.
Ну а код править приходилось в любом случае, обработка новых типов объектов или новых атрибутов практически всегда была довольно специфична. И то, какие именно объекты и атрибуты нужны экспорту определялось самим экспортом.
На самом деле, больше всего сложностей было не на этапе интеграции, там то как раз всегда всё было относительно просто и понятно, а на этапе подготовки данных.
Лезть в базу DGPP экспорт перестал в момент смерти первого. А как удалось его заменить на чтение из ESB я расскажу в следующей статье, выйдет через недельку.
Если речь именно о движении общественного транспорта — то да, реализация как вы описали. Как пользоваться написано тут.
О планах по реализации отдельного слоя для этих данных мне ничего неизвестно, уточню у коллег.
Максим, кажется, у вас завышенные ожидания от исторической справки) Тут возможны споры относительно правдивости описанных событий, например, можете оказать посильную помощь и набросить на вентилятор:)
Спасибо за полезный комментарий.
Насколько я понимаю, это все таки онлайн решение, которое предоставляет тайловый кэш и поддержку WMS. Основная фишка описанного в статье mapsforge — это оффлайн данные. Если требования предполагают постоянный онлайн — то это существенное смягчение, и выбор вариантов реализации сильно расширяется.
Вы конечно же правы. Как обычно — весь дьявол в деталях.
Но статья и не подразумевала создание совершенного приложения с выходом в прод. Она ведь всего лишь демонстрирует один из возможных инструментов для тех, кто этого ни разу не делал. Не более того. И это вполне осуществимо за два дня, никакого лукавства.
Про юзабельный поиск. Согласен с вами, что для того, чтобы сделать навороченную выдачу с группировкой по типам объектов, приоритетами, подсказками и прочим, встроенного в SQLite FTS недостаточно. Но всё ведь зависит от требований.
Например, в нашем приложении для выверки данных специалистам достаточно простого поиска по названию организации, и поиска адреса по названию улицы и номера дома. Вполне юзабельно и достаточно указанного выше FTS.
Решения же на данных OSM (со своими недостатками и преимуществами) существуют и пользуются спросом. Тот же maps.me.
Понятно, что если требуется получить качество данных приближенное к 2ГИС — то это серьезная задача. Но, опять же, всё определяется требованиями к продукту.
Ну а в каком направлении действовать, если вас устроит OSM, показано в статье.
Более того, если у вас есть свои данные, их легко завернуть в MAP файл плагином от mapsforge и использовать для отображения описанный выше движек.
Да секретов тут никаких нет. 2ГИС появился гораздо раньше, чем тот же mapbox или carto. Даже на текущий момент нет какого то стандарта по организации данных для векторных тайлов в компактном виде, а уж тем более стандартов по их стилизации. Приходится изобретать свои велосипеды.
Ну и есть еще несколько аргументов в пользу своего формата:
1. Полный контроль над структурой данных с возможностью обеспечить хороший баланс между производительностью и потреблением памяти
2. Данные в проприетарном формате сложнее позаимствовать без спроса:)
В мобильном 2ГИС используется наш собственный закрытый (по крайней мере пока) движек с кастомным форматом данных и навороченной стилизацией.
mapsforge/vtm же — открытый, основанный на OSM данных. Его мы используем в своём внутреннем продукте, предназначенном для сбора данных на местности, когда наши специалисты прям ногами ходят по бренной земле и выверяют информацию.
Предвосхищая вопрос «почему же не использовать свой собственный» ответ, вкратце, такой: mapsforge/vtm было, на тот момент, быстрее интегрировать. Он довольно прост в использовании и достаточно быстрый. Это основные критерии, ведь для выверки нам не нужны излишние красивости, которых требует публичный продукт. Если будет возможность и необходимость перейти на нашу собственную разработку — сделаем это. Благо, работа с картой абстрагирована от остальной логики, и переход произойдёт относительно просто.
Согласен с вами, статья как раз демонстрирует, как можно сделать эту простую часть максимально быстро. Для настройки и поддержки инфраструктуры у нас в компании есть крутые админы, а наивные разработчики обычно занимаются разработкой:)
Что касается настройки астериска, можно почитать, например, вот эту статью.
Спасибо за дельное замечание по поводу 'progress', поправлю, дабы никто не спотыкался.
sipml5 то же пробовал, но она довольно большая, и была какая то проблема с ней, сейчас уже не вспомню.
А, дак у вас претензии к заголовку:) Ну обмана по прежнему никакого нет, способ представления данных может быть разным. Ну и если всё таки хочется увидеть миллион на одной картиночке (ну вы понимаете, что это будет соответствующий зум и симплификация данных), то вот вам ещё одна картиночка, но вряд ли она вам понравится. Это 1180 тыс зданий Москвы и МО.
Пример выше - это не "точка а вместо 5 домов". Это "столбик" в месте расположения каждого дома. Т.е. каждый дом - ячейка грида. Вот детальный зум, чтоб было понятно:
Ну а если хочется прям сами дома, то специально для вас есть вот такой пример. Тут прям контуры зданий, цветовое кодирование соответствует кол-ву организаций в здании.
С бека на фронт уходят прям реально сотни тысяч и миллионы объектов. Сейчас ограничение около 3 миллионов. Фронт способен отрисовать и такое, например, в визуализации точками или гридами / гексами малого размера, просто это будет уже не так шустро.
Вот так выглядит 20-метровые ячейки:
В данный момент с бекенда уходит json, просто для большого объёма данных (когда в результате больше 10 000 объектов) он готовится в фоне, и на клиент фактически отдаётся файл. Упаковка его в бинарный формат - вариант на будущее. И вы правы, это точно сократит время на фронте.
Да, крутая штука, вдохновлялись как раз глядя на неё:)
Никто не запрещает, используйте). В LocationLayer просто точка рисуется шэйдером в указанной координате, и она анимированная. В исходники библиотеки можно заглянуть, там всё относительно просто.
В дальнейшем наши специалисты пешком обходят ТЦ и вносят необходимые корректировки.
А по поводу бурного роста я же не говорил, что он начался с моим приходом. Рост может продолжаться довольно долго ведь. В начале 2010 года у нас было порядка 20 крупных городов, сейчас — больше 120, да и география стран то же расширилась. RND состоял из нескольких десятков человек, сейчас в несколько раз больше. Не вижу здесь противоречий).
Проблем с модификацией структуры не было. Тут нужно иметь ввиду, что продукт растаскивали на отдельные сервисы, и количество доработок постепенно уменьшалось.
Ну а сам процесс внесения изменений происходил с поддержкой обратной совместимости: структура расширялась. Добавляем этажность в здании — новая колонка. Добавляем входы на карту — новая таблица.
Так что вносить изменения в один момент конечно же не приходилось. Фича спокойно реализовывалась в DGPP, и если новые данные появлялись и их нужно было доставлять до внешних продуктов, что само собой происходило не всегда, то требовалась поддержка в экспорте.
Ну а код править приходилось в любом случае, обработка новых типов объектов или новых атрибутов практически всегда была довольно специфична. И то, какие именно объекты и атрибуты нужны экспорту определялось самим экспортом.
На самом деле, больше всего сложностей было не на этапе интеграции, там то как раз всегда всё было относительно просто и понятно, а на этапе подготовки данных.
Лезть в базу DGPP экспорт перестал в момент смерти первого. А как удалось его заменить на чтение из ESB я расскажу в следующей статье, выйдет через недельку.
О планах по реализации отдельного слоя для этих данных мне ничего неизвестно, уточню у коллег.
Максим, кажется, у вас завышенные ожидания от исторической справки) Тут возможны споры относительно правдивости описанных событий, например, можете оказать посильную помощь и набросить на вентилятор:)
Общественный транспорт на картах 2гис присутствует. О каком "слое" идёт речь?
Насколько я понимаю, это все таки онлайн решение, которое предоставляет тайловый кэш и поддержку WMS. Основная фишка описанного в статье mapsforge — это оффлайн данные. Если требования предполагают постоянный онлайн — то это существенное смягчение, и выбор вариантов реализации сильно расширяется.
Но статья и не подразумевала создание совершенного приложения с выходом в прод. Она ведь всего лишь демонстрирует один из возможных инструментов для тех, кто этого ни разу не делал. Не более того. И это вполне осуществимо за два дня, никакого лукавства.
Про юзабельный поиск. Согласен с вами, что для того, чтобы сделать навороченную выдачу с группировкой по типам объектов, приоритетами, подсказками и прочим, встроенного в SQLite FTS недостаточно. Но всё ведь зависит от требований.
Например, в нашем приложении для выверки данных специалистам достаточно простого поиска по названию организации, и поиска адреса по названию улицы и номера дома. Вполне юзабельно и достаточно указанного выше FTS.
Решения же на данных OSM (со своими недостатками и преимуществами) существуют и пользуются спросом. Тот же maps.me.
Понятно, что если требуется получить качество данных приближенное к 2ГИС — то это серьезная задача. Но, опять же, всё определяется требованиями к продукту.
Ну а в каком направлении действовать, если вас устроит OSM, показано в статье.
Более того, если у вас есть свои данные, их легко завернуть в MAP файл плагином от mapsforge и использовать для отображения описанный выше движек.
Ну и есть еще несколько аргументов в пользу своего формата:
1. Полный контроль над структурой данных с возможностью обеспечить хороший баланс между производительностью и потреблением памяти
2. Данные в проприетарном формате сложнее позаимствовать без спроса:)
mapsforge/vtm же — открытый, основанный на OSM данных. Его мы используем в своём внутреннем продукте, предназначенном для сбора данных на местности, когда наши специалисты прям ногами ходят по бренной земле и выверяют информацию.
Предвосхищая вопрос «почему же не использовать свой собственный» ответ, вкратце, такой: mapsforge/vtm было, на тот момент, быстрее интегрировать. Он довольно прост в использовании и достаточно быстрый. Это основные критерии, ведь для выверки нам не нужны излишние красивости, которых требует публичный продукт. Если будет возможность и необходимость перейти на нашу собственную разработку — сделаем это. Благо, работа с картой абстрагирована от остальной логики, и переход произойдёт относительно просто.
Что касается настройки астериска, можно почитать, например, вот эту статью.
sipml5 то же пробовал, но она довольно большая, и была какая то проблема с ней, сейчас уже не вспомню.