GIS開発者としての最大の課題は何ですか?


23

GISソフトウェアを開発する際の最大の課題は何ですか?

コーディングですか?地図作成/地理/などの概念(投影など)を理解していますか?または他の困難?


この議論が大好きです。古いスレッドを知っていますが、情報はゴールドです。Esriで開発者製品のプロダクトマネージャーとして働いています。ArcGIS Runtime SDK(Java、Android、Qt)およびArcObjects SDK for Javaを管理しています。まず第一に、私は痛みに共感することができます。第二に、Web APIとArcGIS Runtime APIがプラットフォームを使用する際の苦痛を軽減するのに役立っているか、それとも一般的なことかを聞きたいと思います。大量のデータを処理することは依然として挑戦だと思いますが、5年後には少し良くなっていますか?オンラインとポータルの両方のサービスがより堅牢になっています。t

こんにちはEric、GIS.SEへようこそ。ソフトウェア会社の従業員がコミュニティに参加しているのを見るのはいつも良いことです。ここではディスカッションフォーラムが少し少なく、より具体的なQ&Aです。あなたはツアーをチェックアウトしたいかもしれません。会話用のチャットはありますが、あまり使用されていません。タグ付けシステムもご覧ください。これを使用すると、言及したAPIやSDKなど、特定のテーマに関する最近の質問アクティビティに集中できます。
クリスW

同様に、GIS SE Ericへようこそ!このサイトをもう少し見て回ると、Stack Exchangeの概要と、焦点を絞ったQ&A形式がディスカッションフォーラムとどのように異なるかをすぐに理解できることを願っています。これはまさに、ArcGISディスカッションフォーラムが最新のオーバーホールになることを期待していたものです。ただし、この初期のQ&Aでその価値を判断しないでください。人気があるにもかかわらず、ユーザーがここに来て回答を探す方法の良い例ではなく、数分以内に同じ質問を識別し、前後の議論を消化します。
PolyGeo

回答:


22

5年近く前にESRI / GIS開発シーンに落ちた開発者としての私の経験から言えば:

  1. やりたいことを行うための単一のAPIはありません。ArcObjects、Python、REST、SOAP、ADF、ST_Geometry演算子など、目的に合ったAPIがごちゃごちゃになっているかどうかはわかりませんか?
  2. すべてのAPIは、アプリケーションのコアに配置したくない、不格好で高価なソフトウェアに関連付けられています。
  3. 真に創造的なデザインの機会はほとんどありません。オブジェクト指向の地理空間データ構造?忘れてください。「オブジェクト」と「機能クラス」についてのすべての話にもかかわらず、気まぐれなミドルウェアを介したダムテーブルで作業しています。
  4. このソフトウェアはバグが多く、誤解を招くエラーメッセージがあり、ドキュメントが不完全です。トラブルシューティングはほとんどの場合試行錯誤です。それに慣れる。
  5. リレーショナルデータベースメソッドを使用して地理空間データを管理することはほとんど不可能です。SQL / DDLはミドルウェアで問題を起こすだけなので、ほとんど放棄しなければなりませんでした(はい、ArcSDEについて話しているのです)。スキルセット全体を捨てることは残念です。ArcCatalogを開き、ポイントしてクリックするだけです。

おわかりのように、私はESRI開発シーンについてかなり否定的な見方をしています。地理的な背景から来ている人にとっては、可能性はかなりエキサイティングだと確信しています。しかし、リレーショナルデータベース、オブジェクト指向プログラミング、および創造的なソリューションの幅広い機会を愛する私のような人にとって、ESRIを使用したGIS開発は非常に制約があり、実現できません。古い学校の群衆は、マイクロソフトと提携する前は以前は優れた環境だったと私に言っているので、これは残念です。私は、オープンソースコミュニティが革新し続けることを心から願っています。


