Шукаєте варіанти для просторової ETL (витяг, перетворення, завантаження)?

Мене цікавлять плюси і мінуси різних просторових інструментів ETL (витяг, перетворення, завантаження). Якщо ви використовували перераховані тут елементи (або додавали свої), я шукаю вашої думки та досвіду. Зокрема, я хотів би побачити порівняння зручності використання:

• Безпечне програмне забезпечення FME (власницьке)
• Розширення інтероперабельності даних ArcGIS (власне, підмножина функцій FME)
• Простірне розширення Talend (раніше інтегратор просторових даних) (відкритий код)
• GeoKettle (відкритий код)
• ogr2ogr (я не знаю, що це справді ETL, але більше набору інструментів для перекладу файлів)
• Будь-який додатковий лот у списку

ВСЕ згадане програмне забезпечення не потрібно давати огляд. Якщо у вас є навіть один, то це буде дуже корисно при прийнятті рішення про те, в якому напрямку рухатися.

Приклад: Я хочу створити функцію перетворення схеми, яка дозволить мені вибрати вхідний шар, створити переклад та вивести нову, заздалегідь задану схему. Оптимально, створивши сценарій перекладу, я хотів би мати інтерактивну форму, де я можу "зіставити" поля у своєму вхідному шарі до вихідного шару (тобто. У вихідному шарі буде поле під назвою "Адреса", як воно називається у вхідному шарі?)

Деякі з них згадувались у питаннях запитань у розділі Які інструменти доступні для завантаження даних gis до бази даних?

І ось кілька пов’язаних статей, які я знайшов.

• http://fuzzytolerance.info/code/open-source-etl-tools/
• http://geobiwiki.spagoworld.org/xwiki/bin/view/Main/Talend+GeoKettle
• http://slashgeo.org/2011/07/25/Open-Source-ETL-Tools-GeoKettle-20-and-Spatial-Data-Integrator-420-Released

Це питання було перетворене на Wiki Wiki та заблоковано, тому що це приклад запитання, який шукає список відповідей і є досить популярним, щоб захистити його від закриття. Це слід розглядати як окремий випадок і не слід розглядати як тип запитання, який рекомендується на цьому або будь-якому сайті Stack Exchange, але якщо ви хочете внести до нього більше контенту, тоді не соромтеся, редагуючи цю відповідь. .

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

Я був у складі присяжних за звітом з випробувального терміну (вибачте, Google traduction "souservation de rapport de stage"), де студент описав ще один робочий процес FME, як цей, але цього разу для перевірки регіональних наборів даних, надісланих на національний рівень для інтеграції до національної бази даних про ризики. Основна відмінність полягає в тому, що в цьому останньому прикладі набір даних знаходився у дуже різних форматах файлів, растрових та векторних, масштабах та стилях.

Останнє, я перевірив інтегратор просторових даних, відкритий код ETL на базі Talend Open Studio. Особливостей було багато, однак менше, ніж FME, але я думаю, що основні відмінності полягали в документації та зручності створення робочого процесу. Мене часто змушували модифікувати джерело коду Java для компонентів робочого процесу. Але це була більш рання версія SDI, і недоліки, які я описую тут, є дещо звичними для проектів з відкритим кодом на їх початку, і ми не можемо порівнювати на тому ж рівні власне добре відточене програмне забезпечення та вільні молоді претенденти з відкритим кодом.

Для нещодавнього проекту, що працює з декількома ГБ просторових даних, я розпочав завантаження / перепрограмування даних за допомогою FME. Це спрацювало добре, але є крива навчання.

На завершення проекту я використовував сценарії Python для автоматизації процесів перегляду. FME може бути написаний сценарієм, але якщо ви маєте основи Python, чому ускладнюєте справи далі? Python дає вам повну гнучкість, і з кожним написаним сценарієм імпорту ваші навички Python вдосконалюються.

Наступні пакети Python були цінними при роботі з перетвореннями даних:

• PyProj
• GeoPy
• Струнко
• xlrd для імпорту даних з електронних таблиць Excel
• pyobdc для підключення до баз даних
• SQLAlchemy для запуску операторів SQL та роботи з базами даних

Якщо у вас є розробник / програмування, я рекомендую використовувати Python, якщо ви віддаєте перевагу роботі з графічним інтерфейсом (який також може створювати приємні зображення для документації), я рекомендую FME.

Я люблю відкритий код, але FME легко перемагає проти відкритих джерел ETL, як найкраще можу сказати. Це насправді досить дешево для обслуговування та підтримки (принаймні порівняно з більшістю інших корпоративних рішень, які ми маємо для речей).

Якщо ви шукаєте переклади між форматами, OGR може це зробити (з деякими перетвореннями в GDAL для перетворень). Звичайно, це командний рядок .

