GISCloud와 같은 렌더링 성능으로 벡터 다각형을 만드시겠습니까?


59

나는 호버 이벤트에서 각 다각형을 다른 색상으로 표시 할 수 있도록하기 위해 그러한 데이터를 영원히로드하지 않고도 웹 맵만들고 벡터 다각형을 오버레이 할 수있는 견고한 솔루션을 찾고 있습니다 .

내가 아는 한 캔버스, SVG, 플래시 중 하나를 통해이를 달성 할 수있는 3 가지 옵션이 있습니다.

플래시는 가장 빠른 렌더링과 가장 깨끗한 디스플레이를 제공하는 것처럼 애플 아이폰 / 아이 패드에서 작동한다면 최상의 솔루션 인 것 같습니다. 캔버스가 두 번째 최선의 선택 인 것처럼 보이지만지도에 수백 개의 다각형이 표시되는 경우 SVG가 렌더링하는 데 시간이 더 오래 걸립니다.

나는 이 문제에 대한 해결책을 찾는 데 거의 희망을 잃었 지만 오늘 GISCloud http://www.giscloud.com (현재 무료 가입 베타 버전) 이라는 회사를 발견했습니다 .

이 회사는 SOMEHOW가 수백 개의 벡터를 거의 실시간으로지도에 렌더링하는 놀라운 방법을 알아 냈습니다. 나는 그들의 접근 방식에 놀랐고 커뮤니티에 대한 나의 질문은 전단지, 오픈 레이어, 왁스와 같은 기존 기술에 사용하기 위해 접근 방식을 복제 할 수있는 방법과 관련이 있습니다.

이 놀라운 데모를보고 자신을 살펴보십시오 : http://www.giscloud.com/map/284/africa

페이지에서 다각형 위로 마우스를 가져 가서 확대 / 축소 컨트롤을 테스트하여 이러한 다각형이 실제로 벡터인지 확인하십시오.

Firebug로 요청을 살펴본 결과 맵에서 특정 json 파일을 요청하고 있다는 사실을 알았습니다. 확대 / 축소 수준 / 영역에 따라 여러 개의 json 파일이 요청 된 것 같습니다.


여기서 giscloud가 페이지에 데이터를로드하면 벡터 위로 마우스를 가져 가면 새 요청을 만들지 않고 즉시 색상이 변경됩니다.

예 :

URL 구조가 표준 타일링 서비스 논리를 따르는 것으로 가정합니다 (예 : 3 번째 폴더부터 마지막 ​​폴더까지 확대 / 축소 수준 ...).

어쨌든 나는이 json 파일의 실제 데이터를 분석했으며 그들이 사용하는 논리는 이러한 데이터 값을 기반으로 벡터를 생성하는 일부 유형의 논리를 따릅니다.

  • 너비 / 높이 : 각 json 요청에서 제공되는 데이터의 너비와 높이를 정의합니다.
  • 픽셀 : 여기에서 어떻게 든 일반화 된 포인트 레벨에 대한 일반적인 x / y 픽셀 좌표와 관련이 있다고 가정하고 픽셀 값을 정의합니까? 그들은 어떻게 든 줌 레벨에 따라 영역을 자동으로 단순화하는 방법을 가지고 있다고 생각합니다. 나는 픽셀 좌표를 사용한다고 가정하고 있는데, 위도 / 경도 데이터와 비교하여로드 해야하는 데이터의 크기를 크게 줄이고 있다고 생각합니다.
  • 스타일 : 여기에서 두 개의 RGB CSS 값을 정의합니다. 다각형 파일 색상을 나타내는 "F"및 다각형 테두리 색상을 나타내는 "S"
  • geom : 여기에서지도 컨테이너 창을 기반으로 데이터가 정의되는로드되는 타일 내에서 각 다각형을 정의하는 방법을 추측하고 있습니다. 또한 흥미로운 점은 각 항목에 "S"값이 있고 이는 선택적 속성 또는 기능 링크 값으로 사용되는 것으로 가정하고 각 항목 끝에는 벡터 ID 당 특정 ID를 정의하는 영역이 있습니다. 내가 추측하고있는 레이어 ID는 호출되는 각 json 타일 요청의 데이터를 어떻게 든 결합하는 데 사용됩니다.

