Czy są jakieś próby zastąpienia pliku kształtu? [Zamknięte]

67

Ostatnio spędzam dużo czasu przekształcając doskonale dobre nazwy pól, takie jak „Procent obywateli w wieku 25 lat i więcej z tytułem licencjata lub wyższym”, na „edbchogtr”, aby osiągnąć limit 10 znaków w polu DBF.

W innym wątku ( „Dziwactwa” w specyfikacji technicznej Shapefile ), geospatialpython skomentował, że „Pomimo wad, osobliwości i ograniczeń formatu pliku shapefile uparcie utrzymuje się w obszarze GIS i wokół niego. Każda inna próba zastąpienia go była zbyt rozdęta dla proste przechowywanie wektorów lub zbyt zastrzeżone ”.

Ta aktywność w połączeniu z komentarzem pana Lawhead'a zastanawia mnie:

  • czy kiedykolwiek podjęto jakiekolwiek wyraźne próby zastąpienia pliku kształtu jako wszechobecnego formatu przechowywania i wymiany danych GIS?
  • Czy są jacyś pretendenci?
  • Jeśli istniały konkurencyjne formaty, dlaczego zawiodły?
  • Czy Esri odmówiła ich poparcia, czy może historia jest po prostu technologiczną bezwładnością?
  • Jeśli nie było prób ... dlaczego nie?

Wydaje się, że moglibyśmy zrobić trochę więcej dla siebie, zarówno jako programistów GIS, jak i użytkowników.

shapefile  vector 
— canisrufus
źródło
2
@Mapperz Poza ostatnio wydanym Geodatabase API, nie widzę żadnych narzędzi do pisania geobazy, które są darmowe. Nie sądzę, że można by to uznać za zamiennik, z wyjątkiem części świata ESRI.
— canisrufus
2
Możesz pisać i czytać geobazy (za pomocą API) za pomocą GDAL gdal.org/ogr/drv_filegdb.html za pomocą resources.arcgis.com/content/geodatabases/10.0/file-gdb-api
— Mapperz
1
Chciałbym zobaczyć API Pythona do odczytu / zapisu Geobazy danych plików (przynajmniej prostych funkcji) bez licencji ArcGIS - to byłoby Otwarte.
— PolyGeo
2
@PolyGeo ty i wszyscy inni :)
— Ragi Yaser Burhum
3
@celenius From gdal.org/ogr/drv_shapefile.html „Geometria: Format Shapefile wyraźnie używa przesunięć 32-bitowych, a więc nie może przekroczyć 8 GB (w rzeczywistości używa przesunięć 32-bitowych do 16-bitowych słów). Dlatego nie zaleca się używania pliku rozmiar ponad 4 GB. Atrybuty: Format dbf nie zawiera żadnych przesunięć, więc może być dowolnie duży. ” Więc możesz mieć pliki DBF, które są dość duże, ale musisz uważać, aby twój shp przekroczył 4 GB. Więc bawisz się ogniem.
— Ragi Yaser Burhum

Odpowiedzi:

50

To temat, który zawsze się pojawia. Być może nie mam właściwej odpowiedzi, ale mogę wyrazić moją osobistą opinię .

Powód, dla którego są one obsługiwane, można przypisać kilku cechom na ich temat, więc wspomnę o kilku.

  • Po pierwsze, istnieje specyfikacja . Mam około trzydziestki i to istniało, odkąd byłem nastolatkiem. Można śmiało powiedzieć, że ta specyfikacja istnieje już od jakiegoś czasu. Oczywiście istnieje kilka innych formatów, które są również publikowane, ale różnica w tym jednym polega na tym, że ...

  • To jest stosunkowo proste! Jest zbudowany na bazie formatu DBF , który w tym czasie już istniał i był szeroko obsługiwany na kilku platformach / systemach operacyjnych. Były już parsery, które potrafiły odczytać połowę tego formatu (część DBF), więc ułatwiło to obsługę dodatkowego dodawania. Masz geometrię? Pewnie po prostu serializuj i napisz. Gotowe. Porównaj to z zasięgiem ! Spróbuj wyjaśnić komuś w prosty sposób, co robi czyszczenie topologii . Nie jest trywialne napisanie czysto topologicznego pokrycia.

  • Co najważniejsze, myślę, że głównym powodem, dla którego pliki kształtu są nadal popularne, jest to , że są one obsługiwane zarówno w systemach Open Source, jak i zastrzeżonych . Jaki wiesz GIS, który nie obsługuje plików kształtu?!? Niespotykane.

