Обхід межі 10 символів поля імен у форматі?

Я експортую геометрію із доданими текстовими атрибутами з бази даних oracle у формат esri shapefile (.shp) з бібліотекою Java та Geotools.

Стовпці атрибутів у нашій базі даних мають імена, що містять більше 10 символів, і Geotools змушує їх усікати. Я розумію, що це пов'язано із специфікацією файлів .shp або .dbf.

Я можу це вирішити, створивши простий txt-файл із "shrtname" = "Повне та довге ім'я", але, очевидно, його не зрозуміють та імпортують будь-яке інше програмне забезпечення, ніж наше.

Чи існує офіційний спосіб зробити відображення від коротких імен полів до довгих повнотекстових імен?

Наприклад, файл xml поруч із усіма іншими .shp .dbf .shx файлами.

Вибачте, відповідь - ні. Потрібно розгорнути власний польовий картограф, і це зрозуміє лише програмне забезпечення, яке використовує ваш картограф. Ви можете використовувати інші формати, які не мають цього обмеження (наприклад, база даних геоданих, просторовий і т.д.).

Деякі поради щодо вирішення проблем із особистого досвіду.

Коли люди вибирають форм-файли (і наполягають на них) як свій основний формат, його зазвичай вибирають для сумісності - подумайте про це як на дотримання специфікації. Якщо ви вирішили прокатати власний польовий картограф, ви в основному робите навпаки - оскільки ви робите речі поза специфікацією - ви створили свою "розширену специфікацію".

Чи робив я це раніше? Так. І це, безумовно, завжди викликає біль, ніж насправді вирішення проблеми, тому що кожного разу, коли ви намагаєтеся відкривати файли форм у будь-що інше, що вміє читати / писати shapefiles, ви опиняєтесь таблицею з цілою купою важких для розуміння полів .

У цей момент я запитав би вас, чому ви використовуєте shapefiles? Або придумайте рішення робочого процесу, яке дотримується специфіки shapefile та його обмежень, або змініть формати файлів. Все інше - лише рецепт головного болю.

Існує стандартний спосіб вирішити це, хоча ваші клієнти можуть бути не цілком задоволені цим: ви експортуєте два файли, файл форми та файл даних у форматі, який їх може прочитати програмне забезпечення. Файл форми має лише унікальний ідентифікатор, [Id], для атрибутів. Файл даних має декілька атрибутів: [Id], щоб відповідати формі, [Поле], щоб вказати ім’я поля, [Тип], щоб вказати його тип, та один атрибут кожного можливого типу даних для зберігання значення. Кожне поле у ​​вихідному файлі зберігається як запис у цьому файлі даних.

Наприклад, таблиця джерел виглядає так:

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

матиме відповідний файл даних

[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

Повинно бути очевидним, як використовувати ці дані в будь-яких RDBMS та як конвертувати назад і назад між двома форматами.

Якщо ваш клієнт використовує ArcGIS, ви можете надати сценарій для масового призначення псевдонімів поля . Це дало б їм вигляд довгих імен полів, коли вони використовують дані.

Подібні сценарії можуть працювати і для створення псевдонімів для інших пакетів ГІС.

Найпростіший шлях - це зберігати ТОЛЬКО свою геометрію як файл форми, для відмінних можливостей редагування геометрії, які існують у багатьох GIS-програмах, все ж зберігати всі ваші польові дані (або основну їх частину) у sqlite як таблиці. Приєднуйтесь до них за необхідності для дослідження своїх польових даних.

АЛЕ Якщо вам потрібно редагувати таблиці під час виконання просторових запитів або вибору функцій формфайлу в QGIS, вам потрібно буде забути [параметри форми, приєднані до таблиць sqlite], як опцію, і замість цього експортувати все до Spatialite. Навчіться користуватися Qspatialite та Spatialite_GUI (вони обидва безкоштовні один для одного з багатьма функціями, у яких інших недоліків - вам знадобиться і використовувати обидва, якщо ви робите багато речей із SQLITE)

Важливо пам’ятати, що ці таблиці (приєднані до shapefile) не можна редагувати одночасно із об'єднанням. І тому міграція до Spatialite була б чудовою альтернативою форм-файлам. Він підтримує простоту та портативність форм-файлів, пропонуючи більшість достоїнств бази даних SQL без складності PostgreSQL.

Тимчасове виправлення може бути збереженим, зберігаючи як файл TAB, який може мати назви стовпців довжиною до 31 символу.