В последнее время я трачу много времени на преобразование совершенно хороших названий полей, таких как «Процент граждан в возрасте 25 лет и старше со степенью бакалавра или выше», в такие вещи, как «edbchogtr», чтобы соответствовать пределу имени для 10-символьного поля DBF.
В другом потоке ( «Странности» в технической спецификации Shapefile ), geospatialpython отметил , что «несмотря на формате шейп - файла в недостатки, странности и ограничения она сохраняется упорно и вокруг области ГИС. Любая другая попытка заменить его было слишком раздутой для простое векторное хранилище или слишком проприетарное. "
Эта деятельность в сочетании с комментарием мистера Лоухеда заставляет меня задуматься:
- Были ли когда-либо предприняты какие-либо явные попытки заменить шейп-файл в качестве повсеместного формата хранения и обмена данными ГИС?
- Есть ли претенденты?
- Если были конкурирующие форматы, почему они потерпели неудачу?
- Эсри отказалась поддержать их, или это просто история технологической инерции?
- Если не было попыток ... почему бы и нет?
Кажется, что мы могли бы сделать немного лучше для себя, как для разработчиков ГИС, так и для пользователей.
Ответы:
Это тема, которая всегда возникает. Возможно, у меня нет правильного ответа, но я могу высказать свое личное мнение .
Причину того, что они поддерживаются, можно объяснить несколькими характеристиками о них, поэтому позвольте мне упомянуть несколько.
Во-первых, есть спецификация . Я имею в виду, мне за тридцать, и эта штука существовала с подросткового возраста. Так что можно с уверенностью сказать, что эта спецификация существует уже некоторое время. Конечно, есть несколько других форматов, которые также публикуются, но разница в этом заключается в том, что ...
Это относительно просто! Он построен поверх формата 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 является жизнеспособным форматом.
источник
Сама часть SHP + SHX не так уж и плоха. Настоящая проблема заключается в части DBF. Это можно сделать с новым форматом, который поддерживает юникод и все виды современных типов полей. Проблема заключается в том, что он хорошо поддерживается всеми программами.
источник
GeoPackage является многообещающим преемником. Он похож на Spatialite, но от OGC, и был принят многими программами, включая ArcGIS и OGR.
Смотрите официальную домашнюю страницу http://www.geopackage.org/ и, например, эту презентацию: http://www.slideshare.net/JeffYutzler/geopackage-swg-overview
источник
По крайней мере у пространственного объекта есть намерение, см., Например, эту презентацию http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf
С другой стороны, я считаю, что главная причина его неудачи в том, что 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
источник
Esri уже несколько лет продвигает файловые базы геоданных в качестве замены шейп-файлов.
Совсем недавно они предоставили API, который скрывает любые странности.
источник
Диалект XML, такой как GML, определенно не оптимизирован для работы с огромными наборами данных, но может использоваться в качестве формата обмена между программным обеспечением или между платформами.
Я не верю, что есть какие-либо проблемы с лицензированием (см. Сообщение Ragi Yaser Burhum о вирусных характеристиках Spatialite), и при необходимости довольно легко адаптировать существующие парсеры.
источник
Просто чтобы взглянуть на это с другой точки зрения, я не уверен, что использование «Процент граждан в возрасте 25 лет и старше со степенью бакалавра или выше» - это очень хорошее название области. Хотя смешивание пробелов и апострофов может быть обработано, если вы пишете код или запросы, более вероятно, что появятся ошибки.
По моему мнению, будущее распространения пространственных данных должно быть сосредоточено на веб-сервисах и веб-сервисах, а спецификация WFS (которая использует GML) открыта и установлена. GeoJSON меньше, и с ним легче работать в JavaScript. Однако со сжатием размеры сопоставимы.
Я также хотел бы проголосовать за Личные базы геоданных ESRI . Это может быть часто искаженный формат Microsoft, но он поддерживает ODBC, запросы SQL, представления и позволяет сторонним разработчикам создавать простые формы ввода данных и включать по крайней мере некоторый уровень проверок целостности данных (типы данных, длины, уникальные значения) ,
источник