タグ付けされた質問 「api」

17
さまざまなJavaScriptマッピングライブラリを比較しますか?
私はWebベースのマッピングシステムに取り組んでおり、使用するライブラリを見つけようとしています。 利用可能なライブラリの比較へのリンクは次のとおりです。 Laurent Jegouのベンチマーク(2010年から)は、Webマッピングソリューション(クライアントとサーバーの両方)の世界的な展望です。 FOSSライブラリの比較ドイツカリージョを見つけることができるここに。 これまでのライブラリのリスト: グーグルマップ Microsoft Virtual Earth MapQuest リーフレット -「より小さく、より速く、より新しく、より簡単なコメントは、より少ない機能とより少ないテストとして読むこともできます。」-Geographika(以下を参照) ArcGIS API for JavaScript -ArcGIS Serverで最適に動作します(以下を参照)。GoogleマップとBingマップの拡張機能も利用でき、Google / BingマップでESRI APIを使用できます(ただし、これはほとんどのライブラリに当てはまります)。 Yahoo Map APIの ミシュラン経由 OpenLayers-豊富なドキュメントと豊富な機能に加えて、さまざまなマッププロバイダーを使用する機能。 Mapquery -MapQueryがリリースされ、いくつかの有用なドキュメントが追加されました。OpenLayers とjQueryを組み合わせるという非常に価値のある目標があります。OpenLayers + jQueryのアイデアに特に熱心な場合、またはJavaScriptマッピングライブラリに貢献したい場合は、参加して努力を貢献してください。ただし、単にエンドユーザーになりたい場合、またはこの分野に慣れていない場合は、あなたには向かないかもしれません。 Mapstraction-特に複数のベースマッププロバイダーでの作業を非常に簡単にします。しかし、それはまだ進行中の作業であり、ドキュメントのように機能が場所に欠けています。(たとえば、「FeatureCollection」タイプのGeoJSONオブジェクトは、フィーチャコレクションオブジェクトです。)あまり有益ではないようです。 1月から。 deCarta-モバイルおよびデスクトップjavascriptがあります-最初はHTML5 / CSS3に準拠し、2番目はより多くのブラウザー互換性があります。ソースコードが提供されました。商用APIの開発者にとって最も使いやすい用語。マップのブランド化が許可されており、いくつかの異なるマップスタイルがあります。NAVTEQまたはOSMデータを選択できます。また、いくつかのモバイルAPIもあります。-TheSteve0による編集-deCartaの従業員 クラウドメイド ポリマップ -さまざまなソースからのラスターデータとベクターデータを非常に簡単に合成できます。独自のカラーリング、グループ化、インタラクションを簡単に追加できます。迅速に実行され、バックグラウンドタイルの読み込みを適切に管理し、わずか30kのJavascriptです。潜在的なマイナス面の1つは、MSIE 7または8で動作しないSVGを使用することです。他のすべてのブラウザで動作し、IE9で動作するはずです。 ジャンプ -ジャンプは、独自に機能する軽量のマップライブラリです。つまり、OpenLayersまたはGoogleMaps APIのラッパーではありません。現在、開発中ですが、多くの重要な機能がうまく機能しています。 ModestMaps -MapboxおよびTileMillのメーカーが提供する、より小さく、高速で、新しいJSマッピングライブラリ。 マピエーター OpenLayersは私が現在使用しているものです。それで多くのことができ、ほとんどのデータ型をサポートします。ただし、すべてに最適というわけではありません。たとえば、リーフレットは、画像のフェードおよびその他の視覚的な調整により、多くの点でよりスムーズに見えます。jQueryに興味がある場合は、jQueryとOpenLayersの組み合わせのようなMapQueryをチェックしてみてください。

