Каковы ваши самые большие проблемы в качестве разработчика ГИС?

Каковы ваши самые большие проблемы при разработке программного обеспечения ГИС?

Это кодирование? Понимает ли это концепции картографии / географии / и т.д. (например, проекции)? Или другие трудности?

Если говорить о моем опыте разработчика, который попал на сцену разработки 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. Я искренне надеюсь, что сообщество open source продолжает вводить новшества.

Большие объемы данных. Возможность найти правильный способ извлечения больших объемов данных с помощью веб-технологий была сложной задачей. У нас может быть как много данных, так и низкая производительность, или может отображаться намного меньше данных, но потенциально передается неверная информация.

Я не разработчик ГИС; Тем не менее, я модельер ГИС:

проблемы:

• Сбор, агрегация, дезагрегация, слияние и разделение данных: я получаю данные из разных источников для разных проектов; самая большая проблема, как правило, получение всех данных для одного и того же географического участка / района. Мне обычно приходится использовать несколько из упомянутых выше методов в каждом наборе данных, чтобы получить согласованную выборку для проекта. Это увеличивает вероятность ошибок и снижает нашу точность.

• Я не разработчик; Я повторяю, я не разработчик: когда вы, милые люди, говорите о SOAP, SHAMPOO, REST, GIS-T Indexes и т. Д., Это очень много значит для вас. Для меня это в основном жаргон. У меня обычно большая кривая обучения или крутой подъем, чтобы выполнить некоторые простые вещи.

• Разрыв между FOSS и проприетарным программным обеспечением: я люблю QGIS и postgis до смерти; буквально у меня они установлены на каждой машине; однако, когда я хочу провести анализ на основе транспортировки, я должен прибегнуть к 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 Maps используют довольно жесткую фильтрацию результатов поиска)

• Эффективное редактирование: привязка, закрытие многоугольников, добавление / перемещение / удаление точек, без большого количества кнопок панели инструментов.

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

• Как спроектировать что-то вроде буфера обмена для элементов / геометрий, чтобы избежать необходимости постоянно «выбирать» элемент с карты для использования в запросах, редактировании ...

Мне кажется, что ГИС является особенно сложной областью в аспекте юзабилити, потому что:

• Местоположение является универсальным и обычно наиболее естественным контекстом для любой информации, поэтому всегда есть слишком много информации, доступной для отображения

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

• Индустрия традиционно пренебрегала аспектом удобства использования программного обеспечения ГИС, и им это сошло с рук, потому что цифровое картографирование рассматривалось как техническая профессия с медленной кривой обучения и существовало гораздо более сложное изучение, чем использование интерфейса. Это означает, что любой, кто пытается спроектировать ГИС-интерфейс для неэксперта, должен придумать свои собственные принципы, которые обречены вводить в заблуждение (хорошим примером могут быть «Мои карты» Google или «Мои места» Bing Maps).

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

Этот вопрос возник в моем поиске в Google для задач в ГИС, и я чувствую, что хочу внести свой вклад здесь.

Еще одна ссылка, которая мне показалась актуальной, была эта статья.

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

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

Когда дело доходит до кодирования, я чувствую, что трачу слишком много времени на обходные пути. Для прогнозов мне потребовалось несколько месяцев, чтобы понять процессы и математику, поскольку, на мой взгляд, опубликовано мало полезных материалов по этому вопросу. Документы EPSG и OGC на эту тему помогли мне разобраться с этим после нескольких чтений, хотя иногда они кажутся копиями друг друга. Самая большая проблема, с которой я сталкиваюсь как независимый разработчик, заключается в том, что я не могу не думать о людях, нуждающихся в специальной работе для медицинской, промышленной или даже простой разработки веб-приложений, даже сейчас. С индустрией ГИС кажется почти невозможным найти выход на рынок.

Я полный новичок в ГИС-технологиях, я все выясняю по ходу дела. А поскольку у меня ограниченные средства, я стараюсь избегать использования каких-либо продуктов ESRI и делаю все с помощью инструментов с открытым исходным кодом.

Итак, самое сложное для меня до сих пор было связано со сбором данных. Там много статей о манипулировании и отображении данных, а также множество инструментов, которые сделают вашу жизнь проще. Но я собираюсь ходить в темноте, когда дело доходит до сбора данных.

Я понятия не имею, что делают профессионалы, чтобы найти и собрать данные. Что-то подсказывает мне, что есть более простой способ получить данные, чем data.gov и google.

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

Легко ожидать, что компетентный разработчик программного обеспечения подберет концепции ГИС, позволит им пройти через API и в общем разобраться без особой помощи. То же самое не относится к тому, чтобы брать ГИС-аналитика и ожидать, что он займется разработкой программного обеспечения.

Результаты смущают , в лучшем случае. Если у вас есть опыт работы с плохими разработчиками , то представьте, что это худший код, чем то, что разработал худший программист.

Есть компании, в которых вы можете работать, но которые этого не понимают.

мир ГИС расширяется до общего пользователя, если только в первые годы ГИС не рассматривались только инженерами, архитекторами или научным сообществом. В случае, если приложение ГИС предназначено для обычного пользователя, задача состоит в том, чтобы надлежащим образом сочетать технологии, в которых ГИС рассматривается как технология в большей степени (в этом случае достаточно разработчика с небольшим пониманием технологии ГИС). Однако в случае, если приложение создано для специализированного сообщества, задача более сложная, потому что помимо объединения технологий необходимо искать существующие алгоритмы, чтобы выполнить их требования, в противном случае, еще хуже, нам пришлось бы разрабатывать эти алгоритмы. В этом случае сочетание инженера и разработчика является подходящим для работника.