또한 요청 된 타일에로드 해야하는 데이터의 크기에 따라 각 타일에로드 해야하는 데이터를 자동으로 결정하고 분할하는 방법을 어떻게 든 알아 냈습니다.

다음은 이러한 요청 중 하나를 추출한 것입니다.

{"width":256,"height":256,"tile":
{"pixels":
[0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]},

"styles":
[{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}],

"geom":
[
{"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"},
{"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"},
{"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"},
{"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"},
{"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"},
{"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"},
{"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"},
{"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"},
{"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"},
{...}
...
]
}

postgis를 사용하여 동일한 (또는 유사한) 유형의 속도를 어떻게 복제 할 수 있습니까?


아! JSON 파일을 보지 말고 전달되는 다른 중요하지 않은 이미지를보십시오. :) 아래 답변을 참조하십시오.
Ragi Yaser Burhum

"3 가지 특정 옵션이 있습니다"... 그렇다면 Silverlight, 다진 간은 무엇입니까?
Kirk Kuykendall

Silverlight에는 플러그인이 작동해야하며 giscloud가 사용하는 솔루션보다 실제로 더 빠르다고 생각하지는 않지만 직접 비교하지는 않았습니다.
NetConstructor.com

2
이 질문은 일반적인 Q & A 형식에 맞지 않는 많은 흥미로운 것들을 이야기합니다. 이제 그들에 대해 대화를 나눌 수 있도록 웹지도 세계의 벡터를 사용하여
매트 윌키를

@RagiYaserBurhum이 유사한 기술을 사용하여 여행 isochrone 매핑에 사용 된 방법의 좋은 설명이있다 : mysociety.org/2012/11/08/...은
djq

답변:


56

나는이 기술이 과거에 사용 된 것을 보았다. Michal Migurski가 TileStache를 만들 때 도움을 준 Zain Memon (Trulia 출신)이 나에게 설명했습니다. Zain 은이 문제를 오랜 SF GeoMeetup 회의 중 한 곳에서 사용하는 Trulia 데모를 설명하면서 설명 했습니다 . 사실, 다음 주에 SF에 있다면 (이것은 플러그에 대한 나의 절름발이 시도입니다. 그는 이것을 만질 것이므로 자유롭게 표시하십시오 :)

이제 설명을하겠습니다.

먼저 위의 json 파일을 볼 때 잘못된 위치를 약간보고 있습니다.

이유를 설명해 드리겠습니다 (가능한 한 짧게).

타일은 일반적인 렌더링 타일처럼 전달됩니다. 큰 문제는 없습니다.이를 수행하는 방법을 알고 있으므로 설명 할 필요가 없습니다.

Firebug에서 검사하면이 이미지 와 같이 비어있는 것처럼 보이는 이미지가 많이 있음을 알 수 있습니다 .

왜 비어 있습니까? 그렇지 않습니다. 픽셀은 기존의 가시 이미지 데이터가 아닌 데이터를 포함합니다. 그들은 픽셀 자체로 인코딩 된 데이터를 전달하기 위해 매우 영리한 기술을 사용하고 있습니다.

지난 10 년 동안 사람들은 스토리지 효율성을 희생하면서 형식의 가독성 및 이식성 데이터를 교환 해 왔습니다.

xml 샘플 데이터의이 예제를 보자.

<data>

  <feature>
    <point>
      <x> -32.1231 </x>
      <y> 10.31243 </y>
    </point>
    <type> 
      sold
    </type>
   </feature>

  <feature>
    <point>
      <x> -33.1231 </x>
      <y> 11.31243 </y>
    </point>
    <type> 
      available
    </type>
   </feature>

</data>

좋아, 이걸 몇 번 먹어? 우리는 utf8 (이 내용을 다룰 때 문자 당 1 바이트)입니다. 글쎄, 우리는이 176 바이트 를 만드는 약 176 개의 문자 (탭 또는 공백 제외)를 가지고 있습니다 (간단히하기 위해 여러 가지 이유로 낙관적입니다). 이 점을 염두에 두십시오!

