Comments 41
Спасибо большое! Не расскажите, как вы пришли к тайловым серверам и интересно, почему выбран у в качестве центрального бд геоданных ms sql server?
К тайловым серверам пришли постепенно. Сначала у нас был один тайл-сервер, который стоял рядом с мап-сервером в новосибирском дата-центре и обслуживал местных пользователей. Потом пользователей становилось все больше, а их география росла. Один сервер не справлялся, так как запросов становилось очень много и много времени терялось на пингах от удаленных клиентов. Мы решили просто замасштабироваться и ставить тайл-серверы поближе к группам пользователей. Сейчас у нас их девять.
MSSQL был выбран с самого начала, потому что у нас были на него лицензии, был опыт работы плюс наша команда администрирования умеет его хорошо готовить.
MSSQL был выбран с самого начала, потому что у нас были на него лицензии, был опыт работы плюс наша команда администрирования умеет его хорошо готовить.
Мне кажется, или на картинке с лосём вы перепутали цифровые индексы у строк и колонок?
Да не за что. Всегда рад помочь хорошей статье ;)
Спасибо вам и всем картографам за 2ГИС, 3 года уже пользуюсь! :)
Почему используется именно WGS84, а не обычные глобальные координаты (те, что используются в навигаторах типа таких 55°45'38.4«N 37°37'42.2»E)? В чём преимущество других систем координат над обычными глобальными?
В навигаторах — и есть WGS84.
Если Вы имели ввиду — почему именно продольная проекция Меркатора, то она чаще всего используется, т.к. достаточно простая и глобальная, и локальные искажения небольшие (пропорции ширины и высоты небольшого объекта на карте сохраняются).
Если Вы имели ввиду — почему именно продольная проекция Меркатора, то она чаще всего используется, т.к. достаточно простая и глобальная, и локальные искажения небольшие (пропорции ширины и высоты небольшого объекта на карте сохраняются).
Глобальные координаты, которые Вы указали, это сферические координаты. То есть координаты на сфере как модели Земли. В реальности гораздо проще работать с плоскими координатами. Мы выбрали WGS84, потому что она покрывает весь мир (есть еще и такие, которые покрывают только часть земной поверхности, например, UTM) и сохраняет углы и формы.
То, что показывает навигатор, скорее всего просто пересчет из используемой им проекции в глобальные координаты, это очень простая операция. Мы в своем клиенте в статусбаре тоже такие координаты показываем.
То, что показывает навигатор, скорее всего просто пересчет из используемой им проекции в глобальные координаты, это очень простая операция. Мы в своем клиенте в статусбаре тоже такие координаты показываем.
Вы какую-то глупость сказали. WGS84 — это не формат представления данных а система геодезических параметров. Что как и относительно чего определяется, рассчитывается и так далее. И кстати, она глобальная. А в каком виде будут представлены конечные пространственные координаты, совершенно не важно. То есть 55°45'38.4«N = 55.760667° (есть ещё всякие промежуточные представления), а вот система координат будет зависеть от того, по каким правилам получены данные.
Проекция WGS84 оперирует метрами, мы же ограничиваемся точностью в один сантиметр, поэтому можем работать с координатами как с целочисленными значениями
Неверно. WGS84 — это эллипсоид (EPSG:4326).
А почему во внешнем сервисе вы используете EPSG:3857, а во внутреннем — EPSG:3395?
Когда мы начинали делать свой продукт, в конечных вообще были UTM-проекции, для каждого города 2ГИС своя. А нам нужен был весь мир и выбрали EPSG:3395. Потом конечные продукты решили использовать EPSG:3857, а мы не стали у себя что-то менять. Конвертация не вызывает проблем, и если вдруг в какой-то момент конечные продукты захотят использовать другую проекцию, мы легко это поддержим.
Внутри остался бейсик или полностью отказались от модулей? В т.ч. тестирование картографом карты на ошибки и привязку карточек?
Раньше снимки подгружались с диска машины, за которой работал картограф, либо с «рядом» стоящего сервера. Отказались от этого?
Раньше снимки подгружались с диска машины, за которой работал картограф, либо с «рядом» стоящего сервера. Отказались от этого?
Проекта ДГПП, в котором был бейсик, уже нет:) Он был разделен на несколько независимых частей, одной из которых стал Fiji. Используем .NET-стек и немного Java. Вся работа с карточками организаций происходит в другой системе, картограф в этом не участвует.
Для космоснимков используется отдельный сервис, который отдает данные на клиента по протоколу WMS, никакого локального хранения.
Для космоснимков используется отдельный сервис, который отдает данные на клиента по протоколу WMS, никакого локального хранения.
Проекция WGS84 оперирует метрами,
Градусами, минутами и секундами.
Даже выбранный вами Меркатор метрами не оперирует, а некоторыми условными единицами, я бы сказал
Мне все время было интересно, а откуда картографы берут информацию о новых объектах? Как вся цепочка процесса построена?
В каждом тайле первая точка первого объекта хранится в абсолютных координатах, а все остальные — как смещение относительно предыдущей точки.
Очень и очень странное решение…
Никогда такое в голову не приходило при реализации тайловых систем…
Зачем такая сложная логика с первой точкой, если можно просто работать в локальной системе координат тайла?
У меня масса вопросов.
1. Зачем вам в тайле флаг того что объект в тайле полностью?
2. Как вы решили проблему места для подписи? Геометрия в тайлах порезана, склеивать её накладно по CPU. Как определить середину объекта, чтоб подписать? Или какой у вас алгоритм?
3. Как вы храните тайлы? Я так понял 1 тайл = 1 BLOB в SQL Server? Не думали использовать key-value NoSQL БД?
4. Какая у вас тайловая сетка? Регулярная? Т.е. на максимальном 16-м зуме существуют все тайлы в которые попадает хотябы 1 объект?
5. Что за странный рендер DirectX и GDI+, я так предполагаю что векторные тайлы рендерятся в растровые GDI+, а потом растровыми манипулирует DirectX для плавности? Или это 2 разных рендера: для экрана и для принтера?
Подкину вам идею для быстрого внесения изменений в тайлы, которая сделана у нас: на таблицу БД с данными вешается триггер, который пишет все изменения в отдельную таблицу истории, старую версию записи и новую версию записи. Отдельный сервис считывает историю и зная где объект был и куда переместился знает какие тайлы необходимо обновить, что в них удалить и что добавить. Обращения к основной таблице не происходит.
Ещё таблица истории может передаваться в сыром виде на клиент. Пока изменения не внесены в тайлы, эти объекты берутся из истории, а в тайлах игнорируются. Тем самым практически нет проблем с неактуальным отображением. Это в кратце.
1. Зачем вам в тайле флаг того что объект в тайле полностью?
2. Как вы решили проблему места для подписи? Геометрия в тайлах порезана, склеивать её накладно по CPU. Как определить середину объекта, чтоб подписать? Или какой у вас алгоритм?
3. Как вы храните тайлы? Я так понял 1 тайл = 1 BLOB в SQL Server? Не думали использовать key-value NoSQL БД?
4. Какая у вас тайловая сетка? Регулярная? Т.е. на максимальном 16-м зуме существуют все тайлы в которые попадает хотябы 1 объект?
5. Что за странный рендер DirectX и GDI+, я так предполагаю что векторные тайлы рендерятся в растровые GDI+, а потом растровыми манипулирует DirectX для плавности? Или это 2 разных рендера: для экрана и для принтера?
Подкину вам идею для быстрого внесения изменений в тайлы, которая сделана у нас: на таблицу БД с данными вешается триггер, который пишет все изменения в отдельную таблицу истории, старую версию записи и новую версию записи. Отдельный сервис считывает историю и зная где объект был и куда переместился знает какие тайлы необходимо обновить, что в них удалить и что добавить. Обращения к основной таблице не происходит.
Ещё таблица истории может передаваться в сыром виде на клиент. Пока изменения не внесены в тайлы, эти объекты берутся из истории, а в тайлах игнорируются. Тем самым практически нет проблем с неактуальным отображением. Это в кратце.
1. Только для небольшой оптимизации — флаг вместо четырех координат, если тайл полностью покрывает объект. Чтобы нарисовать заливку в этом тайле, если она нужна. Очень актуально для больших объектов типа населенных пунктов, районов и т.д.
2. Для некоторых типов объектов картографы специально ставят точку, в которой должна быть подпись, мы ее храним как отдельный атрибут и потом используем в отрисовке. Для всех остальных случаев подпись может дублироваться, если объект попал в несколько тайлов, для нас это нормальная ситуация, никакой склейки геометрий не делаем. Это касается только нашего внутреннего продута, в конечных же продуктах свои алгоритмы расставления подписей.
3. В SQL Server хранятся оригинальные геометрии, сами же тайлы лежат в отдельных базах PostgreSQL. В них один тайл это одна запись в таблице. Однако помимо простой операции получения по ключу нам иногда нужны и более хитрые запросы, поэтому в таблице есть и другие колонки. Key-value хранилище в таких случаях нам не подходит.
4. Сетка регулярная, в итоге получается, что у нас есть все тайлы, которые явно запрашивали пользователи. Если запроса на тайл не было, специально мы его не создаем.
5. Для отрисовки тайлов используется GDI+. А вот для для отображения трекеров при редактировании объектов у нас есть два режима в клиенте — DirectX и GDI+. Первый выигрывает на большом количестве точек и трекеров. Однако на большом зоопарке машин картографов иногда он не работает, поэтому можем отображать трекеры средствами GDI.
Спасибо за предложенные идеи по ускорению. Чтение изменений у нас примерно так и сделано. Про дополнительное получение необработанных изменений с клиента интересно, но может не подойти нам по причине сильной отдаленности некоторых клиентов от центральной БД, попробуем поэкспериментировать.
2. Для некоторых типов объектов картографы специально ставят точку, в которой должна быть подпись, мы ее храним как отдельный атрибут и потом используем в отрисовке. Для всех остальных случаев подпись может дублироваться, если объект попал в несколько тайлов, для нас это нормальная ситуация, никакой склейки геометрий не делаем. Это касается только нашего внутреннего продута, в конечных же продуктах свои алгоритмы расставления подписей.
3. В SQL Server хранятся оригинальные геометрии, сами же тайлы лежат в отдельных базах PostgreSQL. В них один тайл это одна запись в таблице. Однако помимо простой операции получения по ключу нам иногда нужны и более хитрые запросы, поэтому в таблице есть и другие колонки. Key-value хранилище в таких случаях нам не подходит.
4. Сетка регулярная, в итоге получается, что у нас есть все тайлы, которые явно запрашивали пользователи. Если запроса на тайл не было, специально мы его не создаем.
5. Для отрисовки тайлов используется GDI+. А вот для для отображения трекеров при редактировании объектов у нас есть два режима в клиенте — DirectX и GDI+. Первый выигрывает на большом количестве точек и трекеров. Однако на большом зоопарке машин картографов иногда он не работает, поэтому можем отображать трекеры средствами GDI.
Спасибо за предложенные идеи по ускорению. Чтение изменений у нас примерно так и сделано. Про дополнительное получение необработанных изменений с клиента интересно, но может не подойти нам по причине сильной отдаленности некоторых клиентов от центральной БД, попробуем поэкспериментировать.
Есть в планах сделать карту мира на уровне названий стран и городов? Периодически нужно прикидывать что где, в общих чертах, а оффлайновой карты найти не смог.
Такое пригодится и туристам, планирующим цепочки полетов.
Такое пригодится и туристам, планирующим цепочки полетов.
Уже который раз удивляюсь «неужели человек, который придумал название для продукта не попробовал его загуглить?»
Как минимум с 2008го года существует вот такое Fiji, который является одно из сборок ImageJ.
А вообще видео одну из версий Вашей Fiji на конференции и был удивлён скоростью работы
Как минимум с 2008го года существует вот такое Fiji, который является одно из сборок ImageJ.
А вообще видео одну из версий Вашей Fiji на конференции и был удивлён скоростью работы
А почему на картинке из «Подвигать карту» в «Нарисовать объект» идут 2 однотипные стрелки?
(промаркированы красным и зеленым ромбами на картинке по ссылке: Подвигать карту)
(промаркированы красным и зеленым ромбами на картинке по ссылке: Подвигать карту)
Спасибо, интересно. А как относительные координаты сокращают дату аж в 8 раз?
Если хранить координату как два double-числа, то она будут занимать 16 байт. Для генерализованных тайлов можно сделать относительную систему координат для каждого тайла и предположить, что в клиенте он будет рендериться в картинку максимального размера 256 на 256 пикселей. Тогда все координаты можно преобразовать в целочисленные значения от 0 до 255 и хранить в байте, то есть всего два байта на координату. Это справедливо только для генерализованных тайлов. Для обычных же можно перейти к целочисленным координатам, пересчитанным относительно угла тайла. Значения будут гораздо меньше оригинальных, и из можно хранить переменным числом байт, используя алгоритм ZigZag из Google Protocol Buffers.
Sign up to leave a comment.
Как мы делаем карту для тех, кто делает карту