Для візуального моделювання понад тих, що вказані в коментарі "можливий дублікат", вони працюють над конструктором моделі QGIS / SEXTANTE; доказ концептуального відео: https://www.youtube.com/watch?v=LTUu-I2ouqU

(Ні, я не працюю для Safe, я просто порівняно щасливий клієнт).

Більшість простих операцій можуть виконуватись цими утилітами з відкритим кодом

• ogr2ogr для вектора
• gdal_translate та gdalwarp для растрових

Отримайте http://fwtools.maptools.org/ FWtools і спробуйте.

Я зробив порівняння різних інструментів близько року тому, що також містить більшість варіантів, згаданих у цій темі.

В якості більш прямої відповіді я дуже часто використовую FME завдяки його універсальності. Однак, коли я працюю зі складними структурами даних, такими як у CityGML, INSPIRE GML або більш великих моделях баз даних, я використовую HALE , додаток з відкритим кодом, розроблений для ETL та особливо узгодження.

Наразі (станом на версію 2.9.0) він порівнює з FME (2014 SP1) наступним чином:

• HALE має меншу кількість форматів (HALE: 20, FME 200) та трансформаторів (HALE: 30+, FME: понад 400), але дуже хороша підтримка всіх діалектів XML / GML
• HALE попередньо переглядає результати трансформації в інтерактивному режимі на карті та в представленнях таблиць, а також підтверджує вихід
• В основному HALE набагато швидше, оскільки підтримується локальний контекст для кожного атрибуту, економлячи, наприклад, багато FeatureMergers
• HALE є відкритим кодом та використовується у виробництві з 2010 року
• HALE використовують інтерпретаційний інтерфейс деклараційного відображення, що призводить до меншої кількості необхідних даних користувачів порівняно з процедурними підходами

Зауважте, що я був у команді HALE вже досить багато років.

Якщо ви подивитесь на дублікат посилання blah238s, ви знайдете більше інформації. Я б сказав, що Talend Open Studio і Pentaho GeoKettle - це найвидатніші рішення з відкритим кодом, які можна вибрати. З цих двох Talend цілей більше, ніж просто ETL та GeoKettle, трохи простіший у використанні, наскільки я читав.

Мій муніципалітет збирається дати GeoKettle написати діалект GML, складений шведською асоціацією місцевих органів влади та регіонів (SALAR), і нам потрібен цей формат для доставки геоданих до різних комерційних інтересів.

Я вважаю, що GeoKettle має підтримку OGR / GDAL від версії 2.0.

FME - це, мабуть, найкращий продукт для використання в цьому просторі. Після цього GDAL / OGR. Інший продукт з відкритим кодом у цьому просторі - геотекль - http://www.spatialytics.org/projects/geokettle/, хоча я ніколи не використовував його в гніві (пощастило згадати і інші продукти).

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

Використовував Geokettle релігійно для невеликої кривої високого навчання, якщо ви не використовували інтерфейс Eclipse ... Насправді потужний, як його складено з GDAL1.10, підтримує всі гео типи ... Мені сподобалось, що це підтримка як збережених даних, так і даних за допомогою сервісів ... Я використовував його для відтворення та синхронізації наборів даних сервера ArcGIS на локальному екземплярі postgis через ESRI json до GeoJSON ... Робочий процес може будуватись в умовах, а валідація встановлювати його для запиту на # об’єктід і на основі цього компілювати попередньо визначений csv щоб повторити запит на повідомлення для 500 функцій одночасно, залежно від першого запиту вдалося об'єднати всі запити в один файл geojson, запустити ogr2ogr для завантаження в postgis навіть сценарії поштових служб, щоб запустити вакуум і індексувати його ... Не пов'язаний просто фанат

Ви можете запустити його та зіставити робочий процес на gui настільних ПК та використовувати серверні інструменти pentahos, щоб налаштувати його на Hadoop та запустити його як скрипт або завдання cron.

QGIS (принаймні з поточної версії 2.6) тепер також має інтегрований конструктор моделей. За допомогою цієї панелі інструментів ви можете отримати доступ до алгоритмів (GDAL, GRASS, SAGA, vectortools тощо). Ви також можете додати свій власний сценарій.

Я мушу визнати, що не використовував його широко, але якби я шукав модельєра, вважав би це гідним дослідження.

[ПОПЕРЕДЖЕННЯ: Безкоштовна просування товару, з яким я причетний]

Ми працювали над інструментом ETL. За смаком він схожий на FME, але розроблений для більш простих завдань і вимагає менше досвіду для використання. Деякі деталі можна знайти на веб- сайті https://www.geoactive.it, просто шукайте інформацію про Data Dragon. Цей додаток використовує GDAL / OGR в задній частині, і ми натискаємо будь-які доповнення, які ми робимо назад до GDAL / OGR.

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

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