<\/HEAD>
Dies ist der erste Teil einer zweiteiligen Serie über die Risiken für Softwareanwender durch schlechte Dokumentation; insbesondere die Verwirrung und unerwarteten Ergebnisse, die durch schwach dokumentierte spatial operators in GIS-Software entstehen. Der erste Teil der Serie<\/STRONG> betrachtet, wie inkonsistente und unvollständige Dokumentation die Benutzer dazu zwingt, zu erraten, wie spatial operators implementiert sind. Der zweite Teil der Serie<\/A> untersucht die inkonsistenten Ergebnisse, die durch das Mischen verschiedener Implementierungen von spatial operators entstehen.<\/EM><\/P><\/P>
Neun Monate seit meinem letzten Blogbeitrag, kann ich nicht sagen, dass das das Tempo war, das ich anstrebte, als GeoNet gestartet wurde (zumindest messe ich GeoNet-Beschlüssen nicht mehr Gewicht bei als Neujahrsbeschlüssen<\/EM>). Ich weiß nicht, ob meine Durststrecke vorbei ist, aber ein roher Nerv wurde von Esri hart genug getroffen, um zumindest vorübergehend Regen zu bringen. Von all den Seifenkisten, die meine Schränke füllen, ist schlechte Dokumentation und ihre Folgen eine der abgenutztesten. So sehr Honest Abe auch sagt, man könne nicht allem vertrauen, was man im Internet liest, denke ich doch, dass Softwareanwender dem Online-Hilfe\/Dokumentation eines Unternehmens vertrauen können sollten.<\/P><\/P>Man kann nicht zu viel Zeit in der Welt der spatial relations verbringen, ohne auf das Dimensionally Extended 9 Intersection Model (DE-9IM) zu stoßen. Das DE-9IM wurde Mitte der 90er Jahre von Clementini und anderen als Weiterentwicklung des 4 Intersection Model (4IM) und 9 Intersection Model (9IM) entwickelt. Obwohl das DE-9IM nicht die einzige Definition von spatial relationships ist, wurde es nach der Aufnahme in die
OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture<\/A> zur vorherrschenden 2D-Definition.<\/P><\/P>
Verweise auf und Diskussionen über DE-9IM waren früher in verschiedenen Esri-Dokumentationen zu finden, aber diese Verweise und Dokumentationen werden in der aktuellen ArcGIS-Dokumentation immer schwerer zu finden. Zum Beispiel wird zwischen den neuen 10.3
ArcGIS for Desktop<\/A>, ArcGIS for Server<\/A> und ArcGIS for Developers <\/A>-Seiten Clementini nur auf ein paar Seiten erwähnt und DE-9IM wird nur auf einer Seite erwähnt und diskutiert: Relational functions for ST_Geometry<\/A>. Während Python eine Philosophie des "wir sind alle erwachsen" verfolgt, scheint Esri in die andere Richtung zu gehen und uns Pablum zu füttern, allerdings ohne Vitaminanreicherung.<\/P><\/P>
Obwohl DE-9IM die Grundlage für 2D spatial predicates\/relations in vielen Geometriebibliotheken und geospatialen Anwendungen ist, gibt es zwei Overlay-Typen für das
Select Layer By Location <\/A>-Werkzeug, bei denen Esris Standardimplementierung von Clementini abweicht: Contains, Within. In beiden Fällen impliziert der Standard- oder unqualifizierte Overlay-Typ Esris Definition (blaue Unterstreichung<\/SPAN>), während die Clementini-Definition (rote Unterstreichung<\/SPAN>) durch Qualifikatoren gehandhabt wird.<\/P>
<\/P>Wie unterscheidet sich also Esris Definition von Contains und Within von der Clementini-Definition? Ohne mathematische Notation und Illustrationsmatrizen reduziert sich der Unterschied darauf, wie Grenzen von Geometrien behandelt werden. Zum Beispiel wird eine Geometrie a<\/SPAN>, die vollständig auf der Grenze einer Geometrie b<\/SPAN> liegt, nach Esris Definition als innerhalb der Geometrie b<\/SPAN> betrachtet, aber nach Clementinis Definition nicht innerhalb der Geometrie b<\/SPAN>. Lassen Sie uns einfache Polygon- und Linienobjekte erstellen, um dies zu demonstrieren:<\/P><\/P>>>> polygon = arcpy.FromWKT('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))')
>>> line = arcpy.FromWKT('LINESTRING(1 0, 2 0)')
>>> arcpy.CopyFeatures_management(polygon, 'in_memory\/polygon')
<Result 'in_memory\\polygon'>
>>> arcpy.CopyFeatures_management(line, 'in_memory\/line')
<Result 'in_memory\\line'><\/PRE><\/P><\/P>
<\/P>Ausführen des Select Layer By Location <\/A>-Werkzeugs mit beiden Definitionen von Within:<\/P><\/P>
>>> arcpy.SelectLayerByLocation_management("line", "WITHIN", "polygon")
<Result 'line'>
>>> arcpy.GetCount_management("line")
<Result '1'>
>>> arcpy.SelectLayerByLocation_management("line", "WITHIN_CLEMENTINI", "polygon")
<Result 'line'>
>>> arcpy.GetCount_management("line")
<Result '0'><\/PRE><\/P>Bisher so gut. Abgesehen davon, dass Esris Standarddefinitionen von Contains und Within sich von den meisten anderen Geometriebibliotheken und geospatialen Anwendungen unterscheiden, einschließlich der OGC simple feature standards, stimmen zumindest die Ergebnisse mit der spärlichen online verfügbaren Dokumentation überein.<\/P><\/P>An dieser Stelle ist es wirklich wichtig etwas hervorzuheben, das leicht übersehen wird. Die ST_Geometry-Funktionen von Esri sind<\/> konform mit den OGC simple feature access und SQL Standards, was bedeutet, dass ST_Within der Clementini-Definition folgt und nicht der Esri-Definition.<\/>p>
SQL> SELECT sde.st_within(sde.st_geomfromtext('LINESTRING(1 0, 2 0)', 0),
2 sde.st_geomfromtext('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))', 0))
3 FROM dual;
SDE.ST_WITHIN(SDE.ST_GEOMFROMTEXT('LINESTRING(10,20)',0),SDE.ST_GEOMFROMTEXT('PO
--------------------------------------------------------------------------------
& nbsp;
Bisher würde ich argumentieren, dass die Esri-Dokumentation bezüglich spatial relations schwach war, weil sie stark auf Schlussfolgerungen basiert.& nbsp ; Der aufmerksame Benutzer könnte bemerken , dass es mehrere Within Overlay-Typen im Dropdown-Menü für das Select Layer By Location-Werkzeug gibt , und der neugierige Benutzer könnte einen Schritt weiter gehen , um über Overlay-Typen zu lesen , um die Unterschiede zwischen ihnen zu verstehen . & nbsp ; Der wirklich aufmerksame und sachkundige Benutzer könnte verstehen , dass eine einzelne Zeile in der Was ist der ST_Geometry-Speichertyp?-Dokumentation besagt , dass ST_Geometry die SQL-3-Spezifikation implementiert , was bedeutet , dass die ST_Within-Funktion Clementinis Definition anstelle von Esris aus dem Select Layer By Location-Werkzeug folgt . & nbsp ; Kurz gesagt , es gibt keine Dokumentation , die explizit anerkennt , dass es unterschiedliche Definitionen bestimmter spatial relations innerhalb verschiedener Teile von Esris eigener Software gibt .
Schon verwirrt? & nbsp ; Warten Sie nur , der Spaß beginnt wirklich , wenn wir in die ArcPy Geometry Classes eintauchen , denn die Dokumentation wird von schwach zu wirklich schwach . & nbsp ; Die einzigen Verweise auf OGC in der ArcPy Geometry Classes-Dokumentation sind für die WKB- und WKT-Eigenschaften , und es gibt keine Verweise auf DE-9IM oder Clementini . & nbsp ; Werfen wir einen Blick auf die Dokumentation für die within-Methode:< /p>
<\/P>
Also, die Geometrie liegt innerhalb einer anderen Geometrie, wenn sie sich innerhalb dieser Geometrie befindet. Verstanden. Oh Moment, fragen sie mich, ob eine Geometrie innerhalb einer anderen Geometrie liegt? Obwohl keine der Abbildungen eine Situation zeigt, die die Esri- und Clementini-Definitionen unterscheidet, lässt das Fehlen jeglicher Referenz auf OGC, DE-9IM oder Clementini vermuten, dass die Definition von Esri verwendet wird. Lassen Sie uns nachsehen:<\/P>
<\/P>
>>> line.within(polygon)
False<\/PRE><\/P>Au weh, das tut weh. Es ist ziemlich klar, dass es an Konsistenz mangelt, wie bestimmte räumliche Operatoren in verschiedenen Teilen der Esri-Software implementiert sind, aber das Schlimmste ist, dass die Dokumentation dies nicht einmal hervorhebt. Die Benutzer müssen selbst schließen und tun dies wahrscheinlich manchmal falsch, wie die Software funktioniert, anstatt darüber informiert zu werden, wie sie funktioniert. Caveat utilitor<\/EM>.<\/P><\/BODY><\/HTML>
