Есть ли попытки заменить шейп-файл? [закрыто]

67

В последнее время я трачу много времени на преобразование совершенно хороших названий полей, таких как «Процент граждан в возрасте 25 лет и старше со степенью бакалавра или выше», в такие вещи, как «edbchogtr», чтобы соответствовать пределу имени для 10-символьного поля DBF.

В другом потоке ( «Странности» в технической спецификации Shapefile ), geospatialpython отметил , что «несмотря на формате шейп - файла в недостатки, странности и ограничения она сохраняется упорно и вокруг области ГИС. Любая другая попытка заменить его было слишком раздутой для простое векторное хранилище или слишком проприетарное. "

Эта деятельность в сочетании с комментарием мистера Лоухеда заставляет меня задуматься:

  • Были ли когда-либо предприняты какие-либо явные попытки заменить шейп-файл в качестве повсеместного формата хранения и обмена данными ГИС?
  • Есть ли претенденты?
  • Если были конкурирующие форматы, почему они потерпели неудачу?
  • Эсри отказалась поддержать их, или это просто история технологической инерции?
  • Если не было попыток ... почему бы и нет?

Кажется, что мы могли бы сделать немного лучше для себя, как для разработчиков ГИС, так и для пользователей.

canisrufus
источник
2
@Mapperz Кроме недавно выпущенного API базы геоданных, я не вижу никаких инструментов для написания бесплатной базы геоданных. Я не думаю, что это может считаться заменой, за исключением части мира ESRI.
canisrufus
2
Вы можете писать и читать базы геоданных (через API), используя GDAL gdal.org/ogr/drv_filegdb.html, используя resources.arcgis.com/content/geodatabases/10.0/file-gdb-api
Mapperz
1
Хотелось бы видеть Python API для чтения / записи файловой базы геоданных (по крайней мере, простых объектов) без лицензии ArcGIS - это будет Open.
PolyGeo
2
@PolyGeo вы и все остальные :)
Ragi Yaser Burhum
3
@celenius From gdal.org/ogr/drv_shapefile.html "Геометрия: формат Shapefile явно использует 32- битные смещения и поэтому не может превышать 8 ГБ (фактически он использует 32-битные смещения для 16-битных слов). Следовательно, не рекомендуется использовать файл размер более 4 ГБ. Атрибуты: в формате dbf нет смещений, поэтому он может быть произвольно большим. " Таким образом, у вас могут быть довольно большие dbfs, но вы должны быть осторожны, если ваш shp превышает 4 ГБ. Тогда вы играете с огнем.
Раги Язер Бурхум

Ответы:

50

Это тема, которая всегда возникает. Возможно, у меня нет правильного ответа, но я могу высказать свое личное мнение .

Причину того, что они поддерживаются, можно объяснить несколькими характеристиками о них, поэтому позвольте мне упомянуть несколько.

  • Во-первых, есть спецификация . Я имею в виду, мне за тридцать, и эта штука существовала с подросткового возраста. Так что можно с уверенностью сказать, что эта спецификация существует уже некоторое время. Конечно, есть несколько других форматов, которые также публикуются, но разница в этом заключается в том, что ...

  • Это относительно просто! Он построен поверх формата DBF , который в то время уже существовал и широко поддерживался в нескольких платформах / ОС. Уже были парсеры, которые могли читать половину этого формата (часть DBF), так что это облегчало поддержку дополнительного добавления. У вас есть геометрия? Конечно, просто сериализовать и написать. Вы сделали. Сравните это с покрытием ! Попытайтесь объяснить кому-то простым языком, что делает чистая топология . Нетривиально написать топологически чистое покрытие.

  • Самое главное, я думаю, что причина № 1 в популярности шейп-файлов заключается в том, что они поддерживаются как в Open Source, так и в проприетарных системах . Какая ГИС, как вы знаете, не поддерживает шейп-файлы?!? Неслыханно.

В качестве замены, мы слышим Файловые базы геоданных и SpatiaLite . Оба формата значительно превосходят по функциональности, гибкости, скорости и т. Д. По сравнению с шейп-файлами. По-своему, у них есть определенные вещи, которые делают их лучше друг друга в разных областях, но сравнение пространственного объекта и FileGDB, безусловно, выходит за рамки этого вопроса.

Думаю ли я, что любой из этих форматов заменит шейп-файлы? Не в их нынешних воплощениях .

