Назустріч протоколу для кодування векторних даних у вигляді зображення

Це відповідь на це питання: Створення векторних полігонів із ефективністю візуалізації, як GISCloud?

У своїй відповіді Ягі окреслює обґрунтування кодування географічної інформації у форматі зображення та декодування її у браузері. Він зауважує, що "В даний час, щоб зробити це, вам доведеться розгорнути своє". Він також зауважує, що в даний час для цього немає стандартів.

З огляду на приголомшливі показники роботи, схоже, що громада може отримати користь від стандарту. З мого розуміння проблеми, це звучить як стандартний спосіб її вирішення міг бути реалізований. Назвіть це B-WFS.

Тоді моє запитання: як виглядає корисний протокол для кодування векторних даних у вигляді зображень? Чи є щось, що робить його занадто складним, щоб вирішувати корисно, чи це просто випадок "ще ніхто цього не зробив"?

web-mapping vector

— кансуруфус
джерело

Вибачте за моє невігластво, можливо, я не зрозумів, але геотиф з кольоровою таблицею не зможе зробити цю роботу?

— Пабло

Вибачте за моє незнання;) Я не впевнений, що таке таблиця кольорів, але я не думаю. Мета - не передавати зображення разом із відповідними метаданими. Як ви згадуєте, це вирішена проблема. Мета полягає в тому, щоб передавати векторні дані з метаданими у більш компактному форматі, ніж читабельний UTF-8 для людини. Зважаючи на те, що JavaScript погано оснащений для роботи з бінарними даними, задане рішення полягає в кодуванні даних у бінарному зображенні та декодуванні їх за допомогою HTML 5 Canvas для декодування зображення та перетворення їх у векторні об'єкти.

— canisrufus

@Pablo Припускаючи, що мережевий введення-виведення (а не аналіз) є вузьким місцем у роботі з векторами в Інтернеті, встановлений спосіб роботи з двійковими кодованими векторами повинен полегшити запис кращих веб-карт.

— canisrufus

Цікаво, зараз я це зрозумів ... Я зараз починаю працювати з веб-картами і все ще вивчаю основи. BTW, барвиста або кольорова карта - це таблиця, яка пов'язує значення растрової комірки з класом.

— Пабло

@monkut Так, інакше. :) Растеризація набору векторів - це просто надання. Вуаля. Растр! Те, про що я говорив у цьому питанні, різне. Ви повинні прочитати відповідь Рагі у питанні, з яким я пов’язаний; це повинно почати пояснювати, що я маю на увазі. Якщо ви виявите, що це все ще незрозуміло, мені знадобиться певний час, щоб виправдати справжню відповідь.

— canisrufus

Відповіді:

Виявляється, це непотрібна робота навколо. XHR2, частина оновлення до javascript, дозволить імпортувати і аналізувати бінарні дані, не примушуючи нічого.

— кансуруфус
джерело

Це не повинно бути окремим стандартом, оскільки специфікація 04-094 впровадження WFS, пункт 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. Введення / виведення, незалежно від того, на основі диска чи мережі (на наш випадок) на порядок повільніше. Як змінюється навантаження з останньої частини спектру в першу "передчасну" будь-якою шкалою?

— Рагі Ясер Бурхум