4
私は統計学者であり、ESRI製品に関して非常によく似た不満を持っています。私の過度に楽観的な理論は、コンピューターがおそらくGISの前に統計に適用されたため、GISソフトウェアは統計ソフトウェア(SAS / SPSSフェーズ)に約10年遅れており、真に傑出したオープンソースプログラムまたはスタックがまもなくあるということですブレークアウトの。たぶん、すでに持っているかもしれません。ESRI以外のプログラムで遊ぶ機会があったので、何年も経ちました。
マットパーカー

2
レッドランズの拳を他の人たちと一緒に仮想的に揺さぶるためにチャイムを鳴らし、説明的な逸話を引き渡します。 「何か問題が発生した場合。トラブルシューティングのために必死になって、straceをArcGIS.exeに接続し、システムコールに埋もれ、1980年代時代の有用で詳細なエラーメッセージが/ dev / nullに相当するウィンドウに書き込まれていることがわかりました(ドラムロール)。
ダンS.

13

大量のデータ。Webテクノロジーを使用して大量のデータを抽出する正しい方法を見つけることができるようにすることは、挑戦でした。大量のデータがあり、パフォーマンスが低いか、表示されるデータがかなり少なくても、間違った情報を伝える可能性があります。


10

私はGIS開発者ではありません。ただし、私はGISモデラーです。

課題:

  • データの収集、集約、分解、マージ、および分割:さまざまなプロジェクトのさまざまなソースからデータを取得します。最大の問題は通常、同じ地理的区画/エリアのすべてのデータを取得することです。プロジェクトの一貫したサンプルを得るには、通常、すべてのデータセットで上記の手法のいくつかを使用する必要があります。これにより、エラーの可能性が高まり、精度が低下します。

  • 私は開発者ではありません。繰り返しますが、私は開発者ではありません。素敵な人がSOAP、SHAMPOO、REST、GIS-Tインデックスなどについて話すとき、これはあなたにとって大きな意味があります。私にとっては、ほとんどが専門用語です。私は通常、簡単なことを成し遂げるために大きな学習曲線または急な上り坂を持っています。

  • FOSSと独自のソフトウェアのギャップ:私はQGISとpostgisが大好きです。文字通り、私はそれらをすべてのマシンにインストールしています。ただし、交通ベースの分析を行いたい場合は、TransCADまたはEMME2 / 3に頼らなければなりません。それぞれの機能は約15,000ドルです。すべての公平において、shpファイル用のnetworkxパッケージがあれば、これらの問題はすべて解決できます。

  • 複数の分野の問題:私は交通モデリングの手法に精通しています。ただし、人口統計学的モデリングは得意ではありません。私が知る限り、データを処理するには洗練されたRツールを使用する必要があります。GISの問題は、GISは学際的な分野であり、独力で生き残ることは難しいということです。

  • 画像の土地利用からベクターの土地利用に移行するための十分に確立されたツールとソフトウェアの欠如:ツールがGEOEYE衛星画像を分析し、その土地利用をベクター(構築時)データベースと比較する未来を予測します

  • Excel / "favスプレッドシートプログラムでここに行くのが速い場合があります。トランジット分析をしたい場合は、データを取得してExcelに入れ、式を実行してからデータをダンプして戻すのがはるかに高速ですcsvファイルとしてpostgisに変換し、マップを再生成します。特にOpenSourceの世界では、このような分割はより適切に処理されるはずです。

とにかく私はあなたに正しく答えていないかもしれません。GISプログラミングに精通していれば、GISモデリングに秀でることができます。


SHPのためのNetworkxはすでに存在してFYI例えばnetworkx.github.io/documentation/latest/reference/...ベクトル+ラスタについては、PostGISのラスタ延長見るtrac.osgeo.org/postgis/wiki/WKTRaster
ThomasG77

+1の最大の問題は、信頼できるデータソースです。多くの州では、夏の仕事のために大学のインターンを雇って道路や物の座標を収集し、通常はエラーチェックや監査を一切行いません(サンプルも含めません)。道路はGoogleよりも500フィート短く、OSMはそうです。ゴダミット。
何も必要ありません

8

最も重要なこと、そして通常私の経験で最も難しいことは次のとおりです。

  1. ジョブに適切なデータを取得する
  2. 適切な投影で表示するようにします(すべてのレイヤーが一致するようにします。)特に、異なるソースからの場合
  3. 使用可能なアプリケーションを設計します。ユーザーを混乱させるだけの多くの機能を追加するのは簡単で魅力的です

