На пути к протоколу для кодирования векторных данных в виде изображения

Это продолжение этого вопроса: Создание векторных полигонов с производительностью рендеринга, как GISCloud?

В своем ответе Яги обрисовывает логическое обоснование кодирования географической информации в формате изображения и ее декодирования в браузере. Он отмечает, что «В настоящее время, чтобы сделать это, вы должны катиться самостоятельно». Он также отмечает, что в настоящее время для этого нет стандарта.

Учитывая демонстрируемую потрясающую производительность, кажется, что сообщество может извлечь выгоду из стандарта. Исходя из моего понимания проблемы, кажется, что можно реализовать стандартный способ решения этой проблемы. Назовите это B-WFS.

Тогда мой вопрос: каким будет полезный протокол для кодирования векторных данных в виде изображений? Есть ли что-то, что делает его слишком сложным, чтобы его можно было бесполезно решать, или это просто случай "никто еще этого не сделал"?

web-mapping vector canisrufus
источник

Прошу прощения за мое невежество, может быть, я не понял, но геотиф с цветовой раной не справился?

Пабло

Извините за мое невежество тоже;) Я не уверен, что такое таблица цветов, но я так не думаю. Цель не передать изображение с соответствующими метаданными. Как вы упоминаете, это решенная проблема. Цель состоит в том, чтобы передавать векторные данные с метаданными в более компактном формате, чем UTF-8, читаемый человеком. Учитывая, что JavaScript плохо приспособлен для работы с двоичными данными, обходной путь заключается в кодировании данных в двоичном изображении и его декодировании с использованием HTML 5 Canvas для декодирования изображения, а затем превращения его в векторные объекты.

canisrufus

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

canisrufus

Интересно, теперь я понял ... Я начинаю работать с веб-картами и все еще изучаю основы. Кстати, colortable или colormap - это таблица, которая связывает значение растровой ячейки с классом.

Пабло

@monkut Да, это другое. :) Растрирование набора векторов - это просто рендеринг. Вуаля. Растр! То, о чем я говорил в этом вопросе, отличается. Вы должны прочитать ответ Раги в вопросе, с которым я связан; это должно начать объяснять, что я имею в виду. Если вы обнаружите, что это все еще не ясно, я найду некоторое время, чтобы написать реальный ответ.

canisrufus

Ответы:

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

canisrufus
источник

Это не должен быть отдельный стандарт как таковой, потому что в спецификации реализации WFS 04-094, пункт 9.4, говорится:

Другие выходные форматы (включая более старые версии GML, не-XML, двоичные и специфичные для производителей форматы) также возможны при условии, что соответствующие значения для атрибута outputFormat объявлены в документе о возможностях [пункт 13]. Эта спецификация рекомендует включать описательный образный [sic] в документ возможностей для каждого выходного формата, перечисленного там.

Самый простой способ добавить бинарную поддержку - просто GZIP-поток JSON, где декомпрессия автоматически обрабатывается большинством браузеров. Тем не менее, я не пробовал, но это потребовало бы минимальной работы как на стороне сервера, так и на стороне клиента, предполагая, что оба уже поддерживают несжатый JSON.

MerseyViking
источник

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

canisrufus

Вы правы, это уменьшает узкие места в сети, но увеличивает нагрузку на клиента и сервер. Но кодирование векторных данных в изображении, IMO, является неоптимальным подходом из-за переменной длины векторных данных. Это также запутывает характер векторных данных. Лучшим подходом может быть наличие двух параллельных потоков данных, одного для векторного и одного для растрового, которые могут обрабатываться различными серверами и устройствами хранения и затем объединяться клиентом.

MerseyViking

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

canisrufus

Я действительно думаю, что Раги четко определил это в своем ответе. Я бы согласился, что я не сделал. :) Возможно, гипотеза о том, что двоичный формат может быть в целом более быстрым форматом передачи данных, неверна. Разница может быть незначительной. Я сказал, что «последствия для производительности ... стоит изучить». Очевидно, я не могу просто определить двоичный формат, а затем объявить победу. Посмотрим!

canisrufus

@MerseyViking Не повторяя мой ответ, позвольте мне представить это в перспективе с точки зрения циклов ЦП (так как вы предполагаете преждевременную оптимизацию). Доступ к кэш-памяти L1 = 1 цикл ЦП, L2 = 14 циклов, ОЗУ ~ 250 циклов, диск = 41 000 000, сеть (зависит от пропускной способности, поэтому давайте будем любезны) = 240 000 000. Ввод-вывод, будь то дисковый или сетевой (в нашем случае) на несколько порядков медленнее. Как перенос нагрузки с последней части спектра на первую «преждевременный» по какой-либо шкале?

Раги Язер Бурхум