W kierunku protokołu do kodowania danych wektorowych jako obrazu

Jest to kontynuacja tego pytania: Tworzenie wielokątów wektorowych z wydajnością renderowania taką jak GISCloud?

W swojej odpowiedzi Yagi przedstawia uzasadnienie kodowania informacji geograficznych w formacie obrazu i dekodowania ich w przeglądarce. Zauważa, że ​​„obecnie, aby to zrobić, musisz rzucić własnym”. Zauważa również, że obecnie nie ma na to żadnego standardu.

Biorąc pod uwagę pokazaną niesamowitą wydajność, wydaje się, że społeczność może skorzystać ze standardu. Z mojego zrozumienia problemu wydaje się, że można go wdrożyć w standardowy sposób. Nazwij to B-WFS.

Moje pytanie zatem: jaki byłby użyteczny protokół do kodowania danych wektorowych podczas wyświetlania obrazów? Czy jest coś, co sprawia, że ​​jest to zbyt skomplikowane, aby poradzić sobie z tym pożytecznie, czy jest to tylko przypadek „nikt jeszcze tego nie zrobił”?

Okazuje się, że jest to niepotrzebne obejście. XHR2, część aktualizacji do javascript, pozwoli na import i parsowanie danych binarnych bez niczego zmuszania.

Nie musi to być osobny standard jako taki, ponieważ specyfikacja implementacji WFS 04-094, klauzula 9.4 mówi:

Możliwe są również inne formaty wyjściowe (w tym starsze wersje GML, inne niż XML, binarne i specyficzne dla dostawcy formaty), o ile odpowiednie wartości atrybutu outputFormat są podane w dokumencie możliwości [klauzula 13]. Ta specyfikacja zaleca, aby opis dokumentu [sic] był zawarty w dokumencie możliwości dla każdego formatu wyjściowego tam wymienionego.

Najłatwiejszym sposobem dodania obsługi binarnej jest po prostu GZIP strumień JSON, gdzie dekompresja jest obsługiwana automatycznie przez większość przeglądarek. To powiedziawszy, nie próbowałem tego, ale wymagałoby to minimalnej pracy zarówno po stronie serwera, jak i klienta, zakładając, że obie już obsługują nieskompresowany JSON.