Jako zamiennik słyszymy o GeoDat bazach danych i Spatialite . Oba formaty są znacznie lepsze pod względem funkcjonalności, elastyczności, szybkości itp. W porównaniu z Shapefiles. Na swój sposób mają pewne rzeczy, które czynią je lepszymi od siebie w różnych obszarach, ale porównanie przestrzeni i FileGDB z pewnością nie wchodzi w zakres tego pytania.

Czy myślę, że którykolwiek z tych formatów zastąpi pliki Shapefiles? Nie w ich obecnych wcieleniach .

Dlaczego?

Nie z powodu argumentu technologicznego (powiedziałem przecież, że pod tym względem są lepsze), ale z powodu czegoś innego: licencjonowania.

Jakie są ich problemy?

FileGDB :

FileGDB zapewnia interoperacyjność dzięki nowemu API FileGDB. Niemniej jednak ten interfejs API jest dostarczany w formacie binarnymprzez ESRI. To nie jest specyfikacja. Pracując w przeszłości w zespole GeoDatabase, mogę ci powiedzieć, w przeciwieństwie do wszystkich teoretyków spiskowych noszących blaszany kapelusz, nie jest to wcale złośliwe. Jest tak, ponieważ elementy wewnętrzne GeoDatabase zmieniają się w każdym wydaniu. Publikacja pełnej specyfikacji wymagałaby zasadniczo podania wszystkich szczegółów dotyczących tego, jak wszystko powinno być utrzymywane, a następnie dokładnego dokumentowania zmian w formacie przy każdej corocznej wersji. To nie ma sensu. Dlatego API FileGDB, mimo że nie jest specyfikacją, wyodrębnia wszystkie te małe zmiany. A teraz można go używać na różnych platformach! Pamiętaj, to ogromny krok naprzód! Biorąc pod uwagę konserwatywny charakter ESRI, jest to zdecydowanie reakcja we właściwym kierunku.

A jednak wsparcie tylko binarne nie sprawia, że ​​nikt w świecie Open Source jest zbyt szczęśliwy. Jak zatem skorzystać z przeniesienia jakiegoś kodu, aby powiedzieć innemu smakowi Linuksa, jeśli ESRI go nie obsługuje. Nie możesz To sprawia, że ​​Open Source jest potężny, a teraz nie możesz z tego skorzystać. Jeśli ESRI zdecyduje się przestać wspierać Debiana, to wszystko. Gotowe. I nic nie możesz zrobić, aby to zmienić.

Przestrzenny :

Spatialite jest niesamowity, ponieważ oferuje wszystkie bezpłatne funkcje SQLite . SQLite jest używany wszędzie. Jest na telefonie z Androidem, iPhonie / iPadzie, Firefox, Google Chrome, na kilku komercyjnych urządzeniach wbudowanych - może trwać wiecznie. Aby naprawdę przekształcić go w Geoformat (a nie tylko wykonywać głupie operacje ograniczające), musi korzystać z tej samej biblioteki geometrii, z której korzysta PostGIS: GEOS . Niestety, GEOS opiera się na innej, jeszcze bardziej niesamowitej bibliotece geometrii znanej jako JTS . Wszystkie algorytmy w JTS są niezwykle wydajne, więc na czym polega problem?

Cóż, JTS jest licencjonowany jako Open Source LGPL , a LGPL jest licencją wirusową . JTS to LGPL, co oznacza, że ​​GEOS to LGPL, oznacza, że ​​przestrzennie powiązane statycznie z GEOS to LGPL. To jest do bani. Dlaczego? Bez zbytniego wyjaśniania licencji typu open source mogę powiedzieć, że na przykład nie mogę używać funkcji spatialite na, powiedzmy, aplikacji na iPhone'a, ponieważ to spowodowałoby, że cała moja aplikacja byłaby automatycznie open source (iOS umożliwia tylko statyczne łączenie). Jakikolwiek rodzaj licencji GPL (rozsądnie) odstrasza ESRI od bzdur, więc nie dotkną go słupem o długości 10 stóp. Dlatego ArcGIS, najpopularniejszy system GIS na świecie, nie obsługuje (i prawdopodobnie nigdy nie będzie) natywnie przestrzenny. To automatycznie zabija go jako realny format.

