What's Within: Esri + Clementini = ユーザー注意報

JoshuaBixby

<\/HEAD>

これは、ドキュメント不備によるソフトウェアユーザーのリスクに関する2部構成シリーズの第2部です。具体的には、GISソフトウェアにおける空間演算子の弱いドキュメントから生じる混乱と予期しない結果についてです。  シリーズの第1部<\/A>では、不完全かつ一貫性のないドキュメントがユーザーに空間演算子の実装方法を推測させる必要があることを取り上げました。  シリーズの第2部<\/STRONG>では、異なる実装の空間演算子を混在させた場合に生じる一貫性のない結果について検討します。<\/EM><\/P><\/P>最近私が提出した多くの空ジオメトリバグのうちの1つが今週急浮上しました。Esriがステータスを「Closed:  Will Not be Addressed.」に更新したことに気づいたためです。  その後、期待される動作と予期しない結果について現在も議論が続いています。  偶然にも、この問題はこのシリーズの最初の記事(What's Within:  When (Esri != Clementini) = ?<\/A>)の議論と例でうまく整理できます。<\/P>

<\/P>

このシリーズの最初の記事では、ジオメトリライブラリや地理空間アプリケーションにおける空間関係の単一定義は存在せず、Dimensionally Extended 9 Intersection Model (DE-9IM) が

OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture<\/A>に含まれたことで主流の2D定義となったことを説明しました。  記事は、空間演算子の不完全なドキュメントがユーザーにソフトウェアの動作を推測させ、時には誤った理解を招くことに焦点を当てました。  不完全なドキュメントがユーザーにとって不幸である一方で、同じ空間演算子内で異なる空間関係定義を混在させることはさらに悪く、それがEsriが行ったことのように見えます。<\/P>

<\/P>

前回の記事の例を借りて、3つのフィーチャとArcPy Geometry.within()<\/SPAN> メソッドを見てみましょう。<\/P><\/P>>>> #正方形ポリゴンを作成
>>> polygon = arcpy.FromWKT('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))')
>>> #ポリゴン境界上に完全に位置するラインを作成
>>> line = arcpy.FromWKT('LINESTRING(1 0, 2 0)')
>>> #空のラインを作成
>>> line_empty = arcpy.FromWKT('LINESTRING EMPTY')
>>>
>>> #ラインがポリゴン内かテスト
>>> line.within(polygon)
False
>>> #空ラインがポリゴン内かテスト
>>> line_empty.within(polygon)
True<\/PRE><\/P>比較目的で、Oracle上でEsriのST_Geometryを使って同じ9行目と12行目のテストを実行してみましょう:<\/P><\/P>SQL> --ラインがポリゴン内かテスト
SQL> SELECT sde.st_within(sde.st_geomfromtext('LINESTRING(1 0, 2 0)', 0),
                          sde.st_geomfromtext('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))', 0))
       FROM dual;
SDE.ST_WITHIN(SDE.ST_GEOMFROMTEXT('LINESTRING(10,20)',0),SDE.ST_GEOMFROMTEXT('PO'
--------------------------------------------------------------------------------
                                                                
SQL> --空ラインがポリゴン内かテスト
SQL> SELECT sde.st_within(sde.st_geomfromtext('LINESTRING EMPTY', 0),
 sde.st_geomfromtext('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))', 0))
  FROM dual;
SDE.ST_WITHIN(SDE.ST_GEOMFROMTEXT('LINESTRINGEMPTY',0),SDE.ST_GEOMFROMTEXT('POLY'
--------------------------------------------------------------------------------
                      <\/P>興味深いことに、ST_Geometryを使った結果はArcPyとは異なります。&#160;ST_Geometry関数はOGC simple feature accessおよびSQL準拠であり、つまりDE-9IMを実装しているため、Oracle上でST_Geometryから得られる結果は予想通りです。ポリゴン境界上のみのラインはポリゴン内とは見なされず、空ジオメトリは他のジオメトリ内には存在できません。<\/P><\/P>ArcPy結果を見ると、10行目は

ArcPy Geometry Classes<\/A>がClementini定義を実装している場合のみ正しいです。このシリーズ最初の記事で見たように、この状況下でEsriのWithin定義はTrueとなります。残念ながらArcPyドキュメントはどちらの定義を実装しているか明示していません。13行目の結果はArcPy Geometry Classes<\/A>がEsri定義を実装している場合のみ正しく、Clementini定義では空ジオメトリが他ジオメトリ内にあることは許されません。非常にわかりづらいですね？<\/P>

<\/P>

Esriの立場は現時点で「すべて設計通りに動作している」というものです。なんと？！もしそうならば、Esriは暗黙的に同じ空間演算子内で異なる空間関係定義を実装していることを認めていることになり、それは渡すジオメトリ次第ということになります！！クローズドソースコード、不完全なドキュメント、および恣意的と思われる実装から判断すると、ArcPy Geometry Classesは自己責任で使用してください。&#160;Caveat utilitor<\/EM>.<\/P><\/BODY><\/HTML>

VinceAngelo

I think the risk is assuming Clementini operators exist where no mention of "Clementini" is found.  Esri has supported a WITHIN operator since long before the Clementini paper was written. 

The creation of SDE (at 3.0) provided a new opportunity to implement a spatial operators library, and Clementini was chosen to be the basis of that library. SDE.ST_GEOMETRY was implemented using that library, and OpenGIS adopted Clementini (probably at Esri's suggestion, though I'm not certain of that). I've got a copy of the Clementini paper (actually, I have several, one in each boot partition of every system I manage), and I use it to check for defects and cross-check for desired functionality, but the average user is not going to want a 2-hour lecture on geometry algebra (and another on geometry calculus) before using a theme-on-theme query tool.

Choosing to break existing functionality on upgrade is a dangerous endeavor.  The rules become even more slippery when additional functionality is added.  And Clementini treats a number of common topological relationships as multiple discrete cases, which would have removed functionality.  So, yes, there are multiple geometric relationship libraries within Esri code.  When you add in the absurdity of having an "empty line" discrete from an "empty point" and don't support a true "Nil" (which is a feature of WKT), then you've also got multiple conflicting standards to address. And that means that yes, there are multiple possible oddities when asking a computer to answer a nonsensical Boolean question.  Personally, I would return FALSE to all Boolean questions outside of defined behavior, but because it is undefined, any outcome, including a division by zero exception would be technically correct.