複雑なポリゴンを修正して、Googleマップで正しく表示するにはどうすればよいですか？

問題：壊れたポリゴンの形状を修正する方法を見つけようとしていますが、どうすればこれができるかわかりません。

詳細：

しばらく前にTIGERLINESから基本的にインポートしたポリゴンがいくつかあります。

それらをシェープファイルに変換してから、SQL Server 2008にインポートしました。

SQL Server 2008では、見栄えがいいです:)それは、インポートが多かれ少なかれ機能したことを示唆しています。これがロサンゼルスの街です：-

しかし、私のポリゴンには多くのポイントがあるため、REDUCEマップビューレベルがズームインされていない場合はそうです。だから、私の場合、縮小されたロサンゼルスをレンダリングしようとしています：-

驚くばかり！

これは、よく知られているテキスト形式としてのポリゴンです。

MULTIPOLYGON (((-118.37033296865027 33.981437119998084, -118.37005887887605 33.981578692036159, -118.37034101004039 33.981636093563019, -118.37033296865027 33.981437119998084)), ((-118.66815694082851 34.181234948814819, -118.62915309690062 34.14689902389253, -118.56475201393673 34.130168028388276, -118.5992039806748 34.074336925351339, -118.57039497030522 34.069345957209549, -118.56968692628638 33.988811006799452, -118.55134001501617 33.982488918901176, -118.49446792996977 34.050559988837591, -118.44342601159182 34.016625025023124, -118.53748592914029 33.96667393391462, -118.49898897162241 33.916299091437473, -118.43732802504242 33.91651401198633, -118.4580839734636 33.961275936767734, -118.42944687485486 33.916317947202252, -118.4287748805515 33.93096998019935, -118.36821587274666 33.92901995236047, -118.37033296865027 33.981437119998084, -118.38014006025271 33.976370879899918, -118.40620312831412 33.9894040312244, -118.40276798429554 34.003464906235209, -118.44721596021705 33.990835906868767, -118.36957705476188 34.035079980519519, -118.37898513570399 34.01930701338695, -118.35780514530173 33.997145063915781, -118.33148511073327 34.001491938133285, -118.37005887887605 33.981578692036159, -118.3177468750705 33.970922985911365, -118.31338700532739 33.93821409504941, -118.29159591706274 33.959494911587832, -118.29062400107088 33.866332991682327, -118.30914811626086 33.865608026065182, -118.30099998201904 33.757721074150069, -118.33305692619008 33.721861951611757, -118.29415704014427 33.704554033590789, -118.23180307928671 33.71500194765504, -118.24896594980441 33.755902076278147, -118.22066886552763 33.782536959833138, -118.22662214917852 33.829531051866013, -118.23026099256474 33.792772095531092, -118.2565120484562 33.804774040894074, -118.2991459834285 33.797795976339046, -118.29920702986115 33.846318895031622, -118.28155507034047 33.86280202135606, -118.28208595952513 33.923201066885447, -118.23032405030229 33.929000895691168, -118.23399502457268 33.953263926662473, -118.25364008888438 33.943276983800338, -118.25643608790811 33.989497954281944, -118.23791790420275 33.989393059909709, -118.23970793049459 34.014713121327667, -118.19142810960136 34.012760956499392, -118.19262502907846 34.061762066095284, -118.1648349431549 34.062282928139695, -118.15528996126079 34.098672108789643, -118.17799390878898 34.098595067874996, -118.16558689825808 34.125466989766352, -118.18258002511257 34.129185991443848, -118.18392009154192 34.148673011439996, -118.22623088187513 34.149788973944844, -118.25425797615566 34.11876096748162, -118.28169102368197 34.156473098182232, -118.30964606995528 34.1612589323332, -118.34566505636386 34.142366926730304, -118.37031291768209 34.196379107293332, -118.33992999453659 34.206502959021506, -118.33746198396433 34.221312054601036, -118.26687107795063 34.221846086487439, -118.26667204057179 34.250779088440183, -118.2387889442851 34.281588919772553, -118.28669401126965 34.278336948162604, -118.29939493959903 34.293259048809304, -118.35470798399948 34.278848025464875, -118.3857618914668 34.284817020858974, -118.38739588298223 34.298779939448842, -118.4061680961638 34.2859269071303, -118.40520195114632 34.329811005464386, -118.50380990538876 34.337305995327178, -118.54629607559784 34.317332026288142, -118.5408208870528 34.2988139356695, -118.58853302357504 34.303219086876425, -118.59620799129411 34.274520945225589, -118.63346111715893 34.269525030054467, -118.63072510622223 34.2377719451453, -118.65873494162602 34.224578011901244, -118.66815694082851 34.181234948814819), (-118.46636404681055 34.0590670662609, -118.45468090186466 34.066799004274742, -118.44817495570614 34.049578023438457, -118.46636404681055 34.0590670662609), (-118.42624590643248 34.083052060665487, -118.39585612350398 34.112414074702421, -118.39584401878872 34.091055026539784, -118.34338194827956 34.09432806847537, -118.37695090866218 34.088630040183155, -118.3702939050842 34.0801689603087, -118.39070402303155 34.072083071358719, -118.37224405760227 34.062199935390908, -118.40602306576152 34.052665897923667, -118.42624590643248 34.083052060665487), (-118.45592304445982 34.284612059955819, -118.43256891423674 34.304687007226292, -118.41566704665274 34.2939320092269, -118.4437338970905 34.273310001969548, -118.45592304445982 34.284612059955819), (-118.3623419482557 34.1386959352159, -118.34569798267972 34.14235601789391, -118.34877496666293 34.131385983468121, -118.3623419482557 34.1386959352159), (-118.46233312716733 33.979751022958048, -118.43225893050703 33.9750159246595, -118.4513010127346 33.964230958845896, -118.46233312716733 33.979751022958048)))

