벡터 기와 조각에 대해 내가 선택한 기술 체계

2진 벡터 타일의 생산과 소비를 확대하기 위해 가능한 한 발자국을 찍는 작은 기술 체계를 구축하고 더 많은 사람들과 공유하도록 한다.이를 위해 내가 선택한 기술 체계는 다음과 같다.

gh:openmaptiles/openmaptiles

2진 벡터 기와를 생산하는 기술은 몇 가지 시스템이 있는데 저는 다음과 같은 경과 중 gh:openmaptiles/openmaptiles를 선택하여 평가하고 토론하기로 결정했습니다.집필할 때 이 소프트웨어를 능숙하게 사용하려는 생각은 변하지 않았다.
오픈 소스 소프트웨어로 2진 벡터 기와를 생산하는 기술이나, OpenStreetMap(OSM) 데이터로 비즈니스를 하는 기업의 여러분이 대량으로 공개되고 있다.다른 원본 데이터에서도 그 기술을 사용해서 상호 운용성을 확보하는 것이 전체적으로 큰 장점이라고 생각합니다.
상기 공개된 기본 지도인 이원 벡터 타일의 생산 기술 체계는 다음과 같은 세 가지가 있다.

맵박스를 주체로 구축한 맵닉을 바탕으로 한 기술 체계

Klokan Technologies를 주체로 구축한 Openmaptioles 시리즈의 기술 체계

Mapzen이 자신의 vector tile 서비스에 구축한tilezen의 기술 체계

이들 소프트웨어는 단일 또는 소수의 GIS 데이터를 바이너리 벡터 기와판, tippecanoe 등으로 변환하는 것과 달리 기가바이트 크기가 넘는 다양한 데이터를 대규모로 변환해 데이터 업데이트에 대응할 것으로 보고 있다.
그 중에서 맵닉은 복합적인 기술 체계이고 웹의 정보에 따라 맵박스 씨도 2진 벡터 필름 생산을 클라우드 환경의 특성으로 전문화하고맵박스도 일부는 벡터 슬라이스 모델에 대한 지식재산권 보호 조치를 취했다.이 일에 관해서는 추가 달력의 다른 항목에 소개되어 있다.아무래도 맥박스 자체가 사용하는 기술은 공유하고 싶은 쪽에서 만들어내기 어렵고 공유하기 어려운 기술이다.
한편, Openmaptiles는 개방원으로 maptunic 등을 사용하는 2진 벡터 타일 생산 체계를 실현하려는 동기를 바탕으로 제작된 것으로 2진 벡터 타일 생산 체계를 공유하는 것이 목적이다.
또한tilezen에 대해 치밀한 기술 체계라고 생각하지만 사용 방법의 문헌화는 Openmaptiles에 비해 그렇게 선진적이지 않고 Mapzen의 2진 벡터 필름 서비스도2진 벡터 기와 조각의 판본이 여전히 낡은 것임을 알 수 있다.
이러한 상황을 관측한 결과 우선 오픈맵tiles를 따라가야 한다. 만약에 오픈맵tiles가 사용하기 어려운 기술이라면 tippecanoe를 사용하여 대응하는 것이 좋지 않겠는가.

Docker 및 node

2진 벡터 타일 생산을 확대하려면 그 하급 기술의 발자국에 따라 작을수록 좋다.특히 중간부품과 프로그램 라이브러리의 도입은 번거롭기 때문에 이런 기술이 더 낮은 OS를 선택하는 기술이라면 기술을 확장하기 어렵다.
Openmaptioles/openmaptioles를 선택한 것을 계기로 가능한 한 생산 기술을 확대한 결과를 고려한 결과 기술 인프라로서'Docker와 node'를 선택하는 것이 좋을 것 같다.

Docker

