O Que Está Dentro: Quando Esri + Clementini = Usuário Cuidado

JoshuaBixby

<\/HEAD>

Esta é a segunda parte de uma série em dois capítulos sobre os riscos para usuários de software devido à documentação deficiente; especificamente, a confusão e resultados inesperados que surgem de operadores espaciais mal documentados em software GIS.  A primeira parte da série <\/A>analisa como a documentação inconsistente e incompleta obriga os usuários a adivinharem como os operadores espaciais são implementados.  A segunda parte da série<\/STRONG> examina os resultados inconsistentes que surgem da mistura de diferentes implementações de operadores espaciais.<\/EM><\/P><\/P>Um dos muitos bugs de geometria vazia que enviei recentemente ganhou prioridade esta semana quando notei que a Esri atualizou o status para "Fechado:  Não Será Corrigido."  O que se seguiu foi uma discussão ainda em andamento sobre comportamento esperado versus resultados inesperados.  Coincidentemente, a questão pode ser enquadrada perfeitamente dentro da discussão e exemplos do primeiro post desta série (O Que Está Dentro:  Quando (Esri != Clementini) = ?<\/A>).<\/P>

<\/P>

O primeiro post desta série discutiu como não existe uma definição única de relações espaciais para bibliotecas de geometria e aplicações geoespaciais, e como o Modelo de Interseção 9 Estendido Dimensionalmente (DE-9IM) tornou-se a definição 2D predominante após sua inclusão na

Especificação de Implementação OpenGIS para Informação Geográfica - Acesso a feição simples - Parte 1: Arquitetura comum<\/A>.  O post focou em como a documentação incompleta dos operadores espaciais força os usuários a adivinharem, e provavelmente incorretamente às vezes, como o software funciona ao invés de saber como o software deveria funcionar.  Por mais infeliz que seja para os usuários a documentação incompleta, misturar diferentes definições de relações espaciais dentro do mesmo operador espacial é muito pior, e isso parece ser o que a Esri fez.<\/P>

<\/P>

Tomando emprestado os exemplos do post anterior, vamos olhar três feições e o método ArcPy Geometry.within()<\/SPAN>.<\/P><\/P>>>> #Criar polígono quadrado
>>> polygon = arcpy.FromWKT('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))')
>>> #Criar linha que está completamente na borda do polígono
>>> line = arcpy.FromWKT('LINESTRING(1 0, 2 0)')
>>> #Criar linha vazia
>>> line_empty = arcpy.FromWKT('LINESTRING EMPTY')
>>>
>>> #Testar se linha está dentro do polígono
>>> line.within(polygon)
False
>>> #Testar se linha_vazia está dentro do polígono
>>> line_empty.within(polygon)
True<\/PRE><\/P>Para fins comparativos, vamos executar os mesmos dois testes das Linhas 9 e 12 usando ST_Geometry da Esri no Oracle:<\/P><\/P>SQL> --Testar se linha está dentro do polígono
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'
--------------------------------------------------------------------------------
                                                              0
SQL> --Testar se linha_vazia está dentro do polígono
SQL> SELECT sde.st_within(sde.st_geomfromtext('LINESTRING EMPTY', 0),
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . & nbsp ; 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'
--------------------------------------------------------------------------------
 . & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; & nbsp ; 0<\/PRE><\/P>Interessante, os resultados usando ST_Geometry diferem dos usando ArcPy.&#160; Sabendo que as funções ST_Geometry são compatíveis com OGC simple feature access e SQL, o que significa que implementam DE-9IM, os resultados do ST_Geometry no Oracle são esperados porque uma linha somente na borda de um polígono não é considerada dentro do polígono, e uma geometria vazia não pode estar dentro de outra geometria.<\/P><\/P>Ao olhar para os resultados do ArcPy, a Linha 10 está correta apenas<\/SPAN> se as

Classes de Geometria ArcPy <\/A>implementarem a definição de Clementini já que vimos no primeiro post desta série que a definição da Esri para Within é Verdadeira nesta situação.&#160; Infelizmente, a documentação do ArcPy não especifica qual definição está implementando.&#160; O resultado na Linha 13 está correto apenas<\/SPAN> se as Classes de Geometria ArcPy <\/A>implementarem a definição da Esri porque a definição de Clementini não permite que uma geometria vazia esteja dentro de outra geometria.&#160; Claro como lama, certo?<\/P>

<\/P>

A posição da Esri até agora é que tudo está funcionando conforme projetado.&#160; O quê?!&#160; Se for esse o caso, a Esri está implicitamente reconhecendo que está implementando definições diferentes de uma relação espacial dentro do mesmo operador espacial, depende apenas das geometrias que você passar!!&#160; Entre o código fechado, documentação incompleta e implementação aparentemente arbitrária; as Classes de Geometria ArcPy são usadas por sua conta e risco.&#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.