Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
Еще забыл про 3) на мелких масштабах (кстати, в прошлый раз я напутал и крупными их назвал) контуры объектов упрощались (выкидывались лишние промежуточные точки по особому алгоритму) и про то, что объектам задавался как минимальный, так и максимальный масштабные диапазоны отображения.
Скажем, город на мелких масштабах был условной точкой/кружочком с подписью, ближе становился контуром застройки (точка исчезала), еще ближе показывалась сеть линий-улиц, еще ближе — контуры отдельных кварталов (общий контур и линии улиц исчезали) и, наконец, появлялись контуры домов, дворовые проезды и прочее.
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать. H>Как рендерят большие карты?
Не совсем на эту тему, скорее, как один из приемов ускорения отрисовки:
Здравствуйте, Homunculus, Вы писали:
H>У меня есть гигантская детализированная SVG карта города. Размером около 1.5 гигов. H>Ясно, что и загрузка и рендеринг занимает кучу времени. Надо оптимизировать.
H>Как рендерят большие карты?
В SVG пространственные данные обычно не хранят. Лучше использовать специализированные форматы данных, особенно если город географически большой по размеру (чтобы учесть широту и долготу и текущую проекцию, т.к. проекции есть разные, и нужно понимать в какой именно проекции была изначальная переведенная в svg карта, если это не учитывать то рано или поздно появятся трудноуловимые и труднопонимаемые баги с нарушением координат).
Как рендерить, можно посмотреть опенсорсный GeoServer (это сервер, написанный на Java, который как раз умеет рендерить большие карты) + OpenLayers (это клиентская библиотека, которая позволяет рисовать карты, отдаваемые тем же GeoServer, в браузере).
У него есть несколько способов, но все они завязаны на тайловую структуру, т.е. карта всегда бьется на куски, причем на разных масштабах, и эти тайлы отдаются клиенту.
Отдаются клиенту тайлы либо в виде векторных (тут уже SVG можно использовать), либо растровых изображений. Их как правило кешируют, сервер делает это и на своей стороне, и клиент также может их кешировать у себя.
Здравствуйте, 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 г.
