Данные Tiling Vector без потери геометрической и топологической информации

Я пытаюсь найти способ подразделить векторную карту на более мелкие блоки. Я могу разложить карту по разным стратегиям, таким как q-дерево. Однако неизбежно обрезать некоторые полилинии и многоугольники, которые пересекают границы блоков. Делая это, мы потеряем их геометрические и топологические атрибуты.

Плиточные данные можно использовать только для отображения, но не для пространственного анализа, поскольку они частично утратили свои геометрические и топологические атрибуты. Есть ли у вас какие-либо предположения или опыт с подразделением векторных данных и сохранением их применимости для пространственного анализа?

vector tiles vector-tiles

— weliam
источник

Вы хотите сделать то, что делает Google ?

— Кирк Куйкендалл

Ответы:

Tilestache - это инструмент с открытым исходным кодом для обслуживания плиток, который обслуживает мозаичные векторные данные, а также мозаичные изображения, на которые, возможно, стоит обратить внимание (либо как инструмент, либо через исходный код ).

PostGIS GeoJSON водитель создает GeoJSON вектор плитки и имеет возможность обрезать их или нет .

clipping: Логический флаг для необязательного ограничения выходных геометрий до границ вмещающей плитки. По умолчанию в фале. Это приводит к неполной геометрии, значительно меньшим размерам файлов и повышает производительность и совместимость с Polymaps (http://polymaps.org).

Недавно было опубликовано сообщение в блоге об использовании TileStache & OpenLayers для создания скрученных вручную векторных плиток .

— geographika
источник

но как только они обрезаются, разве это не нарушает пространственный анализ, который он хочет сделать?

— Ян Тертон

спасибо, география. но Иант прав. как только мы их разберем, пространственная информация будет ухудшена.

— Weliam

Но установив флаг в true, вы получите полную геометрию

— география

но затем функции могут простираться далеко за пределы плитки (в США между штатами 80 проходит от Нью-Йорка до Сан-Франциско), что убивает ваше повышение производительности.

— Ян Тертон

Возможно, вы сталкиваетесь с теорией об отсутствии бесплатного обеда ...

В зависимости от вашего варианта использования может потребоваться, чтобы мозаичные векторные данные для отображения, но второй не мозаичный экземпляр данных для анализа. Я мог бы счесть это полезным, если отношение анализа к отображению низкое.

— DavidF
источник

У нас есть операционные и складские базы данных. Операционные имеют много реляционных таблиц и практически не дублируют таблицы. Складские базы данных сглажены, никаких связей, много дублированных полей, но быстрые - никаких вычислений на лету. Хитрость заключается в автоматизации процесса от аналитического до плиточного без вмешательства пользователя. По сути, то, что ArcMap делает в своем новом элементе слоя «базовая карта» на лету, и Google Maps & Tilestache и его друзья: соберите классы объектов X, Y, Z в интересующей области, выбросьте весь их интеллект, объедините их в тупой растровый образ в кеше) и рисовать.

— Мэтт Уилки

С веб-точки зрения, вроде отправки всех ваших слоев данных клиенту в одном слое WMS?

— DavidF