그럼에도 불구하고, 그가 말하고있는 것을 이해하지 못하는 똑똑한 엉덩이는 어딘가에 "json이 압축률을 높인다"고 주장 할 것이다.

자, json과 동일한 XML 넌센스를 봅시다.

{ "data": [
            "feature" : { "x" : -32.1231, "y" : 10.31243 , "type": "sold" },
            "feature" : { "x" : -33.1231, "y" :11.31243, "type": "avail" },
          ]
}

여기 몇 바이트입니까? ~ 115 자라고 말합니다. 나는 약간의 속임수를 쓰고 작게 만들었습니다.

내 영역이 256x256 픽셀을 덮고 있으며 각 기능이 하나의 픽셀로 렌더링되고 너무 많은 기능이 있으므로 가득 차도록 확대 / 축소 수준이 높다고 가정하십시오. 65,536 개의 기능을 표시하려면 얼마나 많은 데이터가 필요합니까?

"기능"항목 당 54 자 (또는 utf 바이트-다른 항목은 무시) x 65,536 = 3,538,944 또는 약 3.3MB 곱하기

나는 당신이 그림을 얻는다고 생각합니다.

그러나 이것이 서비스 지향 아키텍처에서 데이터를 전송하는 방법입니다. 읽을 수있는 부풀어 오른 쓰레기.

내가 발명 한 이진 방식으로 모든 것을 전송하려면 어떻게해야합니까? 대신, 그 정보를 단일 밴드 이미지 (즉, 흑백)로 인코딩했습니다. 그리고 나는 0은 팔리고 1은 가능하고 2는 알지 못한다는 것을 의미했습니다. 1 바이트에서 256 옵션을 사용할 수 있으며이 예제에서는 2 ~ 3 개만 사용하고 있습니다.

스토리지 비용은 얼마입니까? 256x256x 1 (1 밴드 만). 65,536 바이트 또는 0.06MB 그리고 이것은 수십 년 동안 이미지 압축에 대한 연구에서 얻은 다른 압축 기술을 고려하지도 않습니다.

이 시점에서 사람들이 왜 단순히 json으로 직렬화하는 대신 이진 형식으로 인코딩 된 데이터를 보내지 않습니까? 우선, 자바 스크립트는 바이너리 데이터를 전송하는 데 많은 시간을 소비 하므로 사람들이 역사적으로 이것을하지 않은 이유입니다.

일부 사람들은 HTML5 의 새로운 기능 , 특히 canvas가 나왔을 때 멋진 해결 방법을 사용했습니다 . 그렇다면이 멋진 해결 방법은 무엇입니까? 이미지로 보이는 것에 인코딩 된 와이어를 통해 데이터를 전송할 수 있으며, 그 이미지를 HTML5 Canvas로 밀어 넣어 픽셀을 직접 조작 할 수 있습니다 . 이제 데이터를 가져 와서 클라이언트 측에서 디코딩하고 클라이언트에서 json 객체를 생성 할 수 있습니다.

잠시 멈추고 이것에 대해 생각하십시오.

방대한 양의 의미있는 지리 참조 데이터를 압축률이 높은 형식으로 인코딩하고 웹 응용 프로그램에서 전통적으로 수행 된 것보다 훨씬 적은 수의 순서로 자바 스크립트로 조작 할 수 있습니다.

HTML 캔버스는 그림을 그릴 때도 사용할 필요가 없으며 바이너리 디코딩 메커니즘으로 만 사용됩니다!

이것이 Firebug에서 보이는 모든 이미지에 관한 것입니다. 다운로드되는 모든 단일 타일에 대해 데이터가 인코딩 된 하나의 이미지. 그것들은 매우 작지만 의미있는 데이터를 가지고 있습니다.