ポイント1は先進国では簡単になると思いますが、それは私の経験ではありません。


6

私にとって最大の課題は、特定のプロジェクトに使用するツールを決定することです。オープンソースまたはプロプライエタリ?Pythonまたは.NET?ウェブベースかデスクトップか?私はこれらの質問にプロジェクトごとに異なって答え、人々はこのサイトでそれらすべてを尋ねると確信しています。その多くは個人的な好みに帰着し、ESRIとMicrosoftが将来サポートするものを神にしようとしています。


これは私にとって最大のものでなければなりません。
ネイサンW

2
これは私にとってそれほど重要ではありません。開発者が自分の将来に投資し、「無駄な仕事」を避けることは最善の利益ですが、目的は手段を正当化するものであり、どのようなテクノロジーが仕事をするのも最良の選択だと思います。配信する必要があるものを明確に把握することは、そこに到達する方法よりも重要です。
mwalker

5

私の問題は、馬と水に関するものです。多くの場合、私たちはクライアントのために本当に良いソリューションを開発または提示しますが、どれほどエレガントなソリューションであっても、だれも使用する時間がなければ絶対に役に立ちません。場合によっては、作業ユーザーベース(問題の調査、開発の前にソリューションについて話す)にすることでこれを軽減できましたが、それでもまだ十分ではありません。


3

最も困難な課題は、管理者にGISを理解させることであり、一部のユーザーもGISを理解できないことです。GISは地図の作成に関するものだという認識です。マップがGISの努力の唯一の結果であること。私がこれをどれほど苛立たせているかは言えません-そこにある無知のレベルは巨大であり、それは主要な意思決定者によって保持されています。

しかし、最終的には、私たちは先駆的なGISの専門家およびプログラマーの一部であり、最終的には管理者となり、ついに適切なGISプロジェクトを完成させることができます!

GISプログラマーとしてのもう1つの困難なことは、Java、.Net、データベース、ESRIソフトウェア、またはMapInfo、ネットワーク、セキュリティ、Webテクノロジーなど、他のベンダーのような多くの異なるテクノロジーを理解する必要があることです。


2

専門的なソフトウェア開発の手法や方法論を理解していないが、アベニュー/ VBのコーディング方法を自分自身で学んだため、調査のバックグラウンドの人々に対処するのはそれだけだと思います。


2

ヴィンコの答えから#3 :

使用可能なアプリケーションを設計します。ユーザーを混乱させるだけの多くの機能を追加するのは簡単で魅力的です。

答え全体に投票しますが、ユーザビリティは彼のリストの3番目の項目にすぎず、最初の2つはそれほど難しいとは思いません。

使いやすさは、私の問題の大部分があり、設計/開発時間の大部分を費やしている場所であり、インテリジェントで効果的なユーザーインターフェイスを設計する方法を考え出しますが、ユーザーが混乱しないように直感的に保ちます。

  • インタラクティブマップのスタイリングを調整(およびレイヤーを選択)して関連情報を表示し、多くのデータの表示に伴う混乱を回避する方法(ポイントフィーチャの自動集計を使用するなど)。私はこれが古くから地図作成が解決しようとしてきたものであることを知っていますが、問題はデジタル/インタラクティブマップでのみ悪化します

  • ユーザーのクエリ/機能選択に基づいてマップビューの自動配置を行う方法

  • 「選択された」機能のハイライト-ハイライトを簡単に表示しますか、機能が選択されている間ずっとハイライトしますか、選択テーブル(またはリスト)がフォーカスを失ったときにハイライトを解除しますか。テーブルとそのテーブル内の選択された行からの結果(トグルボタンが多すぎることなく)

  • レイヤーまたは機能のリストに追加情報を表示します。たとえば、レイヤーの可視性/適用されたスタイル/ジオメトリタイプ、機能のステータス/クラスなどです。同じリストに異なる機能タイプが表示される場合、これはさらに複雑になりますGoogleとBing Mapsでは、検索結果のフィルタリングをかなり使用しています)

  • 効率的な編集:多数のツールバーボタンなしで、スナップ、ポリゴンのクローズ、ポイントの追加/移動/削除。

  • ジオメトリクエリ用のユーザーにやさしいクエリインターフェイス、およびさらに難しい、属性とジオメトリの両方を含むクエリ用のインターフェイスを設計(および実装)する方法。ユーザーをSQLに似たものに入力することなく。

  • クエリ/編集で使用するためにマップからフィーチャーを継続的に「選択」する必要を回避するために、フィーチャー/ジオメトリ用のクリップボードのようなものを設計する方法...

