Які ваші найбільші проблеми як розробника ГІС?

Які ваші найбільші проблеми при розробці програмного забезпечення GIS?

Це кодування? Чи розуміє поняття картографії / географії / тощо (як прогнози)? Або інші труднощі?

Якщо говорити про мій досвід розробника, який потрапив на сцену розвитку ESRI / GIS майже 5 років тому:

1. Не існує єдиного API, щоб робити те, що ви хочете зробити. Лише безладний безлад API, який може працювати або не працювати для ваших цілей: оператори ArcObjects, Python, REST, SOAP, ADF, ST_Geometry?
2. Всі API прив’язані до якогось незграбного, дорогого програмного забезпечення, яке ви краще не розміщуєте в основі вашої програми.
3. Маленька можливість по-справжньому креативного дизайну. Об'єктно-орієнтовані геопросторові структури даних? Забудь це. Незважаючи на всі розмови про "об'єкти" та "класи функцій", ти все ще працюєш з тупими таблицями, опосередкованими примхливими середніми програмами.
4. Програмне забезпечення є помилковим, повідомлення про помилки вводить в оману, а документація неповна. Виправлення неполадок майже завжди є спробою та помилками. Звикнути.
5. Управління геопросторовими даними за допомогою методів реляційних баз даних майже неможливо. Мені довелося майже відмовитися від будь-якого SQL / DDL, тому що вони просто заважають мені проміжне програмне забезпечення (так, я кажу про ArcSDE). Соромно викидати цілий набір навичок. Просто відкрийте ArcCatalog, вкажіть, натисніть.

Як ви можете сказати, у мене досить негативний прогноз на сцені розвитку ESRI. Для тих, хто походить з географічного походження, я впевнений, що можливості досить захоплюючі. Але для когось, як я, який любить реляційні бази даних, об’єктно-орієнтоване програмування та широку відкриту можливість для творчих рішень, розробка ГІС за допомогою ESRI є дуже стриманою та нездійсненою. Це прикро, тому що натовп старої школи говорить мені, що раніше, перш ніж узгоджуватися з Microsoft, це було чудовим середовищем. Я щиро сподіваюсь, що спільнота з відкритим кодом продовжує інновації.

Великий обсяг даних. Можливість з'ясувати правильний спосіб отримання великої кількості даних за допомогою веб-технологій стала проблемою. Ми можемо мати чимало даних і низьку продуктивність, або мати набагато менше даних, але потенційно передавати неправильну інформацію.

Я не розробник ГІС; однак я GIS-модельєр:

Виклики:

• Збір даних, агрегація, дезагрегація, об'єднання та розщеплення: я отримую дані з різних джерел для різних проектів; Найбільшою проблемою є зазвичай отримання всіх даних для тієї ж географічної посилки / області. Зазвичай мені доводиться використовувати декілька вищезазначених методик для кожного набору даних, щоб мати цілісний зразок для проекту. Це збільшує ймовірність помилок і зменшує нашу точність.

• Я не розробник; Я повторюю, що я не розробник: коли ви прекрасні люди говорять про SOAP, SHAMPOO, REST, GIS-T індекси тощо., Це для вас дуже багато означає. Для мене в основному це жаргон. У мене зазвичай є велика крива навчання або крутий підйом, щоб зробити деякі прості речі.

• Розрив між FOSS та власним програмним забезпеченням: я люблю QGIS та постгіс до смерті; буквально у мене їх встановлено на кожній машині; однак, коли я хочу зробити аналіз на транспорті, я повинен вдатися до TransCAD або EMME2 / 3. Кожен коштує близько 15 000 доларів з усіма дзвіночками. Чесно кажучи, усі ці проблеми можна було б вирішити, якби існував пакет networkx для файлів shp.

• Випуск декількох дисциплін: Я добре розбираюся в техніці моделювання транспорту; як би не вдавалося демографічного моделювання, і наскільки я можу сказати, мені потрібно використовувати складні інструменти R, щоб зробити свої дані. Отже, проблема ГІС полягає в тому, що ГІС - це багатопрофільне поле, яке важко пережити самостійно.

