Пиксели против координат
Когда я думаю о растровых картах, моя первая мысль - спутниковые снимки. Почти каждый пиксель в детальном спутниковом изображении городской местности может содержать уникальную информацию. Одна плитка на веб-карте (обычно это вариант Mercator, слабо называемый « Сферический Меркатор » или « Веб-Меркатор » и поддерживаемый Google , Bing , Yahoo, OSM и ESRI) обычно имеет 256 x 256 = 65 536 пикселей, и каждый Уровень масштабирования имеет (2 ^ zoom * 2 ^ zoom) плитки. Когда я думаю о векторе, я думаю о многоугольниках и линиях. Например, файл формы, детализирующий границы зонирования всей области города (возможно, миллионов растровых плиток), может иметь только 65 000 векторных фигур.
Точное масштабирование
Похоже, вы (и, вероятно, большинство читателей) уже знаете наиболее очевидную разницу между растровыми фиксированными пикселями и вектором (координатными картами). Векторные рисунки (и карты) могут масштабироваться с более высокой степенью точности, чем пиксели, потому что векторные данные содержат шаблоны координат (точки, многоугольники, линии и т. Д.), Которые могут отображаться относительно друг друга с различными разрешениями с использованием простых формул, в то время как при изменении размера пикселей обычно используется алгоритм сглаживания, который приводит к артефактам изображения.
Сжатие изображений и сжатие структур
На практике большинство изображений, не имеющих 100% уникальных пикселей, могут быть сжаты в меньшие пакеты данных, а многие векторные файлы содержат избыточную детализацию, которая не требуется при многих низких уровнях детализации. Сжатие изображений является хорошо известным и очень эффективным процессом, и почти каждая библиотека кодирования имеет встроенные классы для этой работы. Сжатие векторной координаты, или «упрощение геометрии», встречается немного реже (поскольку ГИС в целом немного реже, чем обычные манипуляции с изображениями). По моему опыту, вы будете тратить около 0 раз на размышления о сжатии изображений (просто выключите или включите их) и значительно больше времени на размышления о пространственном сжатии. Посмотрите алгоритм Дугласа Пекера для примеров или просто поиграйтесь с QGIS и некоторые граничные файлы переписи.
Рендеринг на стороне клиента и на сервере
В конечном итоге все, что просматривается на компьютере, отображается в пикселях на экране с определенным разрешением (т. Е. Уровнем масштабирования). Зачастую (особенно в Интернете) задача состоит в том, чтобы максимально эффективно отображать эти пиксели перед пользователями. Эти файлы формируют группы US Census ТРАКТ & Blockособенно интересны, потому что они находятся за границей наборов векторных данных, которые «слишком велики», чтобы отображать их в веб-браузере как векторные данные. В отличие от этого, в современных браузерах округа США едва ли можно представить как векторную загрузку. В то время как файл векторной формы группы блоков переписи США, безусловно, будет меньше растрового набора листов, отображаемого для охвата всего США с несколькими уровнями масштабирования, файл формы группы блоков слишком велик (около 1 ГБ) для веб-браузера, чтобы его можно было загрузить по требованию. Даже если веб-браузер может быстро загрузить файл, большинство веб-браузеров (даже использующих флэш-память) работают довольно медленно при рендеринге огромного количества фигур. Таким образом, для просмотра больших векторных наборов данных вам лучше перевести их в сжатые изображения для передачи в веб-браузер.
Некоторые практические примеры
Несколько дней назад я ответил на аналогичный вопрос о рендеринге больших наборов данных в картах Google. Вы можете увидеть вопрос и подробный анализ «лучших практик», которые используются NY Times и другими сегодня здесь .
Несколько лет назад было решено перейти от векторного рендеринга на стороне клиента с интенсивной флэш-памятью к векторному рендерингу на стороне сервера, который доставляет фрагменты сжатого изображения в чистый HTML и JavaScript. У нас есть галерея карт с несколькими версиями Html + Raster (серверные сгенерированные изображения) и Flash + Vector (интенсивный рендеринг на стороне клиента).