Kolejna wielka rzecz w znormalizowanym formacie wymiany danych przestrzennych?

Pamiętam, jak czytałem kilka miesięcy temu, w drugiej połowie 2012 r., O skoordynowanym wysiłku grupy w celu opracowania nowego standardu udostępniania danych geograficznych / przestrzennych. Ma lub ma na celu zastąpienie de facto standardu pokazowego (20+ lat) standardowego pliku kształtu Esri jako środka do szerokiego udostępniania naszych danych na wszystkich urządzeniach i platformach. Oprócz rozwiązania najbardziej palących ograniczeń plików shapefile , ta nowa rzecz obejmuje także raster i metadane.

Ta ważna rzecz, której nie pamiętam, nie jest SpatiaLite - Shapefile przyszłości? lub Czy są jakieś próby zastąpienia pliku kształtu? ale niektóre wirujące wokół rozmowy były podobne. Spędziłem dziś trochę czasu, próbując to wyśledzić, ale moje poszukiwania nie spełniły tego zadania (co może nie wróżyć dobrze na przyszłość).

Jak nazywa się ten nieuchwytny projekt, który może głęboko wpłynąć na wszystkie nasze przepływy pracy? (Zakładając, że zejdzie z deski kreślarskiej, pan wie, że czegoś potrzebujemy .) I, w jaki sposób lub gdzie się w to angażuje, a przynajmniej śledzi?

Pomysł, o którym prawdopodobnie myślisz, to GeoPackage .

Tło.

Tło tego wymogu pochodzi z Centrum Geosprzestrzeniowego Armii USA, które jest częścią Korpusu Inżynierów, który szukał sposobu na umieszczenie map i innych informacji (punktów lub zainteresowań, tras, zdjęć i innych obserwacji) w prostym „jednym” plik ma wszystko ”dla aplikacji mobilnych. Pierwotnego rozwoju dokonano na publicznych listach mailingowych (jednej dla wektorów i jednej dla rastrów / kafelków ) w Grupach dyskusyjnych Google.

Kiedy OGC rozpoczęło aktywność testową OWS-9, prace rozwojowe i prototypy zostały przeniesione do OGC. Przyczyny tego są trochę skomplikowane, ale wydaje się, że dokonano tego w dobrych intencjach. Jedynym problemem było to, że musiałeś być „w” świecie OGC, aby zobaczyć, co się dzieje. Dwie listy Grup dyskusyjnych Google są w zasadzie martwe.

Gdy OWS-9 dobiegł końca, OGC (podyktowane przez NGA i Centrum Geosprzestrzeniowe Armii USA) wyodrębniło grupę roboczą ds. Standardów (SWG) w celu opracowania „właściwej” specyfikacji. OGC ma więcej szczegółów na ten temat .

Proces opracowywania specyfikacji OGC był początkowo nadzorowany przez Paula Daiseya. Był to interesujący proces, ponieważ przyciągał wiele uwagi z zewnątrz. Początkowa praca została wykonana w programie Microsoft Word, ale przeszła na rozwój w GitHub . Od 2017 roku krzesłem SWG jest Jeff Yutzler. Pamiętaj, że wersja GitHub jako Markdown nie jest oficjalną specyfikacją - jest w toku, podobnie jak kod źródłowy, gdy przechodzi z oficjalnej wersji do oficjalnej wersji.

Techniczny

Specyfikacja jest nieco trudna do odczytania (ale mam nadzieję, że trudno ją pomylić na etapie wdrażania). Stara się być jednoznaczna, nie miła. Najlepszym sposobem, aby zrozumieć, co się dzieje, jest znalezienie diagramu pokazującego relacje między tabelami. Wpatrz się w to przez chwilę, a to może zacząć mieć więcej sensu. Następnie spójrz na niektóre przykładowe dane (uwaga: może nie być aktualna do najnowszej specyfikacji).

Realizacja

Istnieje wiele wdrożeń ( linki znajdują się na stronie http://www.geopackage.org/ ). Uwaga: Pracowałem nad niektórymi z nich.

Przyszłość

Pod koniec 2017 r. Rozwój specyfikacji rdzenia spowolnił - pojawiają się nowe wersje, ale różnice są w większości niewielkie. Istnieje dość otwarty mechanizm rozszerzenia - niekompletna lista znajduje się na stronie http://www.geopackage.org/extensions.html . Przedłużenie elewacja była pierwsza, że SWG pracował, a praca najbliższej przyszłości na tabelach pokrewnych , który to sposób powiązać geoprzestrzennych funkcji z niektórych innych danych (np zdjęcie punkt orientacyjny lub PDF od startu i lądowanie „płyt podejścia” na lotnisko).

OGC sponsoruje niektóre organizacje członkowskie (firmy, uniwersytety) do wykonywania innych prac w ramach swoich działań testowych .