Wat Binnen Is: Wanneer Esri + Clementini = Gebruiker Pas Op

JoshuaBixby

<\/HEAD>

Dit is het tweede deel van een tweedelige serie over de risico's voor softwaregebruikers van slechte documentatie; specifiek, de verwarring en onverwachte resultaten die voortkomen uit zwak gedocumenteerde ruimtelijke operatoren in GIS-software.  Het eerste deel van de serie <\/A>bekijkt hoe inconsistente en onvolledige documentatie gebruikers dwingt te raden hoe ruimtelijke operatoren zijn geïmplementeerd.  Het tweede deel van de serie<\/STRONG> bekijkt de inconsistente resultaten die ontstaan door het mengen van verschillende implementaties van ruimtelijke operatoren.<\/EM><\/P><\/P>Een van de vele bugs met lege geometrie die ik recentelijk heb ingediend, kwam deze week op de voorgrond toen ik merkte dat Esri de status had bijgewerkt naar "Gesloten:  Wordt Niet Aangepakt."  Wat daarop volgde is een discussie die nog steeds gaande is over verwacht gedrag versus onverwachte resultaten.  Toevallig kan het probleem netjes worden geplaatst binnen de discussie en voorbeelden uit het eerste bericht in deze serie (Wat Binnen Is:  Wanneer (Esri != Clementini) = ?<\/A>).<\/P>

<\/P>

Het eerste bericht in deze serie besprak hoe er geen eenduidige definitie is van ruimtelijke relaties voor geometriebibliotheken en georuimtelijke toepassingen, en hoe het Dimensionally Extended 9 Intersection Model (DE-9IM) de overheersende 2D-definitie werd na opname in de

OpenGIS Implementatiespecificatie voor Geografische informatie - Eenvoudige feature toegang - Deel 1: Gemeenschappelijke architectuur<\/A>.  Het bericht richtte zich op hoe onvolledige documentatie van ruimtelijke operatoren gebruikers dwingt te raden, en waarschijnlijk soms onjuist, hoe software werkt in plaats van te weten hoe de software zou moeten werken.  Zo ongelukkig als onvolledige documentatie voor gebruikers kan zijn, is het mengen van verschillende definities van ruimtelijke relaties binnen dezelfde ruimtelijke operator veel erger, en dat lijkt te zijn wat Esri heeft gedaan.<\/P>

<\/P>

Afgaand op de voorbeelden uit het vorige bericht, laten we drie functies bekijken en de ArcPy Geometry.within()<\/SPAN>-methode.<\/P><\/P>>>> #Maak vierkante polygoon
>>> polygon = arcpy.FromWKT('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))')
>>> #Maak lijn die volledig op polygoonrand ligt
>>> line = arcpy.FromWKT('LINESTRING(1 0, 2 0)')
>>> #Maak lege lijn
>>> line_empty = arcpy.FromWKT('LINESTRING EMPTY')
>>>
>>> #Test of lijn binnen polygoon ligt
>>> line.within(polygon)
False
>>> #Test of lege lijn binnen polygoon ligt
>>> line_empty.within(polygon)
True<\/PRE><\/P>Voor vergelijkingsdoeleinden laten we dezelfde twee tests uitvoeren als in regels 9 en 12 met behulp van Esris ST_Geometry in Oracle:<\/P><\/P>SQL> --Test of lijn binnen polygoon ligt
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> --Test of lege lijn binnen polygoon ligt
SQL> SELECT sde.st_within(sde.st_geomfromtext('LINESTRING EMPTY', 0),
 &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;, sde.st_geomfromtext('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))', 0))
&nbsp.& nbsp. FROM dual;
SDE.ST_WITHIN(SDE.ST_GEOMFROMTEXT('LINESTRINGEMPTY',0),SDE.ST_GEOMFROMTEXT('POLY'
--------------------------------------------------------------------------------
&nbsp.& nbsp.
<\/P>Interessant genoeg verschillen de resultaten van het gebruik van ST_Geometry van die met ArcPy.&#160; Wetende dat ST_Geometry-functies OGC simple feature access en SQL-conform zijn, wat betekent dat ze DE-9IM implementeren, zijn de resultaten van ST_Geometry in Oracle te verwachten omdat een lijn die uitsluitend op de grens van een polygoon ligt niet wordt beschouwd als binnen de polygoon, en een lege geometrie niet binnen een andere geometrie kan liggen.<\/P><\/P>Als we naar ArcPy-resultaten kijken, is regel 10 correct alleen als de

ArcPy Geometry Classes <\/A>de definitie van Clementini implementeren aangezien we in het eerste bericht van deze serie zagen dat Esri's definitie van Within in deze situatie Waar is.&#160; Helaas vermeldt de ArcPy-documentatie niet welke definitie wordt geïmplementeerd.&#160; Het resultaat op regel 13 is correct alleen als de ArcPy Geometry Classes <\/A>de definitie van Esri implementeren omdat de definitie van Clementini niet toestaat dat een lege geometrie binnen een andere geometrie ligt.&#160; Helder als modder, toch?<\/P>

<\/P>

De houding van Esri tot nu toe is dat alles werkt zoals ontworpen.&#160; Wat?!&#160; Als dat zo is, erkent Esri impliciet dat ze verschillende definities van een ruimtelijke relatie implementeren binnen dezelfde ruimtelijke operator, het hangt er gewoon vanaf welke geometrieën je doorgeeft!!&#160; Tussen de gesloten broncode, onvolledige documentatie en schijnbaar willekeurige implementatie zijn ArcPy Geometry Classes op eigen risico te gebruiken.&#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.