• Відсутність налагоджених інструментів та програмного забезпечення для переходу від використання земель для зображень до векторного землекористування: я передбачаю майбутнє, коли інструмент буде аналізувати супутникове зображення GEOEYE і порівнювати використання землі в ньому з векторною (як вбудованою) базою даних

• Іноді швидше робити речі в Excel / "ваша програма для розповсюдження фаворитів йде сюди: Іноді я хочу зробити транзитний аналіз, набагато швидше схопити дані, поставити їх у excel, чи формули працювати, а потім скинути дані назад у postgis як файл csv та регенерувати карту. Такий розрив, особливо у світі OpenSource, має бути краще.

У будь-якому випадку я, можливо, не відповів вам правильно; Я просто хочу, щоб я добре розбирався, коли мова йде про програмування ГІС, щоб я міг досягти успіху в ГІС-моделюванні

Найважливіші речі, і, як правило, найскладніші в моєму досвіді:

1. отримати потрібні дані для роботи
2. змусити його показуватись у правильній проекції (і погодившись з усіма шарами). Особливо, коли вони надходять із різних джерел
3. розробити корисну програму. Легко і спокусливо поставити безліч дзвіночків, які лише збентежать користувачів

Я думаю, що точка 1 буде легшою у розвинених країнах, але це не мій досвід.

Для мене найбільшою проблемою є вирішення, які інструменти використовувати для даного проекту. Відкритий чи захищений? Python чи .NET? Веб-сайт чи настільний ПК? Я відповідаю на ці запитання по-різному для різних проектів, і я впевнений, що люди зададуть їх усім на цьому сайті. Багато чого зводиться до особистих уподобань і намагається визначити, що підтримуватимуть ESRI та Microsoft у майбутньому.

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

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

Врешті-решт - ми, будучи одним із перших експертів та програмістів ГІС - з часом станемо керівництвом, і тоді ми зможемо нарешті виконати кілька гідних проектів ГІС!

Інша важка річ, як програміст ГІС - ви повинні розуміти так багато різних технологій, Java, .Net, баз даних, програмне забезпечення ESRI або інших постачальників, тобто MapInfo, мереж, безпеки, веб-технологій тощо. Іноді це майже неможлива робота!

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

№3 з відповіді Вінко :

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

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

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

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

• Як зробити автоматичне позиціонування подання карти на основі запиту / вибору функції користувача

• Виділення "вибраних" функцій - чи висвітлюєте ви лише коротко, чи це підсвічується весь час, коли вибирається функція, чи не знімаєте виділення, коли таблиця (або список) вибору втрачає фокус ... Як виділити обидва запити результати з таблиці та вибраного рядка в цій таблиці (без занадто великої кількості кнопок перемикання)

• Показ додаткової інформації у списках шарів або особливостей, наприклад, видимість шару / тип застосованого стилю / тип геометрії, статус / клас функції ... Це стає ще складнішим у випадку, якщо в одному списку відображаються різні типи функцій (я думаю, саме тому Карти Google і Bing використовують досить важку фільтрацію результатів пошуку)

• Ефективне редагування: оснащення, закриття полігонів, додавання / переміщення / видалення точок, не маючи багато кнопок панелі інструментів.

• Як створити (і реалізувати) інтерфейс запитів, який користувачі часто використовують для геометричних запитів, а ще складніше - інтерфейс для запитів, що включає як атрибути, так і геометрію; не створюючи користувачеві тип щось подібне до SQL.

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

Я відчуваю, що ГІС - це особливо складна сфера в застосуванні, оскільки:

• Розташування - це універсальний і, як правило, найприродніший контекст для будь-якої інформації, тому для відображення завжди доступно занадто багато інформації

• Маючи інформацію, відображену на карті, можна легко спокуситись на важливості не-ГІС-частин інтерфейсу користувача

• Галузь традиційно нехтує аспектом зручності використання програмного забезпечення ГІС, і вони відійшли від цього, оскільки цифрове відображення розглядалося як технічна торгівля з повільною кривою навчання, і навчитися набагато складніше, ніж використовувати інтерфейс. Це означає, що кожен, хто намагається розробити GIS-інтерфейс для неекспертів, повинен вигадати свої власні принципи, приречені на заплутаність (чудовим прикладом може бути Google "Мої карти" або "Bing Maps" "Мої місця")

