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

23

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

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

George
источник
Я люблю эту дискуссию. Я знаю, это старая тема, но информация ЗОЛОТА. Я работаю на Esri в качестве менеджера по продуктам разработчиков продуктов. Я смотрю на ArcGIS Runtime SDK (Java, Android, Qt) и ArcObjects SDK для Java. Прежде всего, я могу сопереживать с болью. Во-вторых, я хотел бы услышать, помогли ли веб-API и API-интерфейсы ArcGIS Runtime уменьшить болевые точки при использовании платформы или вообще. Полагаю, что обработка большого и большого количества данных все еще остается проблемой, но становится ли все лучше ... сейчас, 5 лет спустя? Сервисы, как онлайн, так и портала, становятся все более надежными. Т
Привет Эрик, добро пожаловать в GIS.SE. Всегда приятно видеть сотрудников софтверной компании, участвующих в сообществе. Мы здесь чуть меньше дискуссионного форума и более конкретные вопросы и ответы. Вы можете проверить тур . У нас есть чат для разговоров, хотя он не используется широко. Вы также можете взглянуть на нашу систему тегов. Используя это, вы можете отследить недавнюю активность в вопросах по определенной теме, например, API и SDK, которые вы упомянули.
Крис У
Также добро пожаловать в ГИС Ю Эрик! Еще раз осмотрев сайт, я надеюсь, что вы быстро поймете, что представляет собой Stack Exchange, и насколько отличается его сфокусированный формат вопросов и ответов от дискуссионного форума. Это именно то, на что я надеялся, что дискуссионные форумы ArcGIS станут последним капитальным ремонтом. Однако, пожалуйста, не судите о его ценности в этом раннем вопросе и ответе, который, несмотря на его популярность, не является хорошим примером того, как пользователи могут прийти сюда в поисках ответа, и в течение нескольких минут идентифицируют тот же вопрос и читают его ответ, не имея переварить туда и обратно обсуждение.
PolyGeo

Ответы:

22

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

NW1
источник
4
Я статистик, и у меня очень похожие жалобы на продукты ESRI. Моя чрезмерно оптимистичная теория заключается в том, что, поскольку компьютеры, вероятно, применялись для статистики до ГИС, программное обеспечение ГИС отстает от статистического программного обеспечения примерно на десять лет (на этапе SAS / SPSS) и что действительно выдающаяся программа или стек с открытым исходным кодом находится на грани вырваться. Возможно, это уже было - прошло много лет с тех пор, как у меня была возможность играть с программами, не относящимися к ESRI.
Мэтт Паркер
2
Я просто присоединюсь, чтобы фактически потрясти кулаком в Redlands вместе с остальными, и передам иллюстративный анекдот: практически любой вызов API в растровые API-интерфейсы Spatial Analyst (на тот момент) не удался с универсальной ошибкой COM "Unspecified Error «если что-то пошло не так. Отчаянно пытаясь устранить неполадки, я закончил тем, что подключил strace к ArcGIS.exe и, скрывшись в системных вызовах, обнаружил (барабанная дробь), что полезные и подробные сообщения об ошибках эпохи 1980-х записывались в окна, эквивалентные / dev / null.
Дан С.
13

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

Хьюго Эстрада
источник
10

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

проблемы:

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

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

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

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

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

  • Иногда это быстрее сделать в Excel / "ваша любимая программа электронных таблиц идет сюда: иногда я хочу провести транзитный анализ, намного быстрее получить данные, поместить их в Excel, выполнить формулы, а затем сбросить данные обратно в postgis как CSV-файл и восстановить карту. Такое разделение, особенно в мире OpenSource, должно быть лучше обработано.

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

dassouki
источник
Networkx для shp уже существует К вашему сведению, например networkx.github.io/documentation/latest/reference/… Информацию о векторе и растре см. В разделе Расширение растра PostGIS trac.osgeo.org/postgis/wiki/WKTRaster
ThomasG77
+1 самая большая проблема это надежные источники данных. Многие штаты будут нанимать стажеров колледжей для летней работы, чтобы собирать координаты для дорог и прочего, и обычно они вообще не проверяются и не проверяются на ошибки (даже не на образцах), и в результате теперь у вас есть ТОЧКА Нью-Джерси, говорящая, что Дорога на 500 футов короче, чем Google, и OSM утверждает, что это так. Goddamit.
ничего лишнего
8

Самые важные вещи, и, как правило, самые тяжелые в моем опыте, это:

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

Я думаю, что пункт 1 будет легче в развитых странах, но это не мой опыт.

Винко Врсалович
источник
6

Для меня самая большая проблема - решить, какие инструменты использовать для данного проекта. Открытый исходный код или проприетарный? Python или .NET? Сетевой или настольный? Я отвечаю на эти вопросы по-разному для разных проектов, и я уверен, что люди зададут их все на этом сайте. Многое из этого сводится к личным предпочтениям и попыткам угадать, что ESRI и Microsoft будут поддерживать в будущем.

