Здравствуйте, Homunculus, Вы писали:
H>Как делается обычно рендеринг карт или если не знаете, то как бы сделали вы?
Используется пространственный индекс объектов, который позволяет не перебирать те объекты, которые не попали в окно запроса и откидывать слишком мелкие объекты (типа контуров домов на общем плане города).
Грубо карта разрезается на клетки n*m, для каждой клетки составляется список пересекающихся с ней объектов. И так несколько раз для разных n и m. В момент рендеринга выбираются все клетки, пересекающиеся с областью рендеринга. Так получается список объектов для рендеринга, именно эти объекты читаются с диска при рендеринге. Смысла держать все в памяти нет, т.к. пользователь видит либо общий план без деталей, либо малую часть детализированной карты.
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
Здравствуйте, Homunculus, Вы писали:
H>Как рендерят большие карты?
H>Какая мысль очевидно приходит в голову. Во-первых, сделать несколько растров под разные зумы. При уже более-менее большом растре — начать бить на клетки и погружать те части, которые видит пользователь в данный момент. Это как бы очевидный подход.
Это единственный поход, который может работать на минимальном зуме, когда нао отобразить всю карту или большую часть.
H>Но есть минусы, которые не нравятся. Во-первых, эти самые разные растры под разные зумы. Что-то дизайнерски некрасивое в этом есть. Во-вторых, перевод в растр сжирает преимущество наличия вектора.
Надо понять какие "преимущества вектора" надо сохранить и от этого плясать. Никто не мешает иметь несколько "слоев", где базовый — растр, а поверх накладываются векторные элементы. Причем на разных уровнях зума будут разные детализации разных слоев.
H>Есть еще другая мысль. Мне собственно все преимущества SVG и не нужны. Нужны только контуры и на некоторых контурах заливка сплошным цветом. Все. То есть мысль перевести SVG в какой-то свой формат контуров и уже эти объекты раскидать по разным файлам и подгружать по мере необходимости.
Вы все равно придете к растрам, когда надо будет отображать карту с минимальным зумом.
Векторные карты для туристических GPS-навигаторов (приборчиков с не особо быстрыми процессорами, тем более в 2000-х годах) подготавливались из исходных (тоже векторных, конечно) так: задавалось несколько масштабных диапазонов (штук 5-8) и для каждого диапазона делалась по сути своя векторная карта, в которой 1) большие объекты разбивались на прямоугольники поменьше, по размеру как экран устройства для среднего для диапазона масштаба 2) на крупных масштабах удалялись ненужные на них мелкие объекты (при подготовке карты можно было каждому объекту "вручную" задать минимальный масштабный диапазон, на котором он еще должен быть виден, но обычно это делалось после автоматизированного присвоения всем объектам этого свойства исходя из их типа и/или их площади).
Естественно, все объекты из одного прямоугольника одного масштабного диапазона в файле хранятся рядом, ну а про индексы для поиска нужного прямоугольника можно сообразить самому, надеюсь.
И никаких растров! Но так "подготовленные" карты — это уже read-only-формат, редактировались они не в нем (обычно).
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
В SVG пространственные данные обычно не хранят. Лучше использовать специализированные форматы данных, особенно если город географически большой по размеру (чтобы учесть широту и долготу и текущую проекцию, т.к. проекции есть разные, и нужно понимать в какой именно проекции была изначальная переведенная в svg карта, если это не учитывать то рано или поздно появятся трудноуловимые и труднопонимаемые баги с нарушением координат).
Как рендерить, можно посмотреть опенсорсный GeoServer (это сервер, написанный на Java, который как раз умеет рендерить большие карты) + OpenLayers (это клиентская библиотека, которая позволяет рисовать карты, отдаваемые тем же GeoServer, в браузере).
У него есть несколько способов, но все они завязаны на тайловую структуру, т.е. карта всегда бьется на куски, причем на разных масштабах, и эти тайлы отдаются клиенту.
Отдаются клиенту тайлы либо в виде векторных (тут уже SVG можно использовать), либо растровых изображений. Их как правило кешируют, сервер делает это и на своей стороне, и клиент также может их кешировать у себя.
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
Очень просто.
1. svg для этого не пригоден (но можно использовать как исходник)
2. карту надо разбить на области, например прямоугольники. сперва на 4 шт затем каждую чаcть так же до нужной детализации. Для каждого прямоугольника в зависимости от масштаба строиться своя оптимизированная картинка(с выкидыванием лишних деталей).
3. карты как правило имеют разные слои, несущую разную информацию (улицы, номера домов, электросети, магистрали и т.п.) всё разбивается так же.
4. плюс индексы для поисков (но это не к отрисовке)
5. Ренедерится из ближайших блоков в подходящем масштабе.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, Nuzhny, Вы писали:
H>Так проблема не только в отрисовке, но перед отрисовкой еще и загрузка кучу времени занимает. Отсечь невидимое — одно. Но вот загрузить все контуры и всегда их держать в памяти — другое. Представь карту города, где даже листики деревьев — отдельные контура Там миллиарды объектов.
Здравствуйте, Homunculus, Вы писали:
H>Каждый объект надо сортировать не просто по положению на сетке города, но и что-то типа LOD, то есть рисовать его или нет в зависимости от зума.
Достаточно оценить размеры его bound rect'а в пикселях при текущем масштабе. Это недорого.
Мы так рисуем вспомогательную информацию. Надписи, к примеру.
_____________________
С уважением,
Stanislav V. Zudin
Еще забыл про 3) на мелких масштабах (кстати, в прошлый раз я напутал и крупными их назвал) контуры объектов упрощались (выкидывались лишние промежуточные точки по особому алгоритму) и про то, что объектам задавался как минимальный, так и максимальный масштабные диапазоны отображения.
Скажем, город на мелких масштабах был условной точкой/кружочком с подписью, ближе становился контуром застройки (точка исчезала), еще ближе показывалась сеть линий-улиц, еще ближе — контуры отдельных кварталов (общий контур и линии улиц исчезали) и, наконец, появлялись контуры домов, дворовые проезды и прочее.
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать. H>Как рендерят большие карты?
Не совсем на эту тему, скорее, как один из приемов ускорения отрисовки:
У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов.
Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
Как рендерят большие карты?
Какая мысль очевидно приходит в голову. Во-первых, сделать несколько растров под разные зумы. При уже более-менее большом растре — начать бить на клетки и погружать те части, которые видит пользователь в данный момент. Это как бы очевидный подход.
Но есть минусы, которые не нравятся. Во-первых, эти самые разные растры под разные зумы. Что-то дизайнерски некрасивое в этом есть. Во-вторых, перевод в растр сжирает преимущество наличия вектора.
Есть еще другая мысль. Мне собственно все преимущества SVG и не нужны. Нужны только контуры и на некоторых контурах заливка сплошным цветом. Все. То есть мысль перевести SVG в какой-то свой формат контуров и уже эти объекты раскидать по разным файлам и подгружать по мере необходимости.
Как делается обычно рендеринг карт или если не знаете, то как бы сделали вы?
Здравствуйте, Homunculus, Вы писали:
H>Как делается обычно рендеринг карт или если не знаете, то как бы сделали вы?
Никогда этим не занимался, но уверен, что для векторной графики просто должна быть сущность типа clip path — регион, внутри которого надо рендерить и который сам отсекает части, которых не надо касаться. Чем больше зум — тем больше отсекается лишнего.
Так проблема не только в отрисовке, но перед отрисовкой еще и загрузка кучу времени занимает. Отсечь невидимое — одно. Но вот загрузить все контуры и всегда их держать в памяти — другое. Представь карту города, где даже листики деревьев — отдельные контура Там миллиарды объектов.
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
H>Какая мысль очевидно приходит в голову. Во-первых, сделать несколько растров под разные зумы. При уже более-менее большом растре — начать бить на клетки и погружать те части, которые видит пользователь в данный момент. Это как бы очевидный подход. H>Но есть минусы, которые не нравятся. Во-первых, эти самые разные растры под разные зумы. Что-то дизайнерски некрасивое в этом есть. Во-вторых, перевод в растр сжирает преимущество наличия вектора.
H>Есть еще другая мысль. Мне собственно все преимущества SVG и не нужны. Нужны только контуры и на некоторых контурах заливка сплошным цветом. Все. То есть мысль перевести SVG в какой-то свой формат контуров и уже эти объекты раскидать по разным файлам и подгружать по мере необходимости.
H>Как делается обычно рендеринг карт или если не знаете, то как бы сделали вы?
В памяти набор примитивов (линия, точка, текст)+ нужные графические атрибуты.
Примитивы отсортированы по координатам, чтобы быстро отсортировывать те,что находятся в текущей области отрисовки.
Если карта занимает 1,Гб в SVG то ее легко поместить в несколько сотен метров оперативки.
Использовать языки, где не создается по объекту на каждый чих. И без этих ваших сборщиков мусора.
Отрисовывать в графическом движке с аппаратным ускорением, если нужна быстрая отрисовка с антиалиасингом.
Файл 1,5 Гб можно грузить и парсить за десятки секунд, в зависимости от скорости диска.
Но если нужно грузить быстро и часто, лучше переложить в что то более компактное, чем XML, и легко парсящееся.
Самое трудоемкое реализовать качественную отрисовку картинки.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, Nuzhny, Вы писали:
H>Так проблема не только в отрисовке, но перед отрисовкой еще и загрузка кучу времени занимает. Отсечь невидимое — одно. Но вот загрузить все контуры и всегда их держать в памяти — другое. Представь карту города, где даже листики деревьев — отдельные контура Там миллиарды объектов.
Какие миллиарды? В 1,5 Гб SVG уместится максимум несколько десятков миллионов точек.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, swame, Вы писали:
S>>Какие миллиарды? В 1,5 Гб SVG уместится максимум несколько десятков миллионов точек.
H>А город еще не целиком готов. Пока только три района. И уже 1.5 гига. Будет больше.
Если карта не умещается в оперативке, то задача существенно усложняется и легче использовать готовую ГИС систему.
Такой подход очевиден, но и он имеет подводные камни. Каждый объект надо сортировать не просто по положению на сетке города, но и что-то типа LOD, то есть рисовать его или нет в зависимости от зума. Растровый подход тут проще.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, samius, Вы писали:
H>Такой подход очевиден, но и он имеет подводные камни. Каждый объект надо сортировать не просто по положению на сетке города, но и что-то типа LOD, то есть рисовать его или нет в зависимости от зума. Растровый подход тут проще.
Я отвечал на вопрос о том, как рендерят карты. Очевидно, что растровый подход — уже результат рендеринга огромной карты.
Здравствуйте, Homunculus, Вы писали:
H>>Как рендерят большие карты?
Дополню ответ камрада swame, расскажу, как рендерится дизайн печатной платы (или кристалл ИС).
S>В памяти набор примитивов (линия, точка, текст)+ нужные графические атрибуты. S>Примитивы отсортированы по координатам, чтобы быстро отсортировывать те,что находятся в текущей области отрисовки.
Строится 2Д хеш, точнее несколько хешей под разные объекты. Хеш позволяет быстро найти объекты, попадающие в заданный прямоугольник, либо в окрестности точки (мы же потом захотим нарисованное потыкать мышой).
S>Если карта занимает 1,Гб в SVG то ее легко поместить в несколько сотен метров оперативки. S>Использовать языки, где не создается по объекту на каждый чих. И без этих ваших сборщиков мусора.
Более того, не создавать объекты для каждой сущности, а хранить всё в плоском массиве и оперировать коллекцией объектов и идентификаторами объектов (целочисленными индексами). Можно сварганить итератор для удобства доступа к атрибутам объекта.
Для пущей компактности каждый атрибут объекта хранится в своём массиве. Другими словами переходим к реляционной таблице, где в массивах лежат столбцы таблиц.
S>Отрисовывать в графическом движке с аппаратным ускорением, если нужна быстрая отрисовка с антиалиасингом.
+1
С использованием соответствующих техник для ускорения рисования (списки вершин, шейдеры и т.д.).
S>Файл 1,5 Гб можно грузить и парсить за десятки секунд, в зависимости от скорости диска.
Если не использовать какой-нибудь msxml парсер, а взять, к примеру, scanner нашего камрада c-smile'а, то скорость разбора xml будет ограничена скоростью чтения с диска. Хотя... любой sax-парсер должен дать близкие значения по скорости, структуры данных нужно выбрать правильные.
S>Но если нужно грузить быстро и часто, лучше переложить в что то более компактное, чем XML, и легко парсящееся.
Если использовать структуру данных, предложенную выше, то бинарная десериализация для нее сводится к двум операциям чтения на каждый массив — считал число элементов, выделил память, зачитал все данные в память. Для кэширования данных и быстрого подъема с диска самое то.
S>Самое трудоемкое реализовать качественную отрисовку картинки.
Угу.
Дизайнерские способности не помешают, чтобы красиво получилось.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, swame, Вы писали:
S>Здравствуйте, Homunculus, Вы писали:
H>>Здравствуйте, swame, Вы писали:
S>>>Какие миллиарды? В 1,5 Гб SVG уместится максимум несколько десятков миллионов точек.
H>>А город еще не целиком готов. Пока только три района. И уже 1.5 гига. Будет больше.
S>Если карта не умещается в оперативке, то задача существенно усложняется и легче использовать готовую ГИС систему.
Да уместится, в чем проблема то? Оперативка сейчас дешевая. 1-2 терабайта не проблема в принципе, если не брать всякое экзотическое железо, обычные серверные чипсеты.
На обычных домашних PC по 256GB из коробки можно впихнуть.
Если уже совсем все большое и никак не влазит, ну придется что-то придумывать с хранением этого всего в БД и подгрузкой по необходимости и модификацией рендерера чтоб читал оттуда.
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
Я бы, наверное, забыл на минутку, что у меня есть конкретный формат SVG, и считал бы, что у меня есть много-много векторов.
Всю-всю поверхность я бы разбил на клеточки, и в каждой клеточке хранил бы те вектора, которые с ней пересекаются (даже если они начинаются и кончаются в другой клеточке).
Для отрисовки, я бы грузил вектора из тех клеточек, которые попадают в окошко, убирал бы повторяющиеся вектора (они могут возникнуть, если какой-то вектор проходит через несколько клеточек), и дальше отрисовывал бы.
Исходный SVG надо один раз переработать, и хранить результат в виде, удобном для поклеточной загрузки. Например, в виде какой-то незамысловатой базы (напрашивается SQLite)
Здравствуйте, Pzz, Вы писали:
Pzz>Всю-всю поверхность я бы разбил на клеточки, и в каждой клеточке хранил бы те вектора, которые с ней пересекаются (даже если они начинаются и кончаются в другой клеточке).
Pzz>Для отрисовки, я бы грузил вектора из тех клеточек, которые попадают в окошко, убирал бы повторяющиеся вектора (они могут возникнуть, если какой-то вектор проходит через несколько клеточек), и дальше отрисовывал бы.
Там в основном не вектора, а полигоны с заливкой. И пересекаться с "клеточкой" будет слишком много. Так что придумывай дальше.
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
H>Какая мысль очевидно приходит в голову. Во-первых, сделать несколько растров под разные зумы. При уже более-менее большом растре — начать бить на клетки и погружать те части, которые видит пользователь в данный момент. Это как бы очевидный подход. H>Но есть минусы, которые не нравятся. Во-первых, эти самые разные растры под разные зумы. Что-то дизайнерски некрасивое в этом есть. Во-вторых, перевод в растр сжирает преимущество наличия вектора.
H>Есть еще другая мысль. Мне собственно все преимущества SVG и не нужны. Нужны только контуры и на некоторых контурах заливка сплошным цветом. Все. То есть мысль перевести SVG в какой-то свой формат контуров и уже эти объекты раскидать по разным файлам и подгружать по мере необходимости.
H>Как делается обычно рендеринг карт или если не знаете, то как бы сделали вы?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, Barbar1an, Вы писали:
H>Да. Но только гораздо ближе, вплоть до куста. Данные уже есть. Только их дохрена.
а рисовать что нужно? 2Д или 3Д?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, Barbar1an, Вы писали:
B>>а рисовать что нужно? 2Д или 3Д?
H>2D
тогда это простой баян реализованный в 100500 игр,
разрезаете их все на тайлы (отдельный текстуры) и рисуете тока те которые видны
если в кадр попадает много тайлов то поможет только Level-0f-Detail
что тоже на самом деле баян реализованый еще в думе2
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, Barbar1an, Вы писали:
B>>а рисовать что нужно? 2Д или 3Д?
H>2D
если по сути ту нужно просто не рисовать то что не нужно(не видно), а для этого геометрию нужно запихнуть в структуру удобную для быстро опеределения видимости, для этого нашими прадедами были придуманы всякие древовидные разбиения пространива — https://habr.com/ru/post/312882/
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