Почему?

Не из-за технологического аргумента (в конце концов, я сказал, что они в этом аспекте превосходят себя), а из-за чего-то другого: лицензирования.

Так в чем их проблемы?

Файл GDB :

FileGDB обеспечивает взаимодействие посредством нового API FileGDB. Тем не менее, этот API предоставляется в двоичном форматепо ESRI. Это не спецификация. Проработав в прошлом в команде GeoDatabase, я могу вам сказать, что вопреки всем теоретикам заговора, носящим оловянную фольгу, это вовсе не зло. Это потому, что внутренняя часть базы геоданных меняется при каждом выпуске. Публикация полной спецификации повлекла бы за собой предоставление в основном всех деталей того, как все должно поддерживаться, а затем тщательное документирование изменений в формате с каждым ежегодным выпуском. Это не имеет смысла. Таким образом, API FileGDB, хотя и не является спецификацией, он абстрагирует все эти небольшие изменения. И теперь его можно использовать кроссплатформенный! Имейте в виду, это огромный шаг вперед! Учитывая консервативный характер ESRI, это определенно реакция в правильном направлении.

И все же, поддержка только двоичного кода не делает никого в мире открытого исходного кода слишком счастливым. Как вы можете воспользоваться портированием некоторого кода, чтобы сказать какой-то другой разновидности Linux, если ESRI его не поддерживает. Ты не можешь Это то, что делает Open Source мощным, и теперь вы не можете этим воспользоваться. Если ESRI решит прекратить поддержку Debian, то все. Вы сделали. И вы ничего не можете сделать, чтобы изменить это.

Пространственный :

Spatialite потрясающий, потому что он получает все бесплатные функции от SQLite . SQLite используется везде. Это на вашем телефоне Android, на вашем iPhone / iPad, в Firefox, в Google Chrome, на нескольких коммерческих встроенных устройствах - может продолжаться вечно. Чтобы по-настоящему превратить его в Geoformat (а не просто выполнять операции с пустыми ограничивающими рамками), ему необходимо использовать ту же библиотеку геометрии, которую использует PostGIS: GEOS . К сожалению, GEOS основан на другой, еще более удивительной геометрической библиотеке, известной как JTS . Все алгоритмы в JTS чрезвычайно мощные, так в чем же проблема?

Ну, JTS лицензируется как LGPL с открытым исходным кодом , а LGPL - вирусная лицензия . JTS - это LGPL, означает, что GEOS - это LGPL, означает, что пространственно связанный статически с GEOS - это LGPL. Это отстой. Почему? Не объясняя слишком много лицензий с открытым исходным кодом , я могу вам сказать, что, например, я не могу использовать пространственный объект, скажем, в приложении для iPhone, потому что это сделало бы все мое приложение автоматически открытым исходным кодом (iOS допускает только статические ссылки). Любой тип лицензии GPL (разумно) пугает дерьмо из ESRI, и поэтому они не будут касаться его 10-футовым шестом. Следовательно, ArcGIS, самая популярная ГИС-система в мире, не поддерживает (и, вероятно, никогда) не поддерживает пространственные объекты изначально. Это автоматически убивает его как жизнеспособный формат.

И поэтому мы возвращаемся к дрянным шейп-файлам, которые поддерживаются повсюду.

Обновление :

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

