Чи є спроби замінити файл форми? [зачинено]

Нещодавно я витрачав багато часу на перетворення ідеально хороших імен полів на кшталт "Процент громадян віком від 25 років і старших ступенів бакалавра" в такі речі, як "edbchogtr", щоб задовольнити ліміт імені поля DBF на 10 символів.

В іншому потоці ( "Дивацтва" в технічній специфікації Shapefile ) геопростірпітон прокоментував, що "Незважаючи на недоліки, дивацтва та обмеження формату файлу формату, він наполегливо зберігається в ГІС та навколо нього. Кожна інша спроба замінити його надто роздута для просте векторне зберігання або занадто фірмове ".

Ця активність у поєднанні з коментарем містера Лоугеда викликає цікавість:

• чи були колись явні спроби замінити форм-файл як універсальний формат зберігання та обміну даними GIS?
• Чи є претенденти?
• Якщо існували змагальні формати, чому вони не змогли?
• Чи Есрі відмовився їх підтримати, чи історія просто одна з технологічних інерцій?
• Якщо не було спроб ... чому б і ні?

Здається, ми могли б зробити трохи краще для себе, як розробники ГІС, так і користувачі.

Це тема, яка завжди виникає. Я не можу мати правильну відповідь, але я можу дати вам моя особиста думка .

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

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

• Це порівняно просто! Він побудований на версії DBF Format , який на той момент вже існував і широко підтримувався на кількох платформах / ОС. Вже були парсери, які могли прочитати половину цього формату (частина DBF), тому це полегшило підтримку додаткового додатку. У вас є геометрія? Впевнений, просто серіалізуй це і напиши. Ви закінчили. Контрастуйте це з покриттям ! Спробуйте пояснити комусь простими словами, що робить чиста топологія . Не тривіально писати топологічно чисте висвітлення.

• Найголовніше, я вважаю, що причина №1 досі залишається популярною в тому, що вони підтримуються як у відкритому коді, так і у власній системі . Який GIS ви знаєте, що не підтримує форм-файли?!? Нечувано.

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

Я думаю, що будь-який із цих форматів замінить Shapefiles? Не в їх нинішніх втіленнях .

Чому?

Не через технологічний аргумент (я казав, що вони в цьому аспекті вище), а через щось інше: ліцензування.

То які їх проблеми?

FileGDB :

FileGDB забезпечує взаємодію завдяки новому API FileGDB. Тим не менш, цей API надається у двійковому форматіза ESRI. Це не специфікація. Раніше працював у команді GeoDatabase, я можу вам сказати, всупереч усім теоретикам змови, що носять олово-фольгу, це зовсім не шкідливо. Це тому, що внутрішня база 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. Це могло б зробити з новим форматом, який підтримував unicode та всілякі сучасні типи полів. Проблема полягає в тому, що він добре підтримується всім програмним забезпеченням там.

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 добре підтримується багатьма програмами та має лише незначні недоліки.

Інші поділяють таку думку:

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

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

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

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

Зовсім недавно вони запропонували API, який приховує будь-які дивацтва.

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

Я не вірю, що існує якась проблема з ліцензуванням (див. Повідомлення Рагі Ясера Бурхума про вірусні характеристики Spatialite), і досить легко адаптувати існуючі парсери за потреби.

Тільки для того, щоб підійти до цього з іншого погляду, я не впевнений, що використання "Процент громадян віком від 25 років із ступенем бакалавра чи вищою" є цілком доброю назвою галузі. Під час змішування пробілів та апостроф можна обробляти, якщо ви пишете код або запити, більше шансів ввести помилки.

На мою думку, майбутнє розподілу просторових даних має зосереджуватися на веб-послугах та веб-сервісах, а специфікація WFS (яка використовує GML) відкрита та встановлена. GeoJSON менше, і з ним можна простіше працювати в JavaScript. Однак при стисненні розміри порівнянні.

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