Альтернативы шейп-файлам как кроссплатформенные типы данных с открытым исходным кодом [закрыто]

20

Я работаю над программным обеспечением, очень ориентированным на ESRI, но в будущей версии, скорее всего, не будет использоваться программное обеспечение ESRI. Он использует шейп-файлы и базы геоданных. Я планирую передать все свои данные в Shapefiles в ожидании будущих версий программного обеспечения, которые, вероятно, будут на Android и других мобильных устройствах. Похоже, что шейп-файлы являются наиболее распространенным типом данных для функций в мире ГИС с открытым исходным кодом, но каковы другие и какие преимущества они приносят? Я знаком с GeoJSON и KML, но я уверен, что есть и другие.

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

дубильщик
источник
1
Этот вопрос с 2011 года был задан до того, как появился GeoPackage, и ответы, естественно, не включают эту альтернативу.
user30184
2
Esri File Geodatabase имеет максимальную длину поля char, которая может конкурировать с текстовым содержимым большинства небольших библиотек, Esri Personal Geodatabase также поддерживает очень длинные текстовые поля. Доступ к обоим возможен через QGIS и, конечно, Esri ArcGIS, но поддержка этих типов данных ограничена за пределами этих пакетов. Остерегайтесь версии, хотя я бы попытался создать 9.3-совместимую версию, так как большинство программного обеспечения Esri, с которым вы, вероятно, столкнетесь, будет более 10, и API базы геоданных для QGIS должны поддерживать эту версию. GeoJSON и KML также могут поддерживать большие текстовые поля, но они не так универсально читаемы.
Майкл Стимсон
1
Хм, 9.3 не является хорошим планом для совместимости файловой базы геоданных - FGDB API не поддерживает .xd в стиле 9.x.
Винс
1
Шейп-файлы @ElioDiaz по-прежнему существуют, несмотря на их ограничения, поскольку они являются наиболее универсальным средством передачи функций - почти каждый пакет ГИС открывается или может импортировать шейп-файл Esri. Формат является открытым стандартом, поэтому каждый может читать и внедрять его по-своему. Существуют, несомненно, превосходные форматы функциональных возможностей ГИС, но они не так широко применяются ... эта тема много раз обсуждалась на GIS.SE. Как бы нам этого ни хотелось, в противном случае шейп-файлы, вероятно, будут наименьшим общим знаменателем для функций в течение некоторого времени, поэтому нам просто нужно улыбаться и нести это.
Майкл Стимсон

Ответы:

18

Как говорит @ user890, это очень сильно зависит от того, как будут использоваться данные. В основном есть два способа доступа к данным:

  1. Загрузка всего этого в память за один раз, а затем доступ / запрос данных в памяти.
  2. Запрашивая конкретные функции, ограничивающие рамки и т. Д.

Форматы, такие как GeoJSON и KML, лучше всего подходят для случаев, когда вы хотите загрузить все за один раз. Преимущества состоят в том, что данные могут быть структурированы таким образом, чтобы это больше подходило для вашего приложения. Недостатки: большие размеры файлов (поскольку они основаны на тексте) и невозможность делать эффективные запросы непосредственно из файла.

SQLite / Spatialite лучше подходит для запросов (SQL), но сложнее структурировать данные - вам нужно сгладить все в таблицы базы данных, а затем выполнять соединения (что может быть дорого) при запросах.

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

Игорь Брейц
источник
14

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

Для мобильных приложений я бы подумал, что sqlite / пространственный формат будет логическим форматом для начала. Я знаю, что Android обеспечивает встроенную поддержку sqlite. Таким образом, при условии, что вы можете загрузить пространственные расширения, у вас будет очень мощный доступ к ГИС.

В зависимости от того, насколько вы авантюрны, может показаться, что создание gdal для Android не является невозможным. Тогда вы могли бы иметь гораздо больше форматов в вашем распоряжении. Я уверен, что многие пользователи на этом сайте были бы заинтересованы, если бы вы пошли по этому пути.

user890
источник
13

Новый формат, который появился недавно, - это Geopackage . Эта спецификация построена поверх базы данных SQLite, поэтому она имеет ту же основу для одного файла, но с дополнительным преимуществом в качестве стандарта OGC .
Что касается размера файла, вполне вероятно , что формат хранения является более компактным , чем .shpи .dbfформатом для пространственных и атрибутивных данных , используемых в шейпе. Следовательно, GeoPackage, вероятно, будет того же размера или меньше, чем совокупность тех же объектов в шейп-файле.
На этой фотографии показана канализационная сеть в Сан-Диего, сохраненная как Shapefile и GeoPackage. Как видите, они по сути одинакового размера. Shapefile vs Размер Geopackage
Поскольку этот формат основан на SQLite, он должен быть готов для мобильных устройств. Многие приложения уже используют этот формат базы данных для хранения, поэтому это проверенная технология. Может использоваться кроссплатформенно без перевода.

Получить Пространственный
источник
4

Согласитесь с Lennert, выберите правильный формат для работы.

Однако я обнаружил, что Spatialite - довольно универсальный формат. У вас есть один файл, который дает вам гибкость в хранении и совместном использовании данных, таких как шейп-файл, но вы сводите на нет проблемы, которые вы упоминаете, с ограничением символов; предоставляя вам возможность использовать преимущества пространственной базы данных.

К сожалению, он не полностью поддерживается в ArcGIS (я не пробовал немного, поэтому могу ошибаться), но отлично работает в QGIS.

Лиам Г
источник
4

Существует множество различных форматов, и лучшее из них зависит от вашего набора данных, используемых вами инструментов и того, что вы хотите с ним сделать.

Некоторые из них я использую:

  • Файловая база геоданных и пространственные базы данных: ловушка, которую я люблю использовать. Он может содержать все виды данных и иметь отношения, индексацию ... Я использую GDB при работе в среде Esri, пространственный для всего остального.

  • GeoJson: Легко читаемый формат, который я обычно использую для небольших наборов данных, которые не требуют много для индексации

  • Правильные базы данных: я склонен использовать это для массивных наборов данных и сложных алгоритмов.

Но есть и множество других.

Леннер Де Фейтер
источник
3

Я бы порекомендовал использовать базу данных SQLite / spatiallite. Это один файл, такой как база геоданных (от одной до нескольких таблиц / слоев внутри), и он может использоваться в ArcGIS Desktop и QGIS.

artwork21
источник
Я сохранил данные полигонов в sqlite, загрузил их в QGIS и получил сообщение «CRS не определен: по умолчанию CRS EPSG: 4326 - WGS84». Не теряется ли информация о проекции?
Ичиро
С каким программным обеспечением вы сохранили слой многоугольника в sqlite?
artwork21
1

Варианты действительно зависят от того, какой язык вы будете использовать и как будут использоваться данные. Android, скорее всего, будет Java. Каждый вариант будет своего рода сравнением затрат и выгод, основанным на этом решении. Все форматы данных оптимизированы для определенных случаев использования.

Следующий вопрос - как будут использоваться данные. Будет ли мобильное приложение просто читать пространственные данные? Или это будет чтение и запись данных часто? Как часто он будет обмениваться данными с другими устройствами или серверами?

GeospatialPython.com
источник