8
OpenLayersまたはLeafletを選択しますか?[閉まっている]
OpenLayers v / s Leafletの同僚の1人と議論していました。GeoserverとPostGISに直接接続する必要があるプロジェクトを構築する場合、OpenLayersははるかに優れたAPIであると指摘しました。 次に、Open Data Kitを見つけました。これはかなり新しく見えますが、GeoserverおよびPostGISとの接続機能を備えています。 私のプロジェクトの詳細は次のとおりです。 マップインターフェイスを使用して、フィーチャ情報を取得します ユーザーが地図上でクリックした場所に関する緯度経度を取得し、ラスタから気候データを取得するカスタマイズされたツールを作成します(サーバー上のpyスクリプトによって処理されます)。 ユーザーがExcelをアップロードできるようにします。Excelはpyスクリプトに送信され、GeoJSONが返され、マップ上にベクターフィーチャが作成されます ユーザーがベクターポリゴンを作成できるようにします。ベクターポリゴンは、交差するフィーチャをWFSレイヤーから取得します。 GeoServer上のPostGISデータストアからレイヤーを取得し、マップ上にレイヤーを表示します。 だから今、私はどちらが優れているのか、そしてリーフレット上でOpenLayersを使用することがより理にかなっているのか混乱していますか?

2
地理的データがantimeridianに及ぶデータベースおよびAPIのベストプラクティス
地理的特徴(ライン、ポリゴン、およびそれらの同等のマルチパート)がantimeridian(±180°経度)にまたがり、GeoJSONとしてクライアントWebアプリケーションに送信および受信する必要がある場合、それらを保存するためのベストプラクティスは何ですか? 私は、Postgres / PostGISデータベースのサポートを受けて、サーバー側のWeb APIで作業を開始し、熱帯低気圧の履歴と風の半径を予測します。太平洋の多くのサイクロンは、時には寿命の間に複数回、反時計回りを通過する不幸な傾向があります。 ニュージーランドのアンティリディアンの近くに住んでいる私は、地域のデータでこの問題に何度も対処し、対処戦略を立てましたが、実際にベストプラクティスと考えられるものを見つけたいと思います。残念ながら、antimeridianでタグ付けされた既存の質問はないため、関連する質問を検索するのは困難です。私がこの問題に苦労しているのを見た質問はすべて、非常にアプリケーション固有のアドバイスを求めているようです。この質問では、境界のない地球に広がるGeoJSONポリゴンの場合の反時計回りについて簡単に説明します。この質問は、私が尋ねていることにかなり近いものです。 空間的データベースに歴史的サイクロンと予測サイクロンを保存する必要がありますが、反時計回りに問題があると予想しています。たとえば、緯度/経度(0,179)で始まり、で終わる線(0,-179)は、その方向に関してあいまいです。それは、反時計回りを横切る短い経路を取るか、惑星全体を「包む」かです。このようなパスを空間データベースにどのように保存する必要がありますか(具体的には私はPostGISを使用していますが、ソリューションが十分に汎用的であることを望みます)。私が持っているいくつかのアイデア: フィーチャジオメトリに変更を加えず、クライアントアプリケーションへの曖昧さをシフトします。 antimeridianを横切るフィーチャを、antimeridianでブレークするマルチパートジオメトリに分割します。(GeoJSON仕様は名前付きCRSをサポートしています。) 仕事以外のグローバル予測などの不連続を持っていない別のサイクロン流域や海洋地域のために サイクロンが惑星全体を巡回することが一度も観察されていないという事実を利用して(90,-90) 、360°の位相でオフセットされた緯度範囲から始まるサイクロンの座標を保存します(他の-180-180°を維持) サイクロンがアフリカの南端の南にある可能性が非常に低いという事実を利用して、経度30°でブレークを使用します(上記のマップのように)。 座標がEPSG 4326の有効範囲を超えて拡張できるようにします。たとえば、反時計回りを通過するすべてのフィーチャに対して、180度以上-180度未満です。 TopoJSONと同様に、デルタエンコーディング(例:で始まり(0,-179)、次の座標は-3緯度西です)。PostGISにデータを保存するときにこれを実装するかどうか、または実装する方法がわかりませんが、これはクライアントアプリケーションにデータを送信するための優れたソリューションです。 何らかの形式のベクトル表記または極座標。(かなり難しくて珍しいようです。) これらのうち、アイデア2〜5は一般的なものではないので好きではありませんが、私の特定のアプリケーションにとって意味があるので好きです。太平洋のデータのみを処理するアプリケーションの場合、それらは非常に理にかなっている可能性があるため、オプションとして完全に割引したくはありません。 アイデア6および7は、Tom MacWrightのブログから取り上げられました。このブログは読む価値はありますが、反時計回りに関しては決定的なものではありません。 アイデア4はGeographicaGS 'GeodesicLinesToGISPythonによって使用されfiona.transform.transform_geom、360°の反時計回りオフセットで使用されています。次に、FionaはOGRを使用してい-wrapdatelineます。これは非常に堅実な先例であり、実際にはかなり一般的だと思います。 ストレージの問題に関連して、そのような機能をクライアントアプリケーションに送信する方法、およびアプリケーションがそこにポストバックされるデータを考慮する方法を検討する必要があります(たとえば、太平洋のサイクロンの予測トラックを変更する人間予報士)。交換形式はおそらくGeoJSONになりますが、そうである必要はありません。 残念ながら、GeoJSON仕様は、反時計回りの問題について明示的ではありません。ウィキペディアからこれ: 多くの地理的ソフトウェアライブラリまたはデータ形式は、世界を長方形に投影します。多くの場合、この長方形は180番目の子午線で正確に分割されます。これにより、180番目の子午線上で単純なタスク(エリアやラインを表すなど)を実行できなくなることがよくあります。いくつかの例: GeoJSON仕様では、仕様で180番目の子午線の処理に言及していないため、180番目の子午線を横切る線の表現は、世界中を回っていると解釈できます。 OpenStreetMapでは、領域(ロシアの境界など)は180番目の子午線で分割されます。 私の読書では、GeoJSONには反時計回りに広がる特徴の特定の標準表現はなく、意図的に曖昧なままになっています(マルチパートジオメトリによって問題が解決される可能性があります)。同様に、OpenStreetMapにはantimeridianにジオメトリ分割がありますが、そのような分割されたフィーチャがマルチパートであるか、実際に個別のレコードであるかはわかりません。 これは、特にバウンディングボックスまたはこの行にまたがる他の空間要求を作成するという観点からだけでなく、入力の解析とサニタイズおよびフィーチャジオメトリの更新においても、かなり問題があります。これが、私が従うことができるベストプラクティスを決定しようとしている理由です。

