Jaka jest różnica między zasięgiem, plikami kształtów i geobazami w ArcGIS?

Zastanawiałem się nad różnicą w metodyce przechowywania danych przestrzennych stosowaną przez Coverages, Shapefiles i Geodatabases w ArcGIS. Pokrycie było początkowym formatem, następnie Shape Files, a teraz Geodatabases. Co zatem poprawiło się w tych nowych formatach Shapefiles i Geodat baz danych?

Byłoby wspaniale, gdyby ktoś mógł wyjaśnić to przykładami.

To takie świetne pytanie. Pokrycia, Shapefile i Geobazy są zasadniczo różnymi magazynami danych geoprzestrzennych zarówno z punktu widzenia implementacji, jak i filozofii. Spróbuję podsumować, nie wchodząc w to zbyt głęboko.

1. Zakresy:

Pokrycia są interesującymi strukturami danych geoprzestrzennych . Koncentrują się na przechowywaniu topologii. Zobaczysz, że nacisk kładziony jest na przechowywanie najpierw elementów geometrycznych, czyli węzłów, krawędzi, które składają się na wszystkie geometrie. Zobaczysz wtedy oddzielny zestaw tabel, które odnoszą te geometrie do atrybutów (a zatem stają się elementami).

„Czysty” pokrycie gwarantuje pewne zasady, na przykład, że istnieją węzły na każdym skrzyżowaniu węzła, nie będzie miał dwa (lub więcej) węzłów na szczycie siebie (lub nawet w obrębie rozmytej odległości tolerancji), że nie ma dwie krawędzie jedna na drugiej itp. Mają także wyczucie kierunku (od-> do) i mogą rozróżniać między tym, co jest po jego lewej i prawej stronie.

Pokrycia działają naprawdę dobrze w przypadku edycji, które wymagają znajomości relacji topologicznych (wyobraź sobie edycję granicy działki). Ponadto pokrycia bardzo dobrze się kompresują, ponieważ usuwają nadmiar geometryczny z założenia. W rzeczywistości przekonasz się, że w dzisiejszych czasach nowoczesne formaty, takie jak TopoJSON, zaczęły wykorzystywać te same techniki, których nauczyliśmy się z relacji sprzed kilkudziesięciu lat.

Pokrycia mogą być nieco bardziej skomplikowane w pracy z danymi 3D (na przykład modelowanie mostu, który ma górną i dolną stronę po prawej stronie poniżej), ponieważ algorytmy, których używaliśmy do radzenia sobie z nimi, były z natury rozumiane dla matematyki płaskiego wykresu 2D .

Dlaczego więc odeszliśmy od tego? To wymagałoby dłuższej odpowiedzi, ale być może powinniśmy wyjaśnić nieco więcej, co sprawiło, że ESAP Shapefiles stał się popularny.

2. Pliki kształtu ESRI:

Wraz z nim pojawił się Shapefile. Prawdopodobnie najważniejszą cechą, jaką miał, było to, że była to specyfikacja otwarta, która była (względnie) prosta do wdrożenia. Atrybuty wykorzystywały pliki DBF , więc było już wiele bibliotek, które zaimplementowały dużą część specyfikacji. Nie było pojęcia „czystego”, co oznaczało, że każda indywidualna geometria musiała martwić się o reprezentację siebie bez uwzględnienia geometrii wokół nich lub ich przecięcia. Oznaczało to, że nie musieliśmy wykonywać skomplikowanej matematyki, aby upewnić się, że plik kształtu jest poprawny (w przeciwieństwie do odpowiednika pokrycia).

Czy krzyżują się ze sobą liczne geometrie? Jasne, czemu nie. Dwa punkty jeden nad drugim? Bądź moim gościem.

Czasami (prawdopodobnie) „najlepszy” format nie jest tym, który wygrywa, ale tym, który zostaje przyjęty. Jeśli format jest łatwy do wdrożenia, ma większe szanse na przyjęcie niż skomplikowany. To był Shapefile.

Nagle miałeś kilka bibliotek (open source i zastrzeżone) oraz dostawców oprogramowania, które je obsługiwały. Więc wszystko było świetnie.

Oczywiste pytanie brzmi zatem - dlaczego Geobazy?

3. Geobazy:

Uważam, że Geobazy są jednym z najbardziej niezrozumianych magazynów danych geoprzestrzennych. Ludzie zwykle myślą o nich jako o „formacie geoprzestrzennym”. Kilka lat temu ktoś zapytał: „Czym są geobazy ESRI?” . Zamiast powtarzać moją odpowiedź, zachęcam do przeczytania tego w pierwszej kolejności. Poczekam :)

Teraz, gdy przeczytałeś tę odpowiedź i wiesz, co to jest Geobaza, mogę nieco rozwinąć tę odpowiedź. W tym czasie prowadzono wiele badań optymalizujących SQL i pisanie optymalizatorów zapytań, które wykorzystywały indeksy, magazyny kolumn itp. (Wciąż istnieje). Budując Geobazę bazową na magazynie danych SQL, możemy bezpłatnie wykorzystać wszystkie te badania. Musimy tylko skoncentrować się na koncepcjach geoprzestrzennych, a ponieważ magazyny danych SQL stają się coraz lepsze, Geodatabase staje się również lepszy, za darmo . Niezła propozycja, co?

Obecnie istnieje kilka specyfikacji dla danych geoprzestrzennych. Jury wciąż zastanawia się, co zastąpi te technologie (jeśli w ogóle). Niemniej jednak, jeśli jesteś zainteresowany tym tematem, polecam przeczytanie odpowiedzi na pytania zadane tutaj w GIS.SE kilka lat temu: „Czy są jakieś próby zastąpienia pliku kształtu”

Mam nadzieję, że to pomoże!

