Qué hay dentro: Cuando Esri + Clementini = Usuario Precavido

JoshuaBixby

<\/HEAD>

Esta es la segunda parte de una serie en dos partes sobre los riesgos para los usuarios de software debido a la mala documentación; específicamente, la confusión y resultados inesperados que provienen de operadores espaciales débilmente documentados en el software GIS.  La primera parte de la serie <\/A>analiza cómo la documentación inconsistente e incompleta obliga a los usuarios a adivinar cómo se implementan los operadores espaciales.  La segunda parte de la serie<\/STRONG> examina los resultados inconsistentes que surgen al mezclar diferentes implementaciones de operadores espaciales.<\/EM><\/P><\/P>Uno de los muchos errores de geometría vacía que he reportado recientemente se puso en primer plano esta semana cuando noté que Esri actualizó el estado a "Cerrado:  No será atendido."  Lo que ha seguido es una discusión que aún se está desarrollando sobre el comportamiento esperado versus resultados inesperados.  Coincidentemente, el problema puede enmarcarse claramente dentro de la discusión y ejemplos del primer post de esta serie (Qué hay dentro:  Cuando (Esri != Clementini) = ?<\/A>).<\/P>

<\/P>

El primer post de esta serie discutió cómo no existe una definición única de relaciones espaciales para bibliotecas de geometría y aplicaciones geoespaciales, y cómo el Modelo de Intersección Extendida Dimensionalmente 9 (DE-9IM) se convirtió en la definición 2D predominante tras su inclusión en la

Especificación de Implementación OpenGIS para información geográfica - Acceso simple a características - Parte 1: Arquitectura común<\/A>.  El post se centró en cómo la documentación incompleta de los operadores espaciales obliga a los usuarios a adivinar, y probablemente equivocarse a veces, cómo funciona el software en lugar de saber cómo debería funcionar.  Tan desafortunado para los usuarios como puede ser la documentación incompleta, mezclar diferentes definiciones de relaciones espaciales dentro del mismo operador espacial es mucho peor, y eso parece ser lo que Esri ha hecho.<\/P>

<\/P>

Tomando prestados ejemplos del post anterior, veamos tres características y el método ArcPy Geometry.within()<\/SPAN>.<\/P><\/P>>>> #Crear polígono cuadrado
>>> polygon = arcpy.FromWKT('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))')
>>> #Crear línea que yace completamente sobre el límite del polígono
>>> line = arcpy.FromWKT('LINESTRING(1 0, 2 0)')
>>> #Crear línea vacía
>>> line_empty = arcpy.FromWKT('LINESTRING EMPTY')
>>>
>>> #Probar si la línea está dentro del polígono
>>> line.within(polygon)
False
>>> #Probar si line_empty está dentro del polígono
>>> line_empty.within(polygon)
True<\/PRE><\/P>Para fines comparativos, ejecutemos las mismas dos pruebas de las Líneas 9 y 12 usando ST_Geometry de Esri en Oracle:<\/P><\/P>SQL> --Probar si la línea está dentro del 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'
--------------------------------------------------------------------------------
                                                             -<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/>-<br/&g... (truncated for brevity) ...

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.