私の考えでは、GISはユーザビリティの面で特に挑戦的な分野だと思います。

  • 場所は普遍的であり、通常はあらゆる情報の最も自然なコンテキストです。したがって、表示できる情報は常に多すぎます。

  • 地図に情報が表示されると、ユーザーインターフェイスの非GIS部分の重要性を過小評価したくなる傾向があります。

  • 業界では伝統的にGISソフトウェアのユーザビリティの側面を無視してきましたが、デジタルマッピングは学習曲線の遅い技術的な取引と見なされ、インターフェイスの使用方法よりもはるかに難しい概念があったため、彼らはそれを使い果たしました。これは、非専門家向けのGISインターフェースを設計しようとする人は、混乱を招く運命にある独自の原則を発明しなければならないことを意味します(Googleの「マイマップ」またはBingマップの「マイプレイス」が良い例です)


2

WebベースのGIS開発の最大の課題の1つは、データの配信方法と、特定の方法でデータを配信することで得られる効率です。最大のハードルは、人間が微調整する必要があるもののコードを書くことが非常に難しいことです。大規模で使用されるベクトルデータの一般化手法はほとんどありません。ほとんどの場合、スケール範囲を微調整して、レイヤーのオンとオフを切り替える必要があります。


1

この質問は、Google検索でGISの課題について出てきたもので、ここで貢献したいと思っています。

関連性があると感じた別のリンクは、この論文でした。

そこに述べられていることと私自身の見解を要約すると、最大の課題は(特定の順序ではありません):

  • ユーザーインターフェイス:ユーザーインターフェイスオプションのホストでは、開発者がすべてのデバイスに適合するように製品を最適化することは困難です。タッチベースvsデスクトップvsウェアラブル。ディスプレイを備えたウェアラブルヘッドセット、方向制御機能を備えた手袋、音声認識を備えたGoreが提示したDEのアイデアは、素晴らしい未来です。
  • 標準化:データの保存と取得の標準を使用すると、クラウド内にジオデータベースを配置し、実行時に情報を取得できるようにして、GISの閲覧と使用をスムーズにすることができます。
  • データの使用:意思決定者は常に時間に追われています。ツールが彼らを助けることであるなら、それは滑らかで、簡単で、迅速な方法でそれをするべきです。GISはこの分野では提供されていないようであり、それがまだ流行語ではない理由の1つです。
  • データ:データは多様で、ばらばらで、ノイズが多い。リアルタイムGISに明確なインセンティブを持っている組織でさえ、データの集約は参入を想定する上で大きな障害となっています。
  • 調整された努力: GISは学際的です。すべての子供はそれを知っています。経営陣は、最初のスライドでそれを認識します。このような学際的で複数の部門にわたるプロジェクトはまれですが。

0

コーディングに関しては、回避策に時間をかけすぎているように感じます。私の意見では、このテーマに関する有用な出版物はほとんどないので、予測のためにプロセスと数学を理解するのに数ヶ月かかりました。主題に関するEPSGおよびOGCのドキュメントは、数回読んだ後に頭をかわすのに役立ちました。しかし、独立した開発者として私が抱えている最大の問題は、今でも医療、産業、または単純なWebアプリ開発のために専門的な仕事を必要とする人々を訪ねるしかありません。GIS業界では、市場に参入する方法を見つけることはほとんど不可能です。


0

