Ominięcie limitu 10 znaków nazwy pola w plikach kształtów?

Eksportuję geometrię z dołączonymi atrybutami tekstu z bazy danych Oracle do formatu esri shapefile (.shp) z biblioteką Java i Geotools.

Kolumny atrybutów w naszej bazie danych mają nazwy zawierające więcej niż 10 znaków, a Geotools zmusza je do obcięcia. Rozumiem, że wynika to ze specyfikacji plików .shp lub .dbf.

Mogę to obejść, tworząc prosty plik txt z „shrtname” = „Pełna i długa nazwa”, ale oczywiście nie będzie zrozumiany i importowany przez żadne inne oprogramowanie niż nasze.

Czy istnieje oficjalny sposób mapowania od krótkich nazw pól do długich nazw pełnotekstowych?

Na przykład plik xml obok wszystkich innych plików .shp .dbf .shx.

Przepraszamy, odpowiedź brzmi nie. Musisz uruchomić własny program mapujący pola i zrozumie go tylko oprogramowanie korzystające z programu mapującego. Możesz jednak użyć innych formatów, które nie mają tego ograniczenia (np. Geobaza plików, spatialite itp.).

Kilka rad na temat obejść z własnego doświadczenia.

Kiedy ludzie wybierają pliki kształtu (i nalegają na nie) jako główny format, zwykle wybierany jest ze względu na interoperacyjność - pomyśl o tym jako o zgodności ze specyfikacją. Jeśli zdecydujesz się rzucić własny maper pola, zasadniczo robisz coś wręcz przeciwnego - ponieważ robisz rzeczy poza specyfikacją - stworzyłeś swoją „rozszerzoną specyfikację”.

Czy zrobiłem to w przeszłości? Tak. I z całą pewnością zawsze staje się bardziej bolesne niż faktyczne rozwiązanie problemu, ponieważ za każdym razem, gdy próbujesz otworzyć pliki kształtów na cokolwiek innego, co potrafi czytać / zapisywać pliki kształtów, pojawia się stół z całą masą trudnych do zrozumienia pól .

W tym momencie zapytam cię, dlaczego używasz plików kształtu? Albo wymyśl rozwiązanie przepływu pracy zgodne ze specyfikacją pliku kształtu i jego ograniczeniami, albo zmień formaty plików. Cała reszta to tylko przepis na bóle głowy.

Istnieje standardowy sposób, aby sobie z tym poradzić, chociaż Twoi klienci mogą nie być z tego całkowicie zadowoleni: eksportujesz dwa pliki, plik kształtu i plik danych w formacie, który może odczytać ich oprogramowanie. Plik shapefile ma tylko unikalny identyfikator [Id] dla atrybutów. Plik danych ma kilka atrybutów: [Id], aby dopasować kształt, [Pole], aby podać nazwę pola, [Typ], aby wskazać jego typ, oraz jeden atrybut każdego możliwego typu danych, aby zapisać wartość. Każde pole w oryginalnym pliku jest przechowywane jako rekord w tym pliku danych.

Na przykład tabela źródłowa wygląda następująco:

[Shape] [Id] [Name]     [Population2010]
shape1  A1   California         37253956
shape2  A2   Texas              25145561
shape3  A3   Wyoming              563626

miałby odpowiedni plik danych

[Id] [Field]        [Type]  [Text]     [Integer]
A1   Name           Text    California    <Null>
A1   Population2010 Integer <Null>      37253956
A2   Name           Text    Texas         <Null>
A2   Population2010 Integer <Null>      25145561
A3   Name           Text    Wyoming       <Null>
A3   Population2010 Integer <Null>        563262

Powinno być oczywiste, jak korzystać z tych danych w dowolnym RDBMS i jak konwertować tam iz powrotem między tymi dwoma formatami.

Jeśli Twój klient korzysta z ArcGIS, możesz podać skrypt do masowego przypisywania aliasów pól . Dałoby im to wygląd długich nazw pól podczas korzystania z danych.

Podobne skrypty mogą działać również w celu zapewnienia aliasów w innych pakietach GIS.

Najłatwiejszą drogą jest przechowywanie TYLKO swojej geometrii jako pliku kształtu, aby uzyskać doskonałe możliwości edycji geometrii, które istnieją w wielu aplikacjach GIS, JESZCZE przechowuj wszystkie dane pola (lub większość z nich) w sqlite jako tabele. Dołącz do nich w razie potrzeby, aby zbadać swoje dane terenowe.

ALE jeśli musisz edytować tabele podczas wykonywania zapytań przestrzennych lub wybierania funkcji plików kształtów w QGIS, musisz zapomnieć [pliki kształtów dołączone do tabel sqlite] jako opcję i zamiast tego wyeksportować wszystko do Spatialite. Naucz się korzystać z Qspatialite i Spatialite_GUI (oba są komplementarne względem siebie z wieloma funkcjami, których innym brakom - będziesz potrzebować i używać obu, jeśli robisz wiele rzeczy z SQLITE)

Ważne jest, aby pamiętać, że te tabele (połączone z plikiem kształtu) nie będą edytowalne w tym samym czasie, co sprzężenie. I tak migracja do Spatialite byłaby doskonałą alternatywą dla plików kształtów. Utrzymuje prostotę i przenośność plików kształtów, oferując większość zalet bazy danych SQL, bez złożoności PostgreSQL.

Tymczasowa poprawka może być zapisana jako plik TAB, który może mieć nazwy kolumn o długości do 31 znaków.