Jaka jest dobra konwencja taksonomiczna lub nazewnicza dla plików i folderów zawierających dane GIS? [Zamknięte]

W ciągu ostatnich 8 lat moja firma zgromadziła około 30 TB danych GIS i zawsze zadaję sobie następujące pytania:

1. Jakie dane mamy dla danego obszaru geograficznego?
2. Jakie są szczegóły dotyczące tych danych (np. Rozdzielczość w metrach na piksel)?
3. Gdzie są dane na dysku twardym, aby móc z nich faktycznie korzystać?
4. Czy dane zostały już przetworzone, czy są w niezmienionej formie ze źródła?

Do tej pory próbowałem odpowiedzieć na te pytania, opracowując odpowiedni folder i hierarchię plików. Czy ktoś ma jakieś pomysły / sugestie dotyczące zrozumiałych, być może nawet standardowych sposobów organizacji danych GIS przy użyciu plików i folderów?

Jestem również otwarty na więcej informacji o tym, jak korzystanie z bazy danych może przynieść korzyści mojej firmie; jesteśmy programistami, a nie ekspertami w zakresie GIS, więc podejrzewam, że jesteśmy nieco w tyle za tym, jak najlepiej podejść do problemu przechowywania / organizowania danych GIS w celu ułatwienia użytkowania. Widziałem pytanie Najlepsze praktyki zarządzania danymi geoprzestrzennymi, ale z odpowiedzi mogłem jedynie czerpać marginalnie, ponieważ nie jestem zaznajomiony z geobazami.

AKTUALIZACJA: W ubiegłym tygodniu spędziłem sporo czasu czytając o bazach danych GIS i zacząłem się zapoznawać z PostGIS. W perspektywie długoterminowej myślę, że ostatecznie przejdziemy na zatrudnienie bazy danych i serwera metadanych, zgodnie z zaleceniami JasonBirch w najlepszych praktykach zarządzania danymi geoprzestrzennymi .

Jeśli faktycznie próbujesz edytować dane lub opracować mapę, będziesz musiał trzymać dane, nad którymi aktywnie pracujesz, oddzielnie od danych, z którymi zacząłeś. Kiedy rozpoczynam projekt, tworzę folder SourceData z podkatalogami nazwanymi według typu danych (DEM, orthofhoto, hydrologia itp.). To pomieści wszystkie warstwy, których używam tylko w celach informacyjnych. Wszelkie dane, nad którymi pracuję, zostaną skopiowane do innego folderu o nazwie Praca. Folder roboczy zawiera dane, MXD i wszystko, co modyfikuję lub tworzę w podkatalogach, które zwykle korelują z fazą projektu (MXD, RoadEdits, Delivery itp.)

Oprócz rzeczywistych danych GIS należy utworzyć folder Komunikacji lub Specyfikacji, w którym będą przechowywane wszelkie dokumenty od klienta / klienta wewnętrznego / profesora. Może to służyć jako metadane, gdy wrócisz do projektu w późniejszym terminie, a także tworzyć scentralizowane miejsce, w którym każdy może zobaczyć, co się dzieje.

Wydaje mi się, że potrzebujesz zestawu metadanych do przechowywania tych informacji oraz systemu wyszukiwania, który wykorzystuje metadane, aby umożliwić Ci wyodrębnienie danych na podstawie tych informacji.

Myślę, że potrzebujesz rozwiązania obsługującego usługę katalogową OGC, zapewniającą maksymalną interoperacyjność. Widziałem, jak koledzy używają Deegree - choć oczywiście są inne rozwiązania, które powinieneś sprawdzić.

Oto przykład, w jaki sposób przywiązaliśmy Deegree do naszego oprogramowania (demo na żywo jest obecnie w trakcie prac konserwacyjnych - nie wiecie! - ale powinno zostać przywrócone w przyszłym tygodniu)

Jeśli chodzi o nazewnictwo plików, jeśli masz usługę katalogową i mechanizm dostarczania, wtedy mniej problemów dotyczy nazw plików i ich lokalizacji. W przeciwnym razie myślę, że zależy to od tego, jak szukasz danych. Czy najpierw zaczynasz od zawężenia obszaru geograficznego lub rodzaju danych? To określi, czy hierarchia zaczyna się od podzielenia danych na kafelki, a następnie typy danych na kafelek; lub dzieląc je na typy danych, z których każdy ma zestaw kafelków.

Oczywiście w przypadku przestrzennej bazy danych nie ma takich samych problemów z podziałem danych na kafelki, więc często jest to metoda preferencyjna - pod warunkiem, że aplikacja końcowego zastosowania obsługuje korzystanie z tego typu danych.

Wybrałbym SpatiaLite która jest w bazie jeden plik , gdzie można włożyć wszystkie swoje Shapefiles, rastry i tabele. Następnie jako relacyjna baza danych SQL masz do dyspozycji moc zapytań SQL do wykonywania wszystkich niezbędnych działań (łączenia, wybierania, scalania, łączenia, dzielenia itp.) Między atrybutami i plikami.

SpatiaLite jest również dostępny z języków programowania, takich jak Python, dla większego stopnia automatyzacji. Niebo jest granicą.

Dokumentacja i samouczki SpatiaLite

Uważam, że przydatne jest tworzenie dokumentów programu Word zatytułowanych „Nazwa lub motyw mapy - komentarze do metadanych.doc”. Dokumentuj główne zmiany i przepływy pracy w porządku chronologicznym (RRRR-MM-DD) dla każdej mapy i / lub zestawu danych. Jeśli chcesz poznać historię zbioru danych: i) Dołącz datę modyfikacji / datę utworzenia powiązanych plików, które są przydatne jako odniesienia historyczne lub potencjalne pliki źródłowe. Dołącz krótkie podsumowanie zawartości każdego pliku (nazwy warstw, liczba rekordów), zwracając uwagę na ogólne podobieństwa lub różnice (tj. Co nowego w każdej wersji mapy lub zestawu danych). Przechowuj plik „- Komentarze do metadanych” w tym samym folderze roboczym, co najnowsza wersja mapy lub zestawu danych. Umieść starsze wersje mapy lub danych w podfolderze Archiwum. Trzyetapowy proces działa dobrze w przypadku tworzenia oprogramowania, tworzenie baz danych i zarządzanie plikami: 1) Opracowywanie (i dokumentowanie); 2) Test (i dokument); 3) Publikuj (w tym metadane). 1) folder roboczy; 2) Podfolder archiwum; 3) Wersja opublikowana.