W ten sposób wracamy do gównianych plików kształtów, które są obsługiwane wszędzie.

Aktualizacja :

Najwyraźniej moja odpowiedź była na tyle kontrowersyjna, że ​​ktoś uznał, że swobodnie jest edytować i zmieniać całe znaczenie mojej odpowiedzi, aby przedstawić ich punkt widzenia. Proszę nie rób tego. Jeśli się ze mną nie zgadzasz, to w porządku, po prostu opublikuj swoją opinię w innej odpowiedzi i pozwól społeczności podjąć decyzję. Wycofałem zmiany do mojej odpowiedzi, aby pokazać oryginalne znaczenie. Dodaję tę aktualizację na wypadek, gdybyś przeczytał zredagowaną odpowiedź, która twierdziła, że ​​sqlite jest wykonalnym formatem.

— Ragi Yaser Burhum
źródło
Problem z SQLite / Spatialite polega na tym, że nie jest to format, to silnik relacyjnej bazy danych z biblioteką przestrzenną na nim. Chociaż robi to, co robi bardzo dobrze, zmusza dane do przechowywania w sposób relacyjny, co nie zawsze jest najodpowiedniejszym sposobem. Ponadto złożoność formatu pliku SQLite ( sqlite.org/fileformat2.html ) utrudnia dostęp do danych bez silnika SQLite, a zatem nie nadaje się jako otwarty i łatwo dostępny format plików do wymiany danych. To nie było do tego specjalnie zaprojektowane.
— Igor Brejc,
8
W rzeczywistości LGPL nie jest licencją wirusową - została specjalnie zaprojektowana, aby tego uniknąć. Dodatkowo, Spatialite jest licencjonowany na podstawie licencji Tri MPL ( źródło ), co oznacza między innymi, że możesz wybrać Licencję Publiczną Mozilla jako licencję najlepiej dopasowaną i działać na jej (bardzo słabych zasadach copyleft). Moim zdaniem przynajmniej ESRI nie ma powodu, aby nie wspierać Spatialite z powodu licencji - czy będą (pod warunkiem, że będą konkurować w prawie tej samej przestrzeni co FileGDB) to inna historia ...
— om_henners
3
@Ragi, miksujesz za pomocą biblioteki i przenosisz ją. Oczywiście portowanie będzie musiało być LGPL, ponieważ jest to w zasadzie praca pochodna. Ale jeśli połączysz go dynamicznie, nie będzie to uważane za dzieło pochodne, jest to „dzieło korzystające z biblioteki” i możesz zachować swoją licencję ( en.wikipedia.org/wiki/GNU_Lesser_General_Public_License ). Zatem powiedzenie „LGPL jest wirusowy” bez dodatkowych wyjaśnień nie jest dokładne.
— Igor Brejc
2
Ale znowu, jest to kwestia sporna, ponieważ Spatialite jest licencjonowany na podstawie schematu opartego na drzewach ( groups.google.com/forum/?fromgroups#!topic/spatialite-users/… ), więc możesz wybrać licencję, która odpowiada Ty najbardziej - MPL pozwala na statyczne łączenie.
— Igor Brejc
2
@ bugmenot123 Dobrze, a następnie popraw go, jeśli chcesz, ale nie oskarżaj mnie o rozpowszechnianie FUD na temat systemu operacyjnego, ponieważ jest to obraźliwe. Piszę kod systemu operacyjnego od ponad dekady (nie zdziwiłbym się, że tak naprawdę używałeś mojego) i to nie był zły gniew. To była prawda - i nadal tak jest. Dynamiczne linkowanie w iOS LGPL (cóż, mówiąc ściślej, frameworki , były dozwolone w iOS 8). To nigdy nie był problem techniczny, ale legalny. Dystrybucja w AppStore wymaga podpisywania kodu - i niestety dla wszystkich miłośników systemów operacyjnych takich jak ja - LGPL jest niewyraźną licencją na to. Bez precedensu w sądzie.
— Ragi Yaser Burhum
18

Sama część SHP + SHX nie jest taka zła. Prawdziwy problem leży w części DBF. Mógłby to zrobić z nowym formatem, który obsługiwał Unicode i wszelkiego rodzaju nowoczesne typy pól. Problem polega na tym, że jest dobrze obsługiwany przez wszystkie dostępne oprogramowanie.

— Uffe Kousgaard
źródło
6
+1 Ulepszenie w części DBF wcale nie jest trudne: tak naprawdę sprowadza się do przekonania twórców oprogramowania, aby zgodzili się na coś.
— whuber
1
Czy była próba?
— canisrufus
5
Często szukałem poprawki Shapefile, która po prostu zastąpiła plik CSV UTF-8 dla DBF. Wsparcie byłoby proste i wymagałoby minimalnych zmian w istniejących pakietach oprogramowania.
— scw
1
@canis Fox Software podjął niewielką (zastrzeżoną) próbę pod koniec lat 80. Po zakupie stwardnienia rozsianego (ok. 1990 r.) To było to. Społeczność stworzyła standard DBF 3 i to prawie zamroziło cały rozwój. MS wydało Access; FoxPro wymarł; świat ruszył dalej.
— whuber
1
Wręcz przeciwnie, @Uffe, pliki CSV są dostępne losowo: potrzebujesz tylko indeksu, podobnie jak pliki DBF, aby efektywne wyszukiwanie. Największym problemem, jaki widzę, jest to, że pozornie niewielkie zmiany, które naturalnie zdarzają się w plikach CSV, takie jak cytowanie ciągów lub konwersje CR / LF, zepsują wszystkie przesunięcia bajtów. Struktura rekordów o stałej długości pliku DBF, choć mniej wydajna w przechowywaniu, nie ma tego problemu.
— whuber
7

Przynajmniej spatialite ma taki zamiar, patrz np. Ta prezentacja http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf

Z drugiej strony uważam, że głównym powodem niepowodzenia było to, że shp jest dobrze obsługiwany przez wiele aplikacji i ma tylko niewielkie braki.

Inni podzielają również tę opinię:

Nie dzieje się tak dlatego, że projekt SpatiaLite nie dał nam narzędzi do wdrożenia, społeczność może mniej o to dbać. SHP działa dla nich i nie ma żadnego powodu, aby to zmieniać.

http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/

Więcej przemyśleń na temat geobazy danych Esri, spatialite i autodesk sdf tutaj: http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto

— johanvdw
źródło
Choć wydaje mi się, że spatiaLite jest świetna, to ~ 3 megabajty narzutu w funkcjach, systemach odniesienia itp., Które uniemożliwiają dobry format wymiany.
— Scro,
W rzeczywistości licencja na usługi przestrzenne jest mniejsza niż idealna - nie ma nic wspólnego z narzędziami.
— Ragi Yaser Burhum
@ Scro, 3 megabajty jest za duży? Na pewno nie jest za duży na pulpit. Musisz wziąć pod uwagę urządzenia mobilne. Ponadto, czy istnieje inny interfejs Spatial API o równoważnej funkcjonalności w rozmiarze mniejszym niż Spatialite?
— klewis
@ klewis - sam w sobie nie jest zbyt duży, jest po prostu bardzo nieefektywny, jeśli weźmie się pod uwagę, że istnieje wiele małych (przypuszczalnie <200kb) zbiorów danych. Jest to duży narzut, zwłaszcza w świetle faktu, że po otrzymaniu zwykle pozostawiałeś każdy zestaw danych w pliku 3 MB lub zrolowałeś go do istniejącej bazy danych. Żeby było jasne, I <3 spatiaLite - ale mówimy o transmisji danych, gdzie jakiś rodzaj płaskiego pliku / xml / wkb byłby znacznie bardziej wydajny.
— Scro
6

Esri od kilku lat promuje Geobazy Plików jako zamiennik plików kształtów.

Niedawno udostępnili interfejs API, który ukrywa wszelkie osobliwości.

— Kirk Kuykendall
źródło
Bardzo dużo nie pracowałem z geobazami. Wikipedia twierdzi, że są „zamkniętym” standardem, np. Specyfikacja geobazy nie została opublikowana. Wydaje się, że bardzo trudno jest uzyskać szerokie zastosowanie bez publikowania elementów wewnętrznych tego formatu. Chociaż jestem zbyt młody, aby znać historię, domyślam się, że pliki kształtów są po części tak popularne ze względu na publiczną część specyfikacji. Interfejs API wydaje się dobrym krokiem.
— canisrufus
1
@ czy masz rację. W tym czasie nikt nie przyjąłby plików kształtowych, z wyjątkiem tego, że ESRI specjalnie je promowało jako otwarty format wymiany danych GIS. Nawet przy ograniczonych narzędziach programowych dostępnych w tym czasie, wraz z wydaniem przez ESRI wyraźnej specyfikacji .shp / .shx (i zobowiązaniem do jej przestrzegania), napisanie kodu do przeczytania i zrobienia stało się kwestią zaledwie kilku godzin pracy zapisuj pliki kształtów: nie wymaga inżynierii odwrotnej.
— whuber
Tak długo, jak interfejs API jest binarnym blokiem BLOB czarnej skrzynki, FGDB nie będzie traktowane tak samo jak SHP. Nawet jeśli Esri przekonuje wszystkich swoich klientów do przejścia na FGDB z SHP, API nie jest tak naprawdę kompatybilny z open source.
— dericke
3

Dialekt XML, podobnie jak GML, zdecydowanie nie jest zoptymalizowany do obsługi ogromnych zestawów danych, ale może być używany jako format wymiany między oprogramowaniem lub platformami.

Nie sądzę, aby pojawił się problem z licencjonowaniem (patrz post Ragi Yaser Burhum o wirusowych cechach Spatialite) i dość łatwo jest przystosować istniejące parsery, jeśli jest to wymagane.

— Stéphane Henriod
źródło
1
Myślę, że nie wspomniano o tym tylko z tego powodu, że wychowujesz, że nie jest zoptymalizowany dla dużych zestawów danych. XML jest wzdęty. Wspomniane tutaj formaty są binarne, w których GML przechowuje punkty jako ciągi znaków. Rozmiar może być o rząd wielkości inny.
— canisrufus
3
Canisrufus ma rację. Istnieje kilka problemów z GML. Po Infosecie można nawigować za pomocą XPath, ale każdy, kto próbował wdrożyć indeksowanie przestrzenne na podstawie XML, powie ci, jak irracjonalne jest to i jak źle mapuje się do tradycyjnych relacyjnych baz danych. Bez wchodzenia w wiele szczegółów, jeśli coś tak podstawowego, jak indeksowanie i kwerendy, nie jest trywialne, format jest rozdęty i zasadniczo wymaga posiadania całego zestawu danych w pamięci, aby cokolwiek z nim zrobić, to nie jest to dobra opcja.
— Ragi Yaser Burhum
4
xml jest rozdęty, gdy jest przechowywany jako zwykły tekst. Istnieją swobodnie (zarówno bezpłatne, jak i modyfikowane i redystrybuowane) dostępne binarne biblioteki xml, które mogą służyć jako kropla zamienników dla czytników xml, dając ludziom swobodę korzystania zarówno z ludzkiej czytelności xml, jak i wydajności i wydajności przechowywania binarnych . Jedyny powód, dla którego mogę wymyślić, że nigdy nie jest podejmowany na dużą skalę, jest taki, jak zauważył powyżej johandvw : nikogo to nie obchodzi, .shp jest „wystarczająco dobry”, jak jest.
— matt wilkie
1

Żeby spojrzeć na to z innej perspektywy, nie jestem pewien, czy użycie „Odsetek obywateli w wieku 25 lat i starszych z tytułem licencjata lub wyższym” jest doskonale dobrą nazwą. Podczas gdy mieszanie spacji i apostrofów może być obsługiwane, jeśli piszesz kod lub zapytania, bardziej prawdopodobne jest wprowadzenie błędów.

Moim zdaniem przyszłość dystrybucji danych przestrzennych powinna koncentrować się na sieci i usługach internetowych, a specyfikacja WFS (która korzysta z GML) jest otwarta i ustalona. GeoJSON jest mniejszy i można go łatwiej obsługiwać w JavaScript. Jednak przy kompresji rozmiary są porównywalne.

Chciałbym także oddać głos na osobiste bazy danych ESRI . Może to być często złośliwy format Microsoft, ale obsługuje ODBC, zapytania SQL, widoki i pozwala programistom na tworzenie łatwych formularzy wprowadzania danych oraz uwzględnienie co najmniej pewnego poziomu kontroli integralności danych (typy danych, długości, unikalne wartości) .

— geografia
źródło
To ważny punkt. Ich zaletą jest to, że przy znajomości języka angielskiego można dowiedzieć się, co oznaczają pola.
— canisrufus
Ale tak naprawdę jest rola metadanych zestawów danych. Plik shapefile może używać pliku XML o tej samej nazwie do przechowywania tego.
— geografia
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.