問題タブ [sqlgeography]

を使用しようとしてかなりの問題が発生しましたMicrosoft.SqlServer.Types.SqlGeography。私は、Linq to Sql でのこれに対するサポートが優れていないことをよく知っています。私は、期待される方法（データベースの種類geography、CLRの種類SqlGeography）から始めて、さまざまな方法を試しました。これにより、NotSupportedExceptionブログで広く議論されている が生成されます。

次に、バイナリとして格納されたUDTと同様に、geography列を として扱う道をたどりました。これは正常に動作するようです (いくつかのバイナリ読み取りおよび書き込み拡張メソッドを使用)。varbinary(max)geography

しかし、私は今、かなりあいまいな問題に直面しています。これは、他の多くの人には起こらなかったようです。

System.InvalidCastException: タイプ 'Microsoft.SqlServer.Types.SqlGeography' のオブジェクトをタイプ 'System.Byte[]' にキャストできません。

ObjectMaterializerこのエラーは、クエリを反復処理するときにスローされます。地理列を含むテーブルが暗黙的にクエリに含まれている場合にのみ発生するようです (つまり、EntityRef<>プロパティを使用して結合を行います)。

System.Data.Linq.SqlClient.ObjectReaderCompiler.ObjectReader`2.MoveNext()

私の質問:geography列を として取得している場合、逆のエラーが発生する可能性があります: にキャストできvarbinary(max)ません。それは私が理解するでしょう。これは私はしません。バイナリ変換を隠す部分的な LINQ to SQL クラスにいくつかのプロパティがあります...それらが問題になる可能性がありますか?byte[]SqlGeography

助けていただければ幸いです。おそらく十分な情報がないことは承知しています。

エクストラ:

• geography'Server Data Type' = の Visual Studio dbml Designerの列で、次のgeographyエラーが生成されます。The specified type 'geography' is not a valid provider type.
• 'Server Data Type' のない Visual Studio dbml Designerのgeography列は、次のエラーを生成します。Could not format node 'Value' for execution as SQL.

GeographyCollection から 'holes'/linestrings/.etc を削除するにはどうすればよいですか? 次に、交差しない MPolygon を 1 つのポリゴンに結合するにはどうすればよいですか?

地理マップへの郵便番号のロールアップがありますが、形状に穴があります。あれこれ調べたのですが、内側の穴を取り除く良い方法が見つかりませんでした。

ConvexHull は、実際には私たちが望んでいるものではないファンキーな形状を作成します。目標は、地域を「ぴったり合わせる」ことで、地図上で人間が見ることができるようにすることです。

.Reduce は役立ちますが、すべてを削除するわけではありません。私は本当に、2つのポリゴンが隣り合っている場合にのみ発生する、細かい（小さい）ConvexHullを持つ外側のエンベロープが欲しいだけです。

考え？リダイレクト？

デザイナにテーブルをロードする際にいくつか問題が発生します。次のエラーが発生します。

選択した1つ以上のアイテムに、デザイナーがサポートしていないデータ型が含まれています

このエラーの原因は、テーブルで使用されている地理タイプであると想定して正しいでしょうか？

どんなポインタでも大歓迎です。

Silverlightで動作するMicrosoft.SqlServer.Types.SqlGeographyの代替品を探しています。私は主に、データの任意のコレクション（ポイント、パス、またはポリゴン）と、STBuffer、STUnion、およびSTIntersectの機能に関心があります。

中間層のWCFを介してデータベースから地理データを取得し、それをSilverlightクライアントに返して、そこで地理空間データを操作させる必要があります。Microsoft.SqlServer.Types.SqlGeographyタイプでこれを実行できると誤って信じていました。残念ながら、管理されていないコードが含まれており、WCFを介してシリアル化されません。

lat / longを他の形式にエンコードするだけではなく、誰かが以前にこれを行ったことがあることを願っています。重要なのは、データをクライアントに返すときにデータに対して操作を実行する必要があり、これを実行するためのアルゴリズムの実装に対処したくないということです。

KMLをSqlGeography（SQLServer DataType）に変換する関数またはDLLを持っている人はいますか？

必要に応じて自分で書きますが、見つからないのでびっくりしました。

全世界の地理的ポイント（long、lat）を記録する必要があるテーブルがあります。入力データは、従来の縦方向および緯度方向（-180、-90、180、90）です。

地理列を作成し、インデックスを作成したいと思います。ただし、多くのオプションがあり、MSDNはベストプラクティスを示していません。次の質問があります。

1. グリッドには、GRIDS =（LEVEL_1 = HIGH、LEVEL_2 = HIGH、LEVEL_3 = HIGH、LEVEL_4 = HIGH）が最適だと思います。これにより、緯度≈611.5mで可能な最大解像度が作成されます。他のオプションの例を見てきました。何が一番いいですか？
2. ポイントのみを記録しているので、CELLS_PER_OBJECT = 1が正しいと思いますか？
3. GEOGRAPHY_GRIDのxとyの最小から最大の範囲はどれくらいですか？＃4を参照してください。
4. 上記の＃3を参照すると、グリッドを適切に使用するために、従来の縦方向および緯度方向（-180、-90、180、90）のデータをGEOGRAPHY_GRIDが使用する範囲に変換する必要がありますか？

SQL Server 2008 に次のようなテーブルがあります。

ISELECT * FROM this_tableの場合、マップ上のポイントのような空間結果を自動的に取得します。

私が取得したいのはまったく同じですが、serv_type列に基づいてポイントが色付けされています。つまり、同じ「マップ」が必要ですが、すべてのレストランは青で、すべてのショップは赤である必要があります。

SQL Server でこれを行うことは可能ですか? ありがとう。

私は最近地理データ型を試していて、とても気に入っています。しかし、緯度と経度を 2 つの別々の数値 (9,5) フィールドに格納する現在のスキーマから地理型に変換する必要があるかどうかを判断できません。両方のタイプのサイズを計算しましたが、地理タイプが 26 であるのに対し、ポイントを表す緯度/経度の方法は 1 つのポイントで 28 バイトです。スペースの大きな増加ではありませんが、地理空間操作 (交差、距離測定など) の実行が大幅に改善されます。 ) これらは現在、厄介なストアド プロシージャとスカラー関数を使用して処理されています。気になるのは指数です。geography データ型では、データのインデックス作成により多くの領域が必要になりますか? 列に格納されている実際のデータは少なくても、地理空間インデックスが機能する方法により、最終的にはより大きなスペースが割り当てられると思います。

PS として、SQL Server 2008 (R2 ではない) は、WITH(INDEX()) 句を使用するように明示的に指示されない限り、地理空間インデックスを自動的にシークしないようです。

何年も問題なく実行されているアプリケーションがあります。最近、アプリケーションが使用するテーブルの 1 つに地理タイプの列を追加することにしました。その後、本番サーバーの Web サイトが動作し始めました。テーブルが使用された場所で奇妙な null 参照例外が発生しました。しかし、もっと重要なことは、サイトが私の開発マシンで問題なく動作したことです。私が行った唯一の変更は、テーブルに列を追加することであることに注意してください。DAL または BBL では何も変更されていません。データ アクセス層は、ADO.NED を使用して記述されます。開発マシンと運用サーバーの唯一の実際の違いは、マシンに SQL Server 2008 R2 がインストールされていることです。しかし、これが原因でアプリケーション エラーが発生した理由はまだわかりません。SELECT ステートメントから geography 列を無視すると、コードは正常に動作し、しかし、ストアド プロシージャもこの列を返すとすぐに、コードは機能しなくなります。DataSet が Geography タイプのデータの処理方法を認識していない可能性はありますか?

どんな洞察も高く評価されます。

別の場所から指定された距離内にある場所を照会しようとしています。クエリは問題ではありませんが、geography.STDistance によって返される距離は問題です。

STDistance赤道に近い場所ではかなり正確な計算ができるようですが、北欧諸国の場所で作業するにはこれが必要です。ノルウェー、スウェーデン、フィンランドなど...

私の計算によると、スウェーデン北部の場所で、距離は約 2.38 倍間違っています?! 期待される結果は 1070 メートルで、返される距離は 2537,28850694302 メートルです

私のクエリは次のようになります。

「他の場所」の座標は (65,578541 22,202286) (SRID 4326 で保存)

これは赤道からの距離 (極円に近い) に関係していると推測していますが、緯度に基づいてこれをより正確に計算する方法が必要ですか、それとも間違っていますか?