Lassen Sie mich Ihnen vor dem spaßigen Teil einen Absatz Hintergrundinformationen geben: In einem früheren Video<\/A> habe ich ein Beispiel gezeigt, wie man eine räumliche Einschränkung von der aktiven ArcGIS Pro-Karte oder -Szene erfasst und in einen ETL-Arbeitsbereich sendet. Das Beispiel arbeitete zufällig mit einem WFS-Dienst; diese haben einen Bounding-Box-Parameter, der die abgerufenen Features einschränken kann. WFS-Dienste unterstützen auch komplexere räumliche Operatoren, die mit beliebigen Geometrieoperanden als GML-Fragmente verwendet werden können. Wenn Sie jedoch nicht wissen, wie man das gesamte erforderliche XML für WFS-Anfragen zusammenstellt, dann sind Sie wie ich und haben Angst, es zu versuchen. ArcGIS Pro 2.3 unterstützt selbst nur eine Bounding-Box-Einschränkung bei WFS-Diensten.<\/P><\/P>Räumliche Einschränkungen sind bei Feature Services viel einfacher. Dieser Blog zeigt Ihnen, wie einfach das ist.<\/P><\/P>Core-Geoverarbeitung unterstützt Feature Services als Eingabeparameter schon seit mehreren Versionen, warum also überhaupt Spatial ETL gegen Feature Services verwenden? Nun, wenn Ihr Feature Service als ein anderes Format ausgegeben wird, oder Sie einige Transformationen verwenden, die Data Interoperability anzeigen, oder Ihr Feature Service sehr groß ist und Sie keine Selektionen zur Unterteilung verwenden möchten. Ich habe gerade einem Kunden geholfen, der während des ETL-Prozesses dynamisch eine räumliche Einschränkung mit einem FeatureReader-Transformer handhaben musste (mehr dazu weiter unten). Es gibt viele Anwendungsfälle.<\/P><\/P>Data Interoperability dreht sich alles um codefreie Ansätze, aber ich mache eine kleine Abschweifung zu den REST API-Abfrageparametern von Feature Services, damit Sie verstehen, was passiert. Unten sehen Sie einen Screenshot der HTML-Ansicht eines Feature Service<\/A>-Abfrageendpunkts. Beachten Sie, dass es einen Input Geometry<\/STRONG>-Parameter (als JSON bereitgestellt) gibt und Sie einstellen können, wie er verwendet wird. In meinem Fall ist es ein Polygon<\/STRONG>, für das ich nur Features möchte, die die Einschränkung Intersects<\/STRONG> erfüllen.<\/P><\/P><\/P><\/P>Der Trick bei der Anwendung räumlicher Einschränkungen auf Feature Services besteht also einfach darin, die Geometrie bereitzustellen!<\/P><\/P>Im Blog-Download (Pro 2.3+) finden Sie das verwendete Beispielwerkzeug, aber der Ansatz ist sehr einfach – wenden Sie ihn einfach selbst in Ihren eigenen Modellen an. Klicken Sie auf dieses Bild zur Vergrößerung, um die von mir verwendete Karte, den Feature-Satz in der Karte und im Inhaltsverzeichnis sowie das Modell als Werkzeuglauf zu sehen. Der Feature-Satz steuert automatisch die Analysegeometrie.<\/P><\/P><\/P><\/P>Das verwendete Werkzeug ist das Modell namens SpatiallyConstrainedGP<\/STRONG>, das einen Eingabeparameter vom Typ Feature Set hat. Zur Laufzeit geben Sie einen Wert an, indem Sie eine Ebene oder Feature-Class auswählen oder ein Feature manuell durch Bearbeiten in der Karte erstellen.<\/P><\/P><\/P><\/P>SpatiallyConstrainedGP<\/STRONG> umschließt das ETL-Werkzeug SpatiallyConstrainedETL <\/>\strong> so: Zwischen dem Eingabe-Feature-Set und dem ETL-Werkzeug befindet sich ein Modellwerkzeug Calculate Value<\/>\strong>:<\/P><\/>\p>
<\/P>
Räumliche Einschränkungen sind bei Feature Services viel einfacher. Dieser Blog zeigt Ihnen, wie einfach das ist.<\/P>
Core-Geoverarbeitung unterstützt Feature Services als Eingabeparameter schon seit mehreren Versionen, warum also überhaupt Spatial ETL gegen Feature Services verwenden? Nun, wenn Ihr Feature Service als ein anderes Format ausgegeben wird, oder Sie einige Transformationen verwenden, die Data Interoperability anzeigen, oder Ihr Feature Service sehr groß ist und Sie keine Selektionen zur Unterteilung verwenden möchten. Ich habe gerade einem Kunden geholfen, der während des ETL-Prozesses dynamisch eine räumliche Einschränkung mit einem FeatureReader-Transformer handhaben musste (mehr dazu weiter unten). Es gibt viele Anwendungsfälle.<\/P>
Data Interoperability dreht sich alles um codefreie Ansätze, aber ich mache eine kleine Abschweifung zu den REST API-Abfrageparametern von Feature Services, damit Sie verstehen, was passiert. Unten sehen Sie einen Screenshot der HTML-Ansicht eines
Alles was Calculate Value macht ist, dass das Eingabe-Feature-Set mit einem Python-Snippet in einen JSON-String umgewandelt wird:
Das JSON wird dann dem veröffentlichten ETL-Werkzeugparameter Input Geometry (denken Sie an den Query-Endpunkt!) übergeben und...
...das ETL-Werkzeug erledigt seine Arbeit und berücksichtigt nur Features, die mein Feature Set schneiden...
...was darin besteht, eine Tabelle zu erstellen, die einige Flächensummen pro Attributfall zusammenfasst:
Das war's also: Holen Sie sich einfach JSON aus der Karte, wenn Sie einem FeatureReader eines Feature Service einen Input Geometry-Parameter übergeben müssen. Wenn Sie einen FeatureReader-Transformer verwenden, um einen Feature Service zu lesen, ist der Workflow etwas anders: Sie müssen das JSON mit einem GeometryReplacer (die Geometrie-Codierung ist Esri JSON) in ein tatsächliches FME-Feature konvertieren und es als initiierenden Spatial Filter-Einschränkung des FeatureReader-Transformers bereitstellen, so:
Jetzt können Sie kartengetriebene räumliche Einschränkungen auf Ihr ETL anwenden!
Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registrieren Sie ein kostenloses Konto.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.