Обойти ограничение в 10 символов для имени поля в шейп-файлах?

Я экспортирую геометрию с прикрепленными текстовыми атрибутами из базы данных Oracle в формат шейп-файла esri (.shp) с библиотекой Java и Geotools.

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

Я могу обойти это, создав некоторый простой текстовый файл с «shrtname» = «Полное и длинное имя», но, очевидно, он не будет понят и импортирован любым другим программным обеспечением, кроме нашего.

Существует ли официальный способ сопоставления коротких имен полей и длинных полнотекстовых имен?

Например, XML-файл рядом со всеми другими .shp .dbf .shx файлами.

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

Несколько советов об обходных путях из личного опыта.

Когда люди выбирают шейп-файлы (и настаивают на них) в качестве основного формата, он обычно выбирается для взаимодействия - думайте об этом как о соответствии спецификации. Если вы решите свернуть свой собственный картограф, вы в основном делаете противоположное - поскольку вы делаете вещи вне спецификации - вы создали свою «расширенную спецификацию».

Я сделал это в прошлом? Да. И это, безусловно, всегда превращается в боль, а не в решение проблемы, потому что каждый раз, когда вы пытаетесь открыть шейп-файлы во что-то еще, что может читать / записывать шейп-файлы, вы получаете таблицу с целой кучей трудных для понимания полей. ,

В этот момент я бы спросил вас, почему вы используете шейп-файлы? Либо придумайте решение для рабочего процесса, которое соответствует спецификации шейп-файла и его ограничениям, либо измените форматы файлов. Все остальное - просто рецепт от головной боли.

Есть стандартный способ справиться с этим, хотя ваши клиенты могут быть не совсем довольны этим: вы экспортируете два файла, шейп-файл и файл данных в формате, который их программное обеспечение может прочитать. Шейп-файл имеет только уникальный идентификатор [Id] для атрибутов. Файл данных имеет несколько атрибутов: [Id] для соответствия форме, [Field] для предоставления имени поля, [Type] для указания его типа и один атрибут каждого возможного типа данных для хранения значения. Каждое поле в исходном файле хранится в виде записи в этом файле данных.

Например, исходная таблица выглядит следующим образом:

[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

Должно быть очевидно, как использовать эти данные в любой СУБД и как конвертировать туда и обратно между двумя форматами.

Если ваш клиент использует ArcGIS, вы можете предоставить скрипт для массового назначения псевдонимов полей . Это дало бы им вид длинных имен полей при использовании данных.

Подобные сценарии могут также работать с псевдонимами в других пакетах ГИС.

Самый простой путь - это сохранить ТОЛЬКО вашу геометрию в виде шейп-файла, поскольку для отличных возможностей редактирования геометрии, которые существуют во многих ГИС-приложениях, YET сохраняет все ваши полевые данные (или большую их часть) в sqlite в виде таблиц. Присоединяйтесь к ним по мере необходимости, чтобы исследовать ваши полевые данные.

НО, если вам нужно редактировать таблицы при выполнении пространственных запросов или при выборе объектов шейп-файлов в QGIS, вам нужно будет забыть [шейп-файлы, соединенные с таблицами sqlite] в качестве опции, и вместо этого экспортировать все в Spatialite. Научитесь использовать Qspatialite и Spatialite_GUI (они оба дополняют друг друга многими функциями, которых нет у других - вам понадобится и то и другое, если вы много делаете с SQLITE)

Важно помнить, что эти таблицы (присоединенные к шейп-файлу) не будут редактироваться одновременно с объединением. Поэтому переход на Spatialite станет отличной альтернативой шейп-файлам. Он поддерживает простоту и переносимость шейп-файлов, предлагая при этом большинство достоинств базы данных SQL, не усложняя PostgreSQL.

Временное исправление может быть сохранено в виде файла TAB, который может содержать имена столбцов длиной до 31 символа.