Какое количество меток может поддерживать SAS Planet

[Fetser]

C нетерпением жду реализации хотелок касательно работы с метками (0000033, 0000426, 0000425, 0001039) Проблема в том что очень большое количество тяжёлых меток (каждый объект это несколько сотен полигонов сложной формы) да ещё многопользовательский доступ.
Пока выхожу из положения, что упрощаю полигоны (к неудовольствию многих) Для многопользовательского доступа (требуется только чтение) При каждом запуске файлы с метками скриптом копируются из другого места в папку программы.
Может кто подскажет временные решения. А то тратится время на ненужное копирование. И вся работа страшно тормозится из за веса (каждый полигон в формате KML порой достигает 0.5 Мб, а их тысячи)
По сути одновременно все метки никто не смотрит, но угадать какие именно будут смотреть одновременно очень трудно.

[Tolik]

Fetser, любопытно узнать цифры.
Сколько именно меток, сколько всего точек (например, вершин полигонов), какой размер файла sml?
В чём проявляются тормоза - сколько сек. занимает какая-нибудь операция?

Также интересно, все метки загружаются в память при запуске программы или берутся из файла по мере необходимости?

[Fetser]

Пока тратится время только на копирование целиком файлов Categorymarks.sml и marks.sml. Время соизмеримо с запуском программы и это вполне приемлемо. Количество полигонов пока чуть более 5 000. Размер пока 20 Мб. Но это очень не нравится начальству, поскольку я каждую зону вещания радио и ТВ превращаю в один полигон и упрощаю до 25 кб файл kml. Реальные же размеры после расчёта зоны - это каждый передатчик примерно 200 полигонов суммарный размер 500 кб одна зона. И в идеале требуется все государственные передатчики России представить в виде подробных зон вещания. Уже несколько человек начали считать. И пока складывают kmz файлы. Просмотр надо организовать минимум с 50 рабочих мест. если полностью занести в тот формат что сейчас то размер будет около 10 Гб. Только на копирование при запуске программы с сервера уйдёт пол часа. Как себя поведёт программа если всё это должно уместится в оперативной памяти даже не представляю.

[vasketsov]

если полностью занести в тот формат что сейчас то размер будет около 10 Гб. Только на копирование при запуске программы с сервера уйдёт пол часа. Как себя поведёт программа если всё это должно уместится в оперативной памяти даже не представляю.

В такой ситуации спасёт только внешний сервер меток (надёжнее всего конечно поднимать взрослую СУБД), к которому сас будет ходить за новыми нужными метками (при чтении, и соответственно при записи новых меток их отправлять на сервер) и выгружать старые из памяти по мере ненужности. Даже просто хранить метки в файловой системе где попало проблему не решит, так как для их индексирования (чтобы потом понимать что качать и показывать, а что нет) их придётся фактически скачать и загрузить. А при многопользовательском доступе качать и индексировать придётся постоянно. Индексирование здесь - индекс по прямоугольнику, ограничивающему полигон снаружи. Соответственно формировать rect в сасе при сохранении полигона (это и так есть), и пихать в БД как блоб, оттуда забирать всю пачку (или как invalidate участками) и выгружать ненужное - по идее ничего сложного.

[Tolik]

10 ГБ - без полноценной БД не обойтись.

[vasketsov]

10 ГБ - без полноценной БД не обойтись.

Да, причём на отдельной тачке.

[vdemidov]

Для такого количества меток единственный вариант делать kml слой по принципам wikimapia

[Fetser]

Для такого количества меток единственный вариант делать kml слой по принципам wikimapia

Подскажите пожалуйста где можно подробнее почитать по созданию подобного слоя.
Хотелось бы найти ответы на вопросы
Каким способом обычные kmz/kml можно преобразовать в такой слой?
Что получится в том случае когда зоны будут частично или даже полностью накладываться друг на друга?
И есть ли возможность для основной массы пользователей сделать доступ только на чтение?

[vdemidov]

Каким способом обычные kmz/kml можно преобразовать в такой слой?

Понятия не имею. Готовых инструментов скорее всего нет.

Что получится в том случае когда зоны будут частично или даже полностью накладываться друг на друга?

Посмотрите как это сделано в викимапии. Сервер отдает тайлы в виде kml файлов, в каждом из которых описаны полигоны захватывающие данный тайл. Данные, конечно, будут многократно дублироваться, но в итоге клиенту отдается только то что нужно. Плюс можно фильтровать данные по зумам.

И есть ли возможность для основной массы пользователей сделать доступ только на чтение?

Поднимите веб сервер, который будет отдавать тайлы и вот вам доступ только на чтение.

[nafa]

Это очень просто реализовать с помощью БД.
В простейшем случае можно обойтись одной таблицей. В ней нужно сделать поля:
id (основной индекс)
xmin (индекс)
ymin (индекс)
xmax (индекс)
ymax (индекс)
kml (зависит от используемой БД, в некоторых можно и текстом обойтись)

При обращении за тайлом, выбрать из таблицы все записи, котоые охватывают хотя бы один из 4х углов тайла.
Подсчитать количество таких записей.
Если количество небольшое - то сгенерить общий KML и отдать его САС Планете.
Если количество большое (мелкий масштаб) - то по вашему усмотрению. Например можно отдать первые 5 или отдать служебный KML с сообщением о количестве объекто в тайле.

Пример как сделать есть в разделе wiki. Даже с возможностью не только просмотра, но и редактирования.

Вместо веб-сервера можно использовать версию САС Планеты с поддержкой PHP.

Это не оптимальный вариант, а самый простой. 10Гб с такой простой структурой любая современная БД потянет легко.

В более сложном варианте KML не используем. Создаем вторую таблицу с точками. При выборке проверяем, проходит ли через запрашиваемый тайл какой-то полигон.Можно также отдаватьне KML а графические тайлы с самостоятельно прорисованными линиями полигонов. В этом варианте количество можно увеличить количество отображаемой информации, если есть много пересечений объектов. Но запросы к БД более сложные.