그렇다면 서버 측에서 어떻게 인코딩합니까? 서버 측의 데이터를 일반화하고 데이터가 인코딩 된 모든 확대 / 축소 수준에 대해 의미있는 타일을 만들어야합니다. 현재이 작업을 수행하려면 사용자가 직접 롤아웃해야합니다. 즉시 사용 가능한 오픈 소스 솔루션이 존재하지 않지만이 작업을 수행하는 데 필요한 모든 도구가 있습니다. PostGIS는 GEOS를 통해 일반화를 수행하며 TileCache를 사용하여 타일 생성을 캐시하고 트리거 할 수 있습니다. 클라이언트 측에서는 HTML5 Canvas를 사용하여 특수 "가짜 타일"을 전달한 다음 OpenLayers를 사용하여 마우스 오버 효과가있는 벡터를 나타내는 실제 클라이언트 측 자바 스크립트 객체를 만들 수 있습니다.

당신은 더 많은 데이터를 인코딩해야하는 경우, (당신 픽셀 당 4 바이트 또는 4,294,967,296 번호는 표현할 수주는 당신은 항상 픽셀 당 RGBA 이미지를 생성 할 수 있음을 기억 픽셀 당을 ). 나는 그것을 사용하는 몇 가지 방법을 생각할 수 있습니다 :)

업데이트 : 아래 QGIS 질문에 답변합니다.

다른 대부분의 데스크탑 GIS 와 마찬가지로 QGIS 에는 고정 된 줌 레벨 세트가 없습니다. 어떤 크기로든 확대 / 축소 할 수있는 유연성이 있으며 렌더링 만 가능합니다. WMS 또는 타일 기반 소스의 데이터를 표시 할 수 있습니까? 물론 그들이 할 수는 있지만 대부분은 정말 바보입니다. 다른 범위로 확대하고, 경계 상자를 계산하고, 필요한 타일을 계산하고, 잡아서 보여줍니다. 대부분의 경우 HTTP 헤더 캐시와 같이 다른 항목을 무시하므로 다시 가져올 필요가 없습니다. 때때로 그들은 간단한 캐시 메커니즘을 구현합니다 (타일을 저장하고 요청하면 타일을 확인하고 요청하지 마십시오). 그러나 이것으로는 충분하지 않습니다.

이 기술을 사용하면 타일과 벡터모든 확대 / 축소 수준 에서 다시 가져와야 합니다 . 왜? 벡터는 확대 / 축소 수준에 맞게 일반화되었으므로

버퍼를 액세스 할 수 있도록 타일을 HTML5 캔버스에 배치하는 전체 요령만으로는 그 모든 것이 필요하지 않습니다. QGIS를 사용하면 Python 및 C ++로 코드를 작성할 수 있으며, 두 언어 모두 이진 버퍼 처리를 지원하므로이 해결 방법은이 플랫폼과 관련이 없습니다.

* 업데이트 2 ** :

처음에 일반화 된 벡터 타일을 만드는 방법에 대한 질문이있었습니다 (결과를 이미지로 직렬화하기 전에 아기 단계 1). 아마도 나는 충분히 명확하지 않았다. Tilestache를 사용하면 모든 확대 / 축소 수준에서 데이터의 효과적인 "벡터 타일"을 만들 수 있습니다 (타일 경계를 통과 할 때 데이터를 자르거나자를 수없는 옵션도 있음). 이를 통해 벡터를 다양한 확대 / 축소 수준에서 타일로 분리합니다. "클립하지 않음"옵션을 선택합니다 (하지만 더 많은 영역을 다루는 임의의 타일을 선택합니다). 그런 다음 GEOS 일반화 옵션을 통해 모든 벡터를 큰 숫자로 공급할 수 있습니다. 사실, 폴리 라인과 다각형이 스스로 접힐 수있을 정도로 커야합니다. 관련이 없습니다. Tilestache를 사용하면이 논리를 적용 할 수있는 쉬운 파이 토닉 데이터 공급자를 작성할 수도 있습니다. 이 단계에서 위의 다른 샘플 (또는 Trulia 하나)에서와 같이 json 파일 (아프리카지도 샘플의 일부와 마찬가지로) 또는 png의 직렬화 된 기하학으로 제공하도록 선택할 수 있습니다.