Однією з найбільших проблем для розробки ГІС на основі веб-сторінок є те, як передаються дані та яка ефективність я можу отримати від певної передачі даних. Найбільша перешкода полягає в тому, що дуже важко написати код для чогось, що вимагає налаштування людини. Дуже рідко ви бачите методи узагальнення векторних даних, що використовуються у великих масштабах. Більшість разів вам доводиться підлаштовувати діапазон масштабу, щоб увімкнути та вимкнути шари.

Це запитання виникло під час мого пошуку в Google за викликами в ГІС, і я можу зробити свій внесок тут.

Ще одним посиланням, яке я вважав актуальним, був цей документ.

Підсумовуючи сказане там і мої власні погляди, я вважаю, що найбільші проблеми (не в певному порядку):

• Інтерфейс користувача: Завдяки безлічі параметрів користувальницького інтерфейсу розробнику складно оптимізувати пропозицію з урахуванням усіх пристроїв. На основі сенсорного та проти робочого столу проти носіння. Ідея DE, представлена ​​компанією Gore, яка має носити гарнітуру з дисплеєм, рукавички з керуванням напрямком та розпізнаванням мови - це фантастичне майбутнє.
• Стандартизація: За допомогою стандартів зберігання та пошуку даних ми можемо мати геобази, які опираються у хмару та дозволяють отримувати інформацію під час руху, щоб безперервно переглядати та використовувати ГІС.
• Використання даних: Ті, хто приймає рішення, завжди натискають час. Якщо інструмент повинен допомогти їм, він повинен робити це плавно, легко і швидко. Здається, ГІС не реалізується на цьому фронті, і це одна з причин, чому це все ще не казкове слово.
• Дані: дані різноманітні, розсіяні та галасливі. Навіть для організацій, які мають чіткі стимули щодо використання ГІС у режимі реального часу, агрегування даних є ще перешкодою для передбачення вступу.
• Координовані зусилля: ГІС є багатодисциплінарним. Кожна дитина це знає. Про це керівництво повідомляє на першому слайді. Хоча такі міждисциплінарні, міжвідомчі проекти зустрічаються рідко.

Що стосується кодування, я вважаю, що витрачаю занадто багато часу на обхідні шляхи. Для прогнозів мені знадобилося пару місяців, щоб зрозуміти процеси та математику, оскільки на мій погляд, мало корисних опублікованих матеріалів з цього питання. Документи EPSG та OGC на цю тему допомогли мені обняти голову після декількох читань, хоча вони часом здаються копіями один одного. Найбільша проблема, яку я маю, як незалежний розробник, полягає в тому, що я не можу не подолати людей, які потребують спеціалізованої роботи для розробки медичних, промислових чи навіть простих веб-додатків, навіть зараз. З індустрією ГІС здається майже неможливим знайти спосіб виходу на ринок.

Я повний початківець у GIS-технологіях, розгадуючи речі, як іду. А оскільки у мене є обмежені кошти, я намагаюся уникати використання будь-яких продуктів ESRI і робити цілком речі з інструментами з відкритим кодом.

Тож, сказане, найважчі речі для мене поки що пов'язані зі збором даних. Існує безліч статей про маніпулювання та відображення даних та безліч інструментів для полегшення життя. Але я підвіконня ходжу в темряві, коли йдеться про збір даних.

Я поняття не маю, що професіонали роблять для пошуку та збору даних. Щось говорить про те, що є більш простий спосіб отримати дані, ніж data.gov та google.

Можливо, вам прикро примусити працювати з аналітиками ГІС, які були перетворені на розробників програмного забезпечення.

Неважко розраховувати на те, що грамотний розробник програмного забезпечення підбере ГІС-концепції та дозволить їм пройти API і взагалі розібратися з нею без особливої ​​допомоги. Це ж не вірно брати аналітика ГІС та очікувати, що вони підберуть розробку програмного забезпечення.

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

Є деякі компанії, на яких ви можете працювати, але цього не виходить.

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