6
ジオコーディングAPIの比較
既存のGeocoding API(Google、Mapquestなど)とその機能を比較するための適切な更新されたソースはありますか? 彼らの言語サポートにもとても興味があります。たとえば、Googleには、JavaScript、Java、Pythonなどのジオコーディングサービス用のライブラリがあります。

6
Google Earthプラグインは廃止されました。どの選択肢ですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉まっている 3年前にました。 私は、Google Earthプラグインを彼のWebサイトに統合するように依頼しました。 Google Earthプラグインサイトからこれを読みました。 Google EarthプラグインAPIは、2014年12月12日をもって廃止されました。APIは、2015年12月12日までサポートされているブラウザで引き続き動作し、その日までシャットダウンします。 どのような選択肢がありますか? Google Maps API、Google Maps Engine API、Google Street View APIがあることは知っていますが、それらとGoogle Earthプラグインを「代替」できるものについて混乱しています。 必要な機能は次のとおりです。重要度の高い順に示します。 サテライトビューでKMZファイルを読み込む KMZファイルエンティティに存在するHTMLデータを含むバルーンを表示します。htmlにはストリートビューへのリンクが含まれます。バルーン内でストリートビューを有効にしたいと思います。Google Earthでなんとかできました。 衛星画像履歴画像セレクター 測定ツール クリックされたポイントのアドレスを取得します(geocooding) 3Dの建物