私はGISテクノロジーの完全な初心者であり、私が行くにつれて物事を理解しています。そして、私は資金が限られているため、ESRI製品の使用を避け、完全にオープンソースツールで作業を試みています。

つまり、私にとってこれまでで最も困難なことは、すべてデータの収集に関連してきました。データの操作と表示に関する記事がたくさんあり、生活を楽にするツールがたくさんあります。しかし、データを収集することになると、私は暗闇の中を歩いています。

専門家がデータを見つけて収集するために何をするのか分かりません。data.govやgoogleよりも簡単にデータを取得できる方法があることを教えてくれます。


ほとんどの場合、ベンダーから購入する必要があります。ベンダーは、実際の地上調査や他のソースからの変換を行います。第三世界では、政府からの公然のデータを取得することは面倒くさです
Devdatta Tengshe

-1

ソフトウェア開発者に変換されたGISアナリストとの連携を余儀なくされるのは残念かもしれません。

有能なソフトウェア開発者がGISの概念を理解し、APIを通過させ、一般的にあまり助けを必要とせずに物事を理解することを期待するのは簡単です。同じことは、GISアナリストを採用し、ソフトウェア開発を手に入れることを期待する場合にも当てはまりません。

結果はせいぜい恥ずかしいです。悪い開発者と仕事をした経験がある場合があるなら、最悪のプログラマーが開発したどのコードよりも悪いコードだと想像してください。

あなたが働くかもしれないいくつかの会社がそれを得ない。


2
@emptyset:私は開発者になった地理学者です。私の結果はせいぜい「誇張」しているとは思わない。P: -私より多くの開発スキルをITのバックグラウンドを持って、他の同僚持っもちろんincluind理解とOOPの概念、データベースの概念とルールの使用などを、私はあなたの答えに反対
ジョージ・シルバ

1
@George:そして、あなたが別の言い方をしたと言っているのではなく、ただあなたがどれだけひどいことを知っていなければならない素晴らしい開発者であると指摘しているだけです。少なくとも私はしようとします。
ビンコヴサロビッチ

2
+1多くの場合、私は1人または複数のアナリストによって書かれたBig Ball of Mud en.wikipedia.org/wiki/Big_ball_of_mudで「バグを修正する」ように依頼さ れました。最悪のコードの一部は、最も優秀なアナリストによって作成されました。多くの場合、賢い人は単純さの美しさを理解できません。多くの場合、障害は管理にあります-アナリストはリファクタリングの価値を認識しているかもしれませんが、壊れていないコードの変更に時間を費やすことを正当化することはできません。
カーククイケンドール

3
当然ながら、GISの専門家として働くことを余儀なくされているソフトウェア開発者と仕事をするのに十分なほど残念かもしれません。私は、あらゆる分野の誰に対しても、GISを使用する際に物事を把握することを非常に警戒しています。私は、開発を模索アナリストだ、と私は完全に期待する-としたい -人々は私のコードの警戒します。GISでうまくやっていると思う開発者は、おそらくそうではありません。:-)
マットウィルキー

3
-1-間違いの可能性があり、やや不快感を与える非常に抜本的なステートメント。マット・Wは、上記のとおり、あなたは一般的に、より良い助けに非常に多くのより多くのリソースがあるので、あなたがコーディング学び、GISであるよりも、ベストプラクティスを実装する他の方法で回避よりもコーディングに来るGIS者を抱えている
dmbrubac

-1

GISがエンジニア、建築家、または科学コミュニティのみによって扱われていた初期の年を除き、GISの世界は一般ユーザー向けに拡大されています。一般ユーザー向けにGISアプリを作成する場合、課題は、GISをより多くのテクノロジとして扱うテクノロジを適切に組み合わせることです(この場合、GISテクノロジを少し理解している開発者で十分です)。ただし、アプリが専門のコミュニティ向けに行われた場合、既存のアルゴリズムを検索して要求を満たすためにテクノロジーを結合する必要があるだけでなく、さらに複雑なため、これらのアルゴリズムを開発する必要があります。この場合、エンジニアと開発者のブレンドが労働者です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.