Większość informacji można znaleźć w Pomocy Esri i niektórych wyszukiwaniach, więc właśnie skompilowałem kilka dobrych lektur.

Jak przechowywane są ubezpieczenia? Ponieważ jest to zastrzeżony format, nie znajdziesz żadnych specyfikacji technicznych dotyczących sposobu implementacji algorytmów (chyba że @Vince rzuci trochę światła).

Pliki kształtów pojawiły się później i zostały wdrożone jako standard, który zapewniał pewien poziom interoperacyjności. Opis techniczny pliku kształtu ESRI zawiera pełny opis.

Geobazy zostały wprowadzone później. Najpierw pojawiły się osobiste geobazy (MS Access), potem geobazy plikowe (w formacie binarnym) i geobazy korporacyjne (lub ArcSDE), które korzystały z technologii ArcSDE i DBMS. Możesz przeczytać więcej o geobazach tutaj: Rodzaje geobaz i Architektura geobazy .

Dobra lektura na GIS.SE: Czy użyć Geobazy danych pliku (* .gdb), Osobistej geobazy danych (* .mdb) czy plików kształtów?

Jeśli chodzi o wydajność, przeprowadzono wiele testów porównawczych, a geobazy danych w plikach okazały się najszybsze pod względem odczytu / zapisu informacji. Osobiste geobazy i pliki kształtu są znacznie wolniejsze i prawdopodobnie jedynym powodem ich użycia jest obsługa starszych systemów, które zostały zbudowane z myślą o logice biznesowej MS Access lub odczytywaniu / przekształcaniu plików kształtu.

Geobaza bazująca na ArcSDE często działa równie dobrze jak geobazy plikowe, gdy DBMS jest dostrojony, ale wszystko zależy od rodzaju przechowywanych danych, sieci i sprzętu. Więcej informacji na temat testów porównawczych można znaleźć w zasobach strategii projektowania systemu Esri (i tutaj ).

Podstawową różnicą między tymi formatami jest sposób, w jaki cechy odnoszą się do geometrii. W czasach świetności relacji językiem kodowym był FORTRAN, co oznaczało stałe rozmiary buforów w WSPÓLNYCH blokach. Najbardziej restrykcyjny z nich to 500 wierzchołków na linię pierwotną („łuk”). To ograniczenie wprowadziło pojęcie „pseudo-węzłów” (miejsc, w których łuki łączą się tylko z jednym innym łukiem) i skomplikowało wiele innych operacji dostępu do danych.

Model pokrycia wykorzystał „listę łuków wielokątnych” (PAL) do opisania wielokątów, co wymagało algorytmu cieniowania wielokątów do odczytania jednego pliku w celu uzyskania listy łuków, a następnie odczytu samych łuków w celu uzyskania liczby wierzchołków, a następnie przydzielenia wystarczającej ilości pamięci RAM, aby zapisz wszystkie wierzchołki, a następnie wróć, aby ponownie przeczytać łuki, tym razem kopiując wierzchołki w kolejności do przodu lub do tyłu, aby złożyć kompletny wielokąt. Dopiero po dwóch wizytach w pliku ARC można było odpowiednio opisać wielokąt, a następnie trzeba będzie uzyskać dostęp do wielu tych samych łuków (w przeciwnym kierunku), aby zacienić sąsiadów wielokąta.

Dla porównania, plik kształtu i różne formaty geobazy przechowują całą geometrię jako pojedynczy obiekt (z różnymi szczegółami implementacyjnymi dotyczącymi fizycznego wdrożenia obiektu). Ma to wady podczas próby edycji wspólnych granic, ale ta operacja jest znacznie rzadsza niż cieniowanie wielokątów.

Model przechowywania „całego kształtu” jest kluczową różnicą między formatem pokrycia a nowymi, a ta różnica jest tak fundamentalna, że ​​trudno jest dostrzec rzeczywistą różnicę między plikiem kształtu a różnymi formatami geobazy. W rzeczywistości format pliku kształtu był używany do uzyskiwania dostępu do geometrii FGDB za pośrednictwem interfejsu API FGDB, nawet jeśli FGDB nie używa tego dokładnego formatu, tylko dlatego, że było to prostsze niż wprowadzenie nowego układu wierzchołków.

Jeszcze jedna różnica między formatami polega na tym, że geobaza może modelować relacje między klasami obiektów . Jak zauważył Ragi,

Pokrycia działają naprawdę dobrze w przypadku edycji, które wymagają znajomości relacji topologicznych (wyobraź sobie edycję granicy działki).

Ale ta świadomość istnieje tylko w jednym zasięgu - jeśli chcesz modelować relacje między 2 lub więcej zasięgami, Twoim obowiązkiem jest napisanie kodu, który sprawdza wszelkie „nielegalne” relacje topologiczne.

Na przykład, jeśli wielokąty działki nie mogą mieć przerw, a granice działki powinny dokładnie pokrywać się z drogami, z pokryciami lub plikami kształtów, to do ciebie należy sprawdzenie, czy tak jest, i ręczne naprawienie błędów, w których te zasady nie są przestrzegane.

Geobaza może opcjonalnie obsługiwać obiekt Topologia , co pozwala zdefiniować dopuszczalne reguły topologiczne dla danych. Co ważne, reguły te mogą występować zarówno w obrębie klas obiektów, jak i między nimi, w twojej geobazie.

Narzędzia do edycji topologii w ArcMap pomagają znaleźć naruszenia topologiczne , aw niektórych przypadkach automatycznie je naprawić .

Przed wprowadzeniem topologii geobazy („stare dobre czasy”) często pisano długie i skomplikowane skrypty AML w celu wykrycia naruszeń topologicznych, a następnie ręcznie edytowano pokrycia w ArcEdit (niezbyt zabawne).