Раги Язер Бурхум
источник
Проблема с SQLite / Spatialite заключается в том, что это не формат, а механизм реляционной базы данных с пространственной библиотекой поверх него. Хотя он делает то, что делает очень хорошо, он заставляет данные храниться реляционным образом, что не всегда является наиболее подходящим способом. Кроме того, сложность формата файлов SQLite ( sqlite.org/fileformat2.html ) затрудняет доступ к данным без механизма SQLite и поэтому не подходит для использования в качестве открытого и легко доступного формата файлов для обмена данными. Это не было действительно предназначено для этого.
Игорь Брейц
8
На самом деле, LGPL не является вирусной лицензией - она ​​была специально разработана, чтобы этого избежать. Кроме того, Spatialite лицензируется по трехсторонней лицензии MPL ( исходная ), что означает, среди прочего, вы можете выбрать Общественную лицензию Mozilla в качестве наиболее подходящей лицензии и действовать на ее условиях (с очень слабым авторским левом). По крайней мере, я читаю, что у ESRI нет никаких причин не поддерживать Spatialite из-за лицензии - будет ли она (если она будет конкурировать почти в том же пространстве, что и FileGDB) - это другая история ...
om_henners
3
@Ragi, вы микшируете, используя библиотеку и портируя ее. Конечно, портирование должно быть LGPL, так как это по сути производная работа. Но если вы связываете его динамически, это не считается производной работой, это «работа, использующая библиотеку», и вы получаете право сохранить свою лицензию ( en.wikipedia.org/wiki/GNU_Lesser_General_Public_License ). Так что высказывание «LGPL - вирусный» без дополнительных объяснений не является точным.
Игорь Брейц
2
Но опять же, это спорный вопрос, так как Spatialite лицензируется по схеме с древовидной лицензией ( groups.google.com/forum/?fromgroups#!topic/spatialite-users/… ), поэтому вы можете выбрать лицензию, которая подходит Вы больше всего - MPL позволяет статическое связывание.
Игорь Брейц
2
@ bugmenot123 Хорошо, затем исправьте это, если хотите, но не обвиняйте меня в распространении FUD об ОС, потому что это оскорбительно. Я писал код ОС более десяти лет (не удивлюсь, что вы использовали некоторые из них на самом деле), и это не было злобной напыщенной речью. Это было правдой - и так до сих пор. Динамическое связывание в iOS LGPL (ну, если быть точным, фреймворки , были разрешены в iOS 8). Это никогда не было технической проблемой, но юридической. Распространение в Appstore требует подписи кода - и, к сожалению, для всех любителей ОС, таких как я, - LGPL является нечеткой лицензией для этого. Нет прецедента в суде.
Раги Язер Бурхум
18

Сама часть SHP + SHX не так уж и плоха. Настоящая проблема заключается в части DBF. Это можно сделать с новым форматом, который поддерживает юникод и все виды современных типов полей. Проблема заключается в том, что он хорошо поддерживается всеми программами.

Уффе Кусгаард
источник
6
+1 Улучшение в части DBF тоже не сложно: на самом деле все сводится к тому, чтобы убедить разработчиков программного обеспечения договориться о чем-то.
whuber
1
Была ли попытка?
canisrufus
5
Я часто тосковал по поправке к Shapefile, которая просто заменяла файл DBF в UTF-8. Было бы просто поддерживать и требовать минимальных изменений в существующих пакетах программного обеспечения.
Scw
1
@canis Fox Software сделала небольшую (частную) попытку в конце 80-х. После того, как MS купил их (ок. 1990), это было так. Сообщество создало стандарт DBF 3, и это в значительной степени заморозило всю разработку. MS выпустила Access; FoxPro вымерла; мир двигался дальше.
whuber
1
Напротив, @Uffe, к CSV-файлам можно получить произвольный доступ: вам нужен только индекс, как это делают файлы DBF для эффективного поиска. Самая большая проблема, которую я вижу, заключается в том, что, казалось бы, незначительные изменения, которые происходят естественным образом в файлах CSV, такие как строки в кавычках или преобразования CR / LF, испортят все байтовые смещения. Структура записи фиксированной длины файла DBF, хотя и менее эффективна в хранении, не имеет этой проблемы.
whuber
7

По крайней мере у пространственного объекта есть намерение, см., Например, эту презентацию http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf

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

Другие тоже разделяют это мнение:

Это не потому, что проект SpatiaLite не дал нам инструментов для реализации, это было то, что сообщество могло меньше заботиться об этом. SHP работает на них, и нет никаких причин для изменения.

http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/

Больше мыслей о файловой базе геоданных Esri, пространственном и автодесковом sdf здесь: http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto

johanvdw
источник
Как бы я ни думал, spatiaLite составляет ~ 3 мегабайта служебных данных в функциях, системах отсчета и т. Д., Которые мешают ему быть хорошим универсальным форматом обмена.
Scro
На самом деле, лицензия на пространственный объект не идеальна - она ​​не имеет ничего общего с инструментами.
Раги Язер Бурхум
@ Scro, 3 мегабайта слишком много? Это, конечно, не слишком большой для рабочего стола. Вы должны рассматривать мобильные устройства. Кроме того, есть ли другой Spatial API с эквивалентной функциональностью меньшего размера, чем Spatialite?
Klewis
@klewis - он не слишком большой сам по себе, просто очень неэффективный, если учесть, что существует множество небольших (например, <200 КБ) наборов данных. Это большая нагрузка, особенно в свете того факта, что после получения вы, как правило, оставляете каждый набор данных в его файле 3 Мб или сверните его в существующую базу данных. Просто чтобы прояснить, я <3 spatiaLite - но мы говорим о передаче данных, где какой-то плоский файл / xml / wkb будет гораздо более эффективным.
Scro
6

Esri уже несколько лет продвигает файловые базы геоданных в качестве замены шейп-файлов.

Совсем недавно они предоставили API, который скрывает любые странности.

Кирк Куйкендалл
источник
Я не много работал с базами геоданных. Википедия говорит, что они являются «закрытым» стандартом, например, спецификация базы геоданных не была опубликована. Кажется, трудно получить широкое распространение без публикации внутренних документов этого формата Хотя я слишком молод, чтобы знать историю, я думаю, что шейп-файлы отчасти популярны из-за публичной части спецификации. API кажется хорошим шагом.
canisrufus
1
@ может ты прав. В то время никто не принимал шейп-файлы, за исключением того, что ESRI специально продвигал их как открытый формат обмена данными ГИС. Даже с ограниченными доступными в то время программными инструментами, с выпуском ESRI четкой спецификации .shp / .shx (и обязательством придерживаться ее), работа над написанием кода для чтения и чтения стала делом нескольких часов. написать шейп-файлы: не требуется обратная инженерия
whuber
Пока API является двоичным двоичным объектом черного ящика, FGDB не будет восприниматься так же, как SHP. Даже если Esri убеждает всех своих клиентов перейти на FGDB с SHP, API не совсем совместим с открытым исходным кодом.
dericke
3

Диалект XML, такой как GML, определенно не оптимизирован для работы с огромными наборами данных, но может использоваться в качестве формата обмена между программным обеспечением или между платформами.

Я не верю, что есть какие-либо проблемы с лицензированием (см. Сообщение Ragi Yaser Burhum о вирусных характеристиках Spatialite), и при необходимости довольно легко адаптировать существующие парсеры.

Стефан Генриод
источник
1
Я думаю, что это не было упомянуто только по той причине, что вы рассказываете, что оно не оптимизировано для больших наборов данных. XML раздутый. Упомянутые здесь форматы являются двоичными, где GML хранит точки в виде строк. Размер может быть на порядок разным.
canisrufus
3
Канисруфус прав. Есть несколько проблем с GML. Навигация в Infoset возможна с использованием XPath, но любой, кто пытался реализовать пространственную индексацию поверх XML, скажет вам, насколько это иррационально и насколько плохо оно отображается в традиционных реляционных базах данных. Не вдаваясь во многие детали, если что-то базовое, такое как индексирование и запросы, становится нетривиальным, формат раздутый, и в основном требуется, чтобы у вас был весь набор данных в памяти, чтобы что-то с ним делать, тогда это не очень хороший вариант.
Раги Язер Бурхум
4
XML раздувается, когда хранится в виде простого текста. Существуют свободно (как бесплатно, так и бесплатно для модификации и перераспределения) двоичные библиотеки xml, которые могут служить заменой читателей xml, предоставляя людям возможность использовать как удобочитаемость xml, так и производительность и эффективность хранения двоичных файлов. , Единственная причина, по которой я могу придумать, потому что она никогда не рассматривается широко, заключается в том, что johandvw замечает выше : никого не волнует, .shp был "достаточно хорош", как есть.
Мэтт Уилки
1

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

По моему мнению, будущее распространения пространственных данных должно быть сосредоточено на веб-сервисах и веб-сервисах, а спецификация WFS (которая использует GML) открыта и установлена. GeoJSON меньше, и с ним легче работать в JavaScript. Однако со сжатием размеры сопоставимы.

Я также хотел бы проголосовать за Личные базы геоданных ESRI . Это может быть часто искаженный формат Microsoft, но он поддерживает ODBC, запросы SQL, представления и позволяет сторонним разработчикам создавать простые формы ввода данных и включать по крайней мере некоторый уровень проверок целостности данных (типы данных, длины, уникальные значения) ,

geographika
источник
Это верный момент. Что хорошо в них, так это то, что, зная английский язык, можно понять, что означают эти поля.
canisrufus
Это действительно роль метаданных наборов данных. Шейп-файл может использовать файл XML с тем же именем, чтобы сохранить это.
география