3
APIを使用してセンチネル製品をダウンロードしますか?
Sentinelデータ(特にS2)を自動化または一括ダウンロードできるようにしたい。 APIとバッチスクリプトに関するSentinels Scientific Data Hubユーザーガイドに記載されているODataプロトコルを使用しようとしています。例として、wgetを使用して完全な製品をダウンロードしようとします。 wget --no-check-certificate --user=username --password=usrpass "https://scihub.copernicus.eu/apihub/odata/v1/Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')/$value" (登録されたユーザー名とパスワードを使用して)しかし、index.htmlを受け取っただけです。 <?xml version='1.0' encoding='utf-8'?><entry xmlns="http://www.w3.org/2005/Atom" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xml:base="https://scihub.copernicus.eu/dhus/odata/v1/"><id>https://scihub.copernicus.eu/dhus/odata/v1/Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')</id><title type="text">S1A_IW_SLC__1SDV_20141023T172123_20141023T172150_002960_0035D1_9743</title><updated>2014-12-07T17:06:00.324Z</updated><category term="DHuS.Product" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/><link href="Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')" rel="edit" title="Product"/><link href="Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')/$value" rel="edit-media" type="application/octet-stream"/><link href="Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')/Products" rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Products" title="Products" type="application/atom+xml;type=feed"/><link href="Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')/Nodes" rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Nodes" title="Nodes" type="application/atom+xml;type=feed"/><link href="Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')/Attributes" rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Attributes" title="Attributes" type="application/atom+xml;type=feed"/><link href="Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')/Class" rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Class" title="Class" type="application/atom+xml;type=entry"/><content type="application/octet-stream" src="Products('18f7993d-eae1-4f7f-9d81-d7cf19c18378')/$value"/><m:properties><d:Id>18f7993d-eae1-4f7f-9d81-d7cf19c18378</d:Id><d:Name>S1A_IW_SLC__1SDV_20141023T172123_20141023T172150_002960_0035D1_9743</d:Name><d:ContentType>application/octet-stream</d:ContentType><d:ContentLength>8544532822</d:ContentLength><d:ChildrenNumber>2</d:ChildrenNumber><d:Value m:null="true"/><d:CreationDate>2014-12-07T17:06:00.324</d:CreationDate><d:IngestionDate>2014-12-07T17:06:00.324</d:IngestionDate><d:EvictionDate m:null="true"/><d:ContentDate m:type="DHuS.TimeRange"><d:Start>2014-10-23T17:21:23.23</d:Start><d:End>2014-10-23T17:21:50.495</d:End></d:ContentDate><d:Checksum m:type="DHuS.Checksum"><d:Algorithm>MD5</d:Algorithm><d:Value>C4415763B3198B7A2874C2A60B2CDCDC</d:Value></d:Checksum><d:ContentGeometry><gml:Polygon srsName="http://www.opengis.net/gml/srs/epsg.xml#4326" ...

1
ArcSDE APIは何に使用されますか?
ArcObjectsを操作するアプリケーションを作成するには、VBAおよびJavaランタイムがあります。ArcToolboxツールでデータを処理するアプリケーションを作成するために、ArcPy for Pythonがあります。 今日、ArcSDEにはCおよびJava APIがあることがわかりました。ArcSDE APIの目的は何ですか?それらはArcSDEコマンドラインとまったく同じ機能を提供しますか? 他にArcGIS APIはありますか?

2
空間データ用のAPIの設計
一部の空間データセットを同僚が分析のために利用できるようにするために、APIを作成することを検討しています。 私の仕事の一部は、他の人がさらに分析するために使用できるデータを分析および準備することでした。作業(現在は小規模で洗練されていない)はwalkscoreに似ていますが、いくつかの巨大なデータセットが関係しています。元のデータを共有する方法に制限が増えていますが、私の派生物は共有できます。私は(大規模なデータセットを渡す以外に)分析の結果を共有するための最良の方法について考えており、APIが1つのアプローチになると考えていました。APIを構築する場合、どのようなことを考慮すべきですか?従うことができる設計仕様はありますか? 私のビジョンは現在よりも少し壮大に聞こえますが、この作業の早い段階で検討することは有用なフレームワークになると思います。
10 data  api 

1
ArcGIS Engineを使用したカスタムパン
いくつかの制約のため、ここでは説明しませんが、アプリケーションにカスタムパンを実装する必要があることに気づきました。 ArcGIS APIリファレンスでは、次のメソッドの使用を推奨しています。 IScreenDisplay2.PanStart(IPoint start) // Starts a pan IScreenDisplay2.PanMoveTo(IPoint moveTo) // Moves to a point IScreenDisplay2.PanEnd() // Ends the pan これらの各メソッドは、次のイベントハンドラーで(それぞれ)呼び出されます。 IMapControl4.OnMouseDown // Call PanStart() IMapControl4.OnMouseMove // Call PanMoveTo() IMapControl4.OnMouseUp // Call PanEnd() つまり、すべてがうまく機能し、イベントが処理され、パンが始まり、みんなが幸せです。 -だが- 画面が実際にパンする場所は、カーソルをドラッグした場所ではありません。マップはやや確定的なパターンで動き回りますが、APIが何をしているかを補正する方法がわかりません。私は啓発的なドキュメントを見つけることができませんでした。 誰かがAPIのこの部分の経験がありますか?サンプルコードやドキュメントは素晴らしいです!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.