저에게 있어서 Docker는 먼저 서버 측 처리를 컨테이너화하는 기술에 익숙한 기술로서 gh:openmaptioles/openmaptioles를 테스트하는 과정에서 2진 벡터 필름 생산과 같은 일괄 처리를 합니다.또는 일반적으로 OS를 뛰어넘는 지리공간 정보기술의 휴대성을 확보하기 위해 사용하는 편리한 기술이다.
Docker의 저위 기술은 아직도 다양한 전환에 직면하고 있는 것 같다. Docker를 사용하기 위해서는 깊은 설정이 필요하다. 그러나 Geor의 사람들에게도 이 기술을 본격적으로 활용해야 하기 때문에 좋은 점이 많다고 느끼기 시작했다.

node

데드는 자바스크립트와 같은 프로그래밍 언어를 사용해 데이터 흐름을 처리하는 환경으로 지구계 인상에서 맵박스가 특히 많이 사용된다.데이터 흐름을 처리하는 방법은 매우 많은데 자바스크립트를 사용하는 네트워크와 일치하고 가져온 OS에 대해 너무 걱정하지 않아도 된다는 것이 특징이다.
나 자신은 지금까지 지오의 일괄 처리에 루비를 사용했다.그러나 내가 지금 처한 환경에서 가능한 한 기술을 가로로 보급한다면 더욱 쉽게 구할 수 있는 환경에서 일하는 것이 더욱 유리해질 것이다.
최근 ES6는 노드나 블라우스 모두 정상적으로 사용할 수 있게 됐다.예전에는 자바스크립트의 장르가 많아 실용적인 기능이나 문법 사탕이 적다는 인상을 줬는데, ES6 덕분에 잘 쓴 것 같다.
저한테는 템플릿 문자열과 Arroy 함수 덕분에 루비를 잠시 떠나 노드에서 일하기로 결심했습니다.다음에 다시 소개하고 싶습니다.

클라이언트 라이브러리에서 상호 운용성을 계속 확인하다

바이너리 벡터 기왓장은 현재 벡터 tile-spec가 사실상의 표준 입장을 유지하고 있으며, Mapbox GL JS, ArcGIS API for JavaScript, Tangram, OpenLayers는 각각 벡터 tile-spec에 맞는 바이너리 벡터 기왓장 형식을 소비할 수 있다.
콘텐츠 제공자로서 바이너리 벡터 기왓장 규격을 독점했다는 이유로 불안해지지 말고 안정적인 표준 입장을 유지해달라는 것이다.
2진 벡터 기와 조각의 상호 운용성을 유지하거나 2진 벡터 기와 조각의 상호 운용성의 열매를 얻기 위해 여러 클라이언트 라이브러리에서 같은 2진 벡터 기와 조각을 계속 활용하려는 노력이 필요하다고 생각합니다.
이를 위해'이진 베이커튼 Ilska의 안정화'가 필요합니다. 이것에 대해서도 이 추가 달력의 다른 항목에 설명해 드리겠습니다.또한 2진 벡터 기와 모델에서'2진 벡터 기와 스타일에 대한 기술'이 단일한 표준으로 통일되는지, 단일화가 방해되는지 상당히 흥미로운 부분이다.여기서도 맵젠은 흥미로운 자리를 유지하고 있다.이것에 관해서는 조만간 쓸지도 모른다.또 Boundless는 OpenLayers에서 맵박스-style을 읽을 수 있는ol-mapbox-style을 개발해 흥미로운 곳이다.
2진 벡터 필름 모델과 2진 벡터 필름 양식의 상호 운용 문제를 주목하는 동시에 기술적인 작업으로서 여러 개의 클라이언트 라이브러리에서 2진 벡터 필름을 문제없이 소모하는 것을 계속 확인해야 한다.나는 이 때문에 일을 진행하고 싶다.
또 모바일 기기 OS 애플리케이션에 사용되는 웹 지도 라이브러리에 대해 잘 알지 못하기 때문에 다른 사람들의 토론을 기대할 수밖에 없다.

도해

이런 기술 체계를 도해해 보면 아래의 그림과 같은 형식이 될 것 같다.나는 이 구도에서 기술을 깊이 있게 하고 싶다.