벡터 데이터를 이미지로 인코딩하기위한 프로토콜로

이것은이 질문에 대한 후속 조치입니다. GISCloud와 같은 렌더링 성능으로 벡터 다각형 생성?

그의 대답에서 Yagi는 지리 정보를 이미지 형식으로 인코딩하고 브라우저에서 디코딩하는 이론적 근거를 설명합니다. 그는 "현재이 작업을하려면 자신의 롤을해야한다"고 관찰했다. 그는 또한 현재 이에 대한 표준이 없다는 것을 관찰했다.

놀라운 성능을 보여 주면 커뮤니티가 표준의 혜택을 누릴 수 있습니다. 문제에 대한 나의 이해에서, 그것은 그것을 처리하는 표준 방법처럼 들릴 수 있습니다. B-WFS라고 부릅니다.

내 질문은 다음과 같습니다. 벡터 데이터를 이미지로 인코딩하는 데 유용한 프로토콜은 무엇입니까? 유용하게 다루기에는 너무 복잡한 것이 있습니까? 아니면 "아무도 아직이 작업을 수행하지 않았습니다"라는 경우입니까?

web-mapping vector

— 큰 개자리
소스

나는 무지해서 미안하다. 어쩌면 나는 포인트를 얻지 못했지만 컬러 테이블이있는 지오텍이 일을하지 않았다?

— Pablo

내 무지에 대해서도 죄송합니다.) 컬러 테이블이 무엇인지 잘 모르겠지만 그렇게 생각하지 않습니다. 목표는 해당 메타 데이터가있는 이미지를 통과하지 않는 것입니다. 언급했듯이, 그것은 해결 된 문제입니다. 목표는 사람이 읽을 수있는 UTF-8보다 더 컴팩트 한 형식의 메타 데이터로 벡터 데이터를 전달하는 것입니다. JavaScript가 이진 데이터를 처리하기에 적합하지 않다면, 해결 방법은 이미지 이진으로 데이터를 인코딩하고 HTML 5 Canvas를 사용하여 디코딩하여 이미지를 디코딩 한 다음 벡터 객체로 변환하는 것입니다.

— canisrufus

@Pablo 파싱이 아닌 네트워크 I / O가 웹에서 벡터를 처리하는 데 병목 현상이 있다고 가정하면 이진 인코딩 된 벡터를 처리하는 방법이 확립되어 성능이 우수한 웹 맵을보다 쉽게 작성할 수 있어야합니다.

— canisrufus

흥미 롭습니다. 이제 이해가되었습니다. 이제 웹맵 작업을 시작하고 있으며 여전히 기본 사항을 배우고 있습니다. BTW, 컬러 테이블 또는 컬러 맵은 래스터 셀 값을 클래스에 연결하는 테이블입니다.

— Pablo

@monkut 예, 다릅니다. :) 벡터 집합을 래스터 화하면 렌더링됩니다. 짜잔 래스터! 이 질문에서 내가 말한 것은 다릅니다. 내가 연결 한 질문에서 Ragi의 답변을 읽어야합니다. 그것은 내가 의미하는 바를 설명하기 시작해야합니다. 여전히 확실하지 않은 경우, 실제 답변을 작성하는 데 시간이 걸립니다.

— canisrufus

답변:

이것은 불필요한 해결 방법입니다. 자바 스크립트로의 업그레이드의 일부인 XHR2는 아무것도 강제하지 않고 이진 데이터를 가져오고 구문 분석 할 수 있습니다.

— 큰 개자리
소스

WFS 구현 사양 04-094, 조항 9.4에 다음과 같이 명시 되어 있으므로 별도의 표준 일 필요는 없습니다 .

다른 형식의 출력 형식 (이전 버전의 GML, 비 XML, 이진 및 공급 업체별 형식 포함)도 outputFormat 속성에 대한 적절한 값 이 기능 문서에 광고되어있는 한 가능합니다 [절 13]. 이 규격은 기술 된 서술 식 [sic]이 거기에 나열된 각 출력 형식에 대한 기능 문서에 포함되도록 권장한다.

바이너리 지원을 추가하는 가장 쉬운 방법은 JSON 스트림을 GZIP하는 것입니다. 압축 해제는 대부분의 브라우저에서 자동으로 처리됩니다. 즉, 시도하지는 않았지만 이미 압축되지 않은 JSON을 지원한다고 가정하면 서버 및 클라이언트 측에서 최소한의 작업이 필요합니다.

— 머지 바이킹
소스

표준에 대한 포인트는 +1입니다. 압축은 같은 의미에서 이진 인코딩이 아닙니다. 이미지에 인코딩 된 지오 존과 지오메트리의 두 가지 접근 방식 사이의 성능에 대한 질문은 확실히 살펴볼 가치가 있습니다.

— canisrufus

맞습니다. 이렇게하면 네트워크 병목 현상이 줄어들지 만 클라이언트와 서버에 더 많은 부하가 가해집니다. 그러나 이미지에서 벡터 데이터를 인코딩하는 것은 가변 길이의 벡터 데이터로 인해 차선의 접근 방식 인 IMO입니다. 또한 벡터 데이터의 특성을 난독 화합니다. 더 나은 방법은 서로 다른 서버와 저장 장치에서 처리 한 다음 클라이언트에 의해 결합 될 수있는 두 개의 병렬 데이터 스트림 (벡터 용과 래스터 용)을 갖는 것입니다.

— MerseyViking

벡터 데이터의 가변 길이 문제는 기본적으로 네트워크가 패킷 전송을 처리하는 것과 같은 방식으로 처리 할 수 있습니다. 나는 그것의 차선책에 동의하지만, JS가 바이너리를 잘 다루지 못한다는 사실에 우리는 밀어 넣는 것처럼 보입니다. 시간이 있으면서 직접 무언가를 작성하고 구현하려고합니다. 내가 뭔가 일을 얻을 때 여기에 넣어 드리겠습니다 ...

— canisrufus

나는 Ragi가 그의 대답에서 그것을 명확하게 정의했다고 생각합니다. 나는 그렇지 않은 것에 동의합니다. :) 이진 형식이 전체적으로 더 빠른 데이터 전송 형식 일 수 있다는 가설이 잘못되었을 수 있습니다. 그 차이는 무시할 수 있습니다. 나는 "성능에 대한 시사점은 ... 조사 할 가치가있다"고 말했다. 분명히 이진 형식을 정의한 다음 승리를 선언 할 수는 없습니다. 우리는 볼 것이다!

— canisrufus

@MerseyViking 대답을 다시 반복하지 않고도 CPU 사이클 측면에서 관점을 고려해 보겠습니다 (여러분의 가정은 조기 최적화에 관한 것이므로). L1 캐시 액세스 = 1 CPU주기, L2 = 14주기, RAM ~ 250주기, Disk = 41,000,000, 네트워크 (대역에 따라 다르므로 친절해야 함) = 240,000,000. 디스크 기반이든 네트워크 기반이든 (우리의 경우) I / O가 훨씬 느리다. 스펙트럼의 마지막 부분에서 첫 번째 "초기"로 어떤 하중으로 부하를 이동 시키는가?

— Ragi Yaser Burhum