2
지금 까지이 기술을 사용하여 본 모든 사람이 코드를 게시하지 않았습니다. IMHO는 중요한 부분이 서버에서 실제로 발생하고 이에 대한 "표준"이 없기 때문에 각 픽셀의 의미 (1 = 판매, 2 = 사용 가능 등)를 선택하면 현재 코드에 따라 다르므로이 코드는 아마도 "일반적인"것은 아닙니다.
Ragi Yaser Burhum

1
QGIS에 대한 답변은 조금 더 복잡합니다. 출근길에 대한 답변을 업데이트하겠습니다. 놀라지 말고, 기차를 타서 GIS.SE에 답장하는 동안 운전하지 마십시오 :)
Ragi Yaser Burhum

12
+1이 읽기 쉬운 응답을 압축하지 않은 것에 감사드립니다 :)
Kirk Kuykendall

1
Silverlight 또는 Flash를 사용하여이 작업을 수행 할 수 있습니다. 그럼에도 불구하고, 플래시 나 실버 라이트의되지 않을 것 때문에 중요한 부분은 서버에서 일어나고 기억 도움의 많은.
Ragi Yaser Burhum

2
4 년 후 많은 것들이 발전했으며이 텍스트 상자에는 ~ 500자가 들어 있습니다. 요약하면 WebGL은 성숙하고 직렬화 기술을 넘어서 사람들은 Topojson과 같은 형식으로 고정밀 델타 인코딩 (60 년대에 사용했던 것처럼)을 적용하고 있습니다. 이것은 좋은 것입니다. 저는 OGC의 표준에서 이러한 것들을보고 싶습니다. 그럼에도 불구하고 OGC의 정치는 최근 매우 복잡했습니다. 2 년 전의 느낌은 다음과 같습니다. blog.burhum.com/post/50036141569/the-ogc-is-stuck-in-1999
Ragi Yaser Burhum

23

최근에 개발 디노 Ravnic에서 직접 메일 링리스트 게시물 :

우리가 그렇게 한 방법은 큰 비밀이 아니므로 여러분과 공유하게되어 기쁩니다. 열쇠는 두 가지입니다.

  1. 픽셀로 계산 될 때 그 면적이 작게 보이도록 작은 벡터를 타일에서 제거하는 것. 그래서 우리는 그러한 벡터를 드롭하고 대신 픽셀을 배치하므로 json 타일에 "pixels"속성이 있습니다

  2. 실제로 보이는 벡터는 일반화되고 좌표를 픽셀 단위로 타일에 기록합니다.

클라이언트 부분에서 우리는 캔버스에 정적 픽셀과 보이는 벡터를 렌더링합니다. 벡터의 상단에 우리는 마우스 이벤트 처리를 구현하여 호버링 즉 상호 작용 성을 달성했습니다. 그리고 그게 다야.

백엔드 맵 엔진은 사전 캐싱을 사용하지 않고 모든 타일이 즉석에서 생성되므로 모든 무거운 작업을 수행합니다. 빠르게 새로 고칠 수있는지도를 만드는 것이 매우 중요합니다.

따라서 클라이언트 쪽이 쉬운 부분 인 것 같습니다. 캐싱없이 데이터가 렌더링된다는 점이 인상적입니다.

그는 또한 귀하가 관심을 가질만한 호스팅 서비스에 대해 언급 합니다. 기성 서비스를 사용하는 비용으로이를 재현하는 데 드는 비용을 측정 할 수 있습니다.


나를 혼란스럽게하는 부분은 요청이 postgis로 전송되는 것처럼 보이고 위도 / 경도 값으로 표준 geojson을 얻는 대신 위도 / 경도 값을 xyz 좌표로 변환하고 뱉어내는 것처럼 보입니다. 확대 / 축소 수준 및 필요한지도 타일을 기반으로합니다. 이 속도를 얻는 데 무엇이 사용되고 있다고 생각하십니까?
NetConstructor.com

@netconstructor 어쩌면 기하학이 이미 xyz 기하학에 저장되어 있으므로 변환 할 필요가 없습니까?
geographika

상대적 xyz 좌표는 대역폭이 덜 필요한 상대적 위도 / 경도보다 짧을 수 있습니다.
Matthew Snape