jswise
источник
Это должно быть самой большой вещью для меня.
Натан W
2
Это менее важно для меня. Хотя в интересах разработчика вкладывать средства в собственное будущее и избегать «напрасной работы», я считаю, что цели оправдывают средства, и какая бы технология ни выполнялась, это лучший выбор. Наличие четкого представления о том, что вам нужно доставить, является более важным, чем то, как вы туда доберетесь.
mwalker
5

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

wilsongis
источник
3

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

В конечном счете, хотя мы являемся одними из первых экспертов и программистов в области ГИС, мы в конечном итоге станем менеджментом, и тогда мы сможем наконец-то сделать несколько достойных ГИС-проектов!

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

Видар
источник
2

Имея дело с людьми из опроса, которые не разбираются в профессиональных методах и методологиях разработки программного обеспечения, а потому, что они сами научились кодировать проспект / VB, думают, что это все, что нужно.

BlinkyBill
источник
2

№ 3 из ответа Винко :

разработать полезное приложение. Легко и заманчиво поставить много наворотов, которые только смущают пользователей.

Я бы проголосовал за весь ответ, но за то, что юзабилити - это только третий пункт в его списке, и я не думаю, что первые два являются такими сложными.

Юзабилити - это то, где большинство моих проблем и где я трачу большую часть времени на разработку / разработку, выясняя, как спроектировать интеллектуальный и эффективный пользовательский интерфейс, но сохраняя его интуитивно понятным, чтобы пользователи его не смущали, например:

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

  • Как сделать автоматическое позиционирование вида карты на основе запроса пользователя / выбора функции

  • Выделение «выбранных» объектов - вы показываете выделение ненадолго, подсвечиваете ли оно все время, когда выбран объект, отменяет выделение, когда таблица выбора (или список) теряет фокус ... Как выделить оба запроса результаты из таблицы и выбранной строки в этой таблице (без слишком большого количества переключателей)

  • Отображение дополнительной информации в списках слоев или объектов, например, видимость слоя / примененный стиль / тип геометрии, статус / класс объекта ... Это становится еще сложнее, если в одном и том же списке отображаются разные типы объектов (наверное, поэтому Google и Bing Maps используют довольно жесткую фильтрацию результатов поиска)

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

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

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

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

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

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

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

оборота мкадунч
источник
2

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

CrazyEnigma
источник
1

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

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

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

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

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

Денди
источник
0

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

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

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

оборота Эрик Палакович Карр
источник
Большинству нам пришлось покупать его у поставщиков, которые проводят фактические наземные обследования и переоборудование из других источников. В третьем мире получение данных от правительства открыто является
PITA
-1

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

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

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

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

пустой набор
источник
2
@emptyset: я географ, который стал разработчиком. Я не думаю, что мои результаты в лучшем случае "смущают". У меня гораздо больше навыков разработки, чем у других коллег, которые имеют опыт работы в сфере ИТ, включая лучшее понимание и использование концепций ООП, концепций и правил баз данных и т. Д. Конечно, я не согласен с вашим ответом: P
Джордж Сильва,
1
@ Джордж: И я не говорю, что вы сказали иначе, просто отмечая, что, чтобы быть великим разработчиком, вы должны знать, сколько вы отстой. По крайней мере, я пытаюсь.
Винко Врсалович
2
+1 Много раз меня просили «просто исправить ошибки» в «Большом шарике грязи» en.wikipedia.org/wiki/Big_ball_of_mud, написанном одним или несколькими аналитиками. Часть худшего кода была написана некоторыми из самых умных аналитиков. Часто умные не могут оценить красоту простоты. Часто ошибка связана с управлением - аналитик может осознавать ценность рефакторинга, но не может оправдать тратить время на изменение кода, который не нарушен.
Кирк Куйкендалл
3
Как следствие, вам может быть не повезло работать с разработчиками программного обеспечения, которые вынуждены работать в качестве специалистов по ГИС. Я очень настороженно отношусь к любому, из любой области, просто выясняю, как они идут в ГИС. Я аналитик, исследующий разработку, и я полностью ожидаю - и хочу - чтобы люди с осторожностью относились к моему коду. Любой разработчик, который чувствует, что у него все хорошо в ГИС, вероятно, нет. :-)
Мэтт Вилки
3
-1 - очень широкое утверждение, которое доказуемо ложно и несколько оскорбительно. Как подразумевает Мэтт W выше, вам, как правило, лучше, чтобы ГИС пришел к кодированию, чем наоборот, потому что есть гораздо больше ресурсов, которые помогут вам изучить кодирование и внедрить лучшие практики, чем в ГИС
dmbrubac
-1

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

Родольфо Морено
источник