ここで、Googleマップにポリゴンを表示するには、SQL Serverからデータを抽出し、Googleマップ形式に変換してから表示する必要があります。これは、ポリスの95％に適しています。他の5％の外観は非常に混乱しています。

Not OKロサンゼルス：-

だから私はあなたが提案するつもりだと推測しています-> コードにバグがあるかどうかを確認しますか？コードを見ることができますか？それはコードで何かすることがあります！

さて、ここに私がCodeplexに置いたサンプルコードライブラリがあります。形状のバイナリデータを使用した単体テストが含まれています。（SELECT MediumReducedBoundary.STAsBinary() FROM Table WHERE Id=1）

それからParseこれをbyte[]..そしてGoogleマップに表示します。

私の変換コードは、1つではなく2つのポリゴンを返します。

これは、私のJsonがどのように見えるかです.. 2つのポリゴンを持っていることに注目してください。

クライアントサイドのJavaScriptコードをここに発見されました。これは私がjsonをデコードし、これを手動でGoogleマップにレンダリングしようとする場所です。

私は、jsonの結果を読み取って、このデータが悪いかどうかを教えてくれる方法/プログラムがあるかもしれないと思っています（間違って変換しました）。または、WKTを間違ってGoogle形式のJSONに変換した場所を誰かが確認できる場合はどうなりますか？

ポリゴンは、ゼロ巻きの塗りつぶしルールを使用するCanvasを使用してGoogle Maps APIでレンダリングされます。穴を表示するには、外側のパスと反対の巻線を使用して穴を定義する必要があります。

私には、Googleマップバージョンは元のソースと同じように穴を理解していないようです。Googleマップで穴がどのように定義されるかを調べる必要があります。

次へ進む前に各穴ポリゴンを閉じる必要のあるいくつかのポイントが欠落している可能性があります。Google Mapsがこれをどのように定義するのかわかりません。ただの推測です...