우측하지만 그들은 즉시 해당 데이터를 변환하는하는
NetConstructor.com

17

OSGeo 목록에서 설명했듯이 핵심은 하위 픽셀 지오메트리에 대한 픽셀과 특정 수준에서 실제로 볼 수있는 기능에 대한 일반화 된 지오메트리가있는 벡터 JSON 타일로 데이터를 제공하는 것입니다. 이 기술은 불필요한 모든 벡터 정보를 제거하고 실제로지도에 시각적으로 영향을주는 벡터 만 남겨 두므로 성능이 뛰어납니다. 틈새를 채우고 서브 픽셀 벡터 대신 픽셀이 배치됩니다. 타일 ​​형식에 관한 것입니다.

백엔드쪽에는 진정한 무거운 리프팅이 있습니다. 우리는 TileStache 또는 다른 맵 엔진을 사용하지 않습니다. 우리는 많은 최적화를 통해 이러한 벡터 그래픽을 실시간으로 생성 할 수있는 자체 개발 한 것이기 때문입니다.

먼저 맵 타일을 SWF로 제공하는 작업을 시작했으며 요즘에는 HTML5 Canvas를 사용하여 그래픽을 렌더링 할 수 있도록 JSON에 출력을 활성화했습니다. 이러한 종류의 벡터 기술과 래스터 기술 (mapnik)을 비교 한 벤치 마크는 다음과 같습니다. 공정한 비교를 위해서는 CGI 모드의 결과 만 찾으십시오.

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vectors/

이 기술을지도 타일 호스팅 서비스로 제공 할 계획입니다. 아이디어는 클라우드에서 지리 데이터를 호스팅하고 HTML5를 통해 타일을 사전 캐시 할 필요없이 모든 맵 클라이언트에 데이터를 고속으로 제공하는 것입니다. 이 베타에 참여하려면 여기 ( http://www.giscloud.com/contact/) 로 문의하십시오.


1
벡터 데이터에 타일을 사용하는 아이디어는 매우 흥미 롭습니다 ( "공간 인덱스"에 대한 다른 표현처럼 보입니다). 여러 타일을 가로 지르는 피처를 어떻게 처리합니까? 그들은 잘랐습니까?
Julien

3
예, 벡터는 타일에 대해 잘립니다
디노 Ravnic

14

OSGeo Open Layers 포럼 에서 GIS Cloud 개발자가 GeoJSON 형상과 정적 픽셀의 흥미로운 조합 인 접근 방식을 설명하면서 매우 비슷한 질문이 최근에 제기 된 것 같습니다 . 실제로 사전 구축 된 GeoJSON 파일 캐시를 사용하는 대신 모든 벡터 타일을 즉석에서 생성합니다.

Esri는 ArcGIS Server 및 Feature Layers를 사용하여 유사한 접근 방식을 구현했습니다.이 기능 은 형상을 즉석에서 일반화하고 와이어로 JSON으로 전송할 수 있습니다.

실제로 구현할 수있는 간단한 방법의 경우 Tilestache ( PostGIS 지원 )를 사용하여 벡터 타일을 빌드 하고이를 Polymaps 에서 사용할 수 있습니다 . 폴리 맵은 SVG를 사용하지만 성능은 매우 뛰어나고 맵 요소의 스타일을 지정하는 CSS 규칙이므로 기능 렌더링은 전적으로 사용자에게 달려 있습니다. 다음 은 귀하가 요청하는 것과 유사한 것을 통해 작업하는 블로그 게시물입니다.


1
@wwnick-답변 주셔서 감사하지만 GisCloud.com은 모든 것을 실시간으로 의미하는 요소를 캐시하지 않고도 놀라운 처리 능력을 허용하는 몇 가지 추가 방법을 사용하고있는 것 같습니다. 질문에 현상금을 추가했으며 심층 솔루션 제공에 기꺼이 참여하기를 희망했습니다. 지금까지 답변 해 주셔서 감사합니다!
NetConstructor.com

6

Canvas를 사용하여 OpenLayers와 놀았으며 합리적인 결과를 얻었습니다.

다른 답변에서 언급했듯이 : 벡터를 즉시 전달하고 표시하려면 각 줌 레벨과 각 데이터 세트에 대해 벡터를 일반화해야합니다. 또한 Google 폴리 라인 인코딩을 사용하여 크기를 상당히 줄일 수 있습니다.

간단한 전달 메커니즘을 사용했습니다. 각 지오메트리는 JavaScript HTTP 응답 내의 JavaScript 함수였습니다. 타일 ​​기반 벡터 전송만큼 고급이 아니라 단순하고 오픈 소스입니다!

Canvas를 사용하여 Google Maps v3을 사용해 보지 못했지만 몇 가지 New York Times 데모 가 인상적이었습니다.


이 접근 방식의 문제는 50 만 개 폴리곤 즉, 성능을 처리 할 때 그들의 솔루션으로 빠른 속도로 도전적으로 정말 나쁜 아니에요이다
NetConstructor.com

추가 현상금을 확인하고 가능한 경우 자세한 솔루션을 제공하십시오. BTW New York Times는 giscloud.com이 사용하는 솔루션과 달리 매우 시원하면서 플래시를 사용합니다.
NetConstructor.com

링크가 오프라인 상태입니다
NetConstructor.com

그렇습니다. 죄송합니다. 4 년 동안 다각형으로 땜질 한 후 "취미"가 끝났습니다! GISCloud는 몇 년 전 인구 조사 데모가 시작된 이후 기술이 얼마나 발전했는지 보여줍니다. 위의 설명에서 이에 대한 언급을 제거했습니다.
마이너스 34

1
늦지 않는 것보다 훨씬 늦습니다! 가능한 한 "즉시"업데이트되도록 클라이언트 측 코드를 GitHub에 게시했습니다 . 새로운 코드 설정이 블로그에 올랐습니다 . 이제 PostGIS에서 직접 다각형을 읽고 PostGIS RESTful 웹 서비스 프레임 워크 ( PRWSF )를 통해 Thinning을 즉석 에서 Leaflet Javascript API 클라이언트에 적용합니다. 백엔드 코딩이 거의 필요하지 않습니다!
마이너스 34

6

이 회사에서 어떤 솔루션을 사용하는지 정확히 알지 못하지만 (직접 요청할 수 있음) 아이디어가 있습니다.

벡터 데이터의 네트워크 전송 및 렌더링 속도를 향상시키는 핵심 솔루션은 확대 / 축소 수준에 따라 일반화하는 것입니다. 높은 확대 / 축소 수준에서 전송 및 렌더링 훨씬 낮은 확대 / 축소 수준을 위해 설계된 수천 개의 객체는 종종 시간이 많이 걸립니다 (그리고 최종 디스플레이는 일반적으로 읽을 수 없기 때문에 쓸모가 없습니다 (예 : 이 이미지 참조 ). 이를 구현하려면 postgis 서버 데이터베이스가 다중 스케일 이어야합니다. 각 확대 / 축소 레벨 마다이 확대 / 축소 레벨에 적합한 객체가 하나씩 표시되어야합니다. 이러한 다른 표현은 일반화 기술을 사용하여 자동으로 계산할 수 있습니다. 또한, 서버에 의해 클라이언트로 전송 된 벡터 데이터는 공간 확장뿐만 아니라 줌 레벨에 의존해야합니다. 서버는 줌 레벨에 따라 적절한 데이터를 전송합니다. 이것은 이 우수한 논문 에서 방어 된 접근 방식입니다 :-)


0

Stanford Visualization Group이 개발 한 소프트웨어의 흥미로운 논문, 데모 및 소스 코드가 있으며, 각 타일에 대해 데이터 큐브를 사용하여 큰 지리적 데이터 세트를 시각화하고 탐색합니다. 포인트 데이터 세트에만 사용할 수 있지만 흥미로운 방법이 될 수 있습니다.

http://vis.stanford.edu/papers/immens

CartoDB 플랫폼과 Torque라는 라이브러리를 사용하여 많은 양의 데이터를 그리는 방법을 실험하고 있습니다.

http://cartodb.github.io/torque/
https://github.com/CartoDB/torque/tree/new_torque

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.