Laat me u door een alinea achtergrondinformatie leiden voordat we bij het leuke gedeelte komen: In een eerder video<\/A> heb ik een voorbeeld opgenomen van het vastleggen van een ruimtelijke beperking van de actieve ArcGIS Pro-kaart of scène en deze naar een ETL-werkruimte sturen. Het voorbeeld werkte toevallig met een WFS-service; deze hebben een bounding box-parameter die de opgehaalde features kan beperken. WFS-services ondersteunen ook complexere ruimtelijke operatoren die kunnen worden gebruikt met willekeurige geometrie-operanden geleverd als GML-fragmenten. Echter, tenzij je weet hoe je alle benodigde XML voor WFS-verzoeken samenstelt, zul je net als ik bang zijn om het te proberen. ArcGIS Pro 2.3 ondersteunt zelf alleen een bounding box-beperking op WFS-services.<\/P><\/P>Ruimtelijke beperkingen zijn veel eenvoudiger met feature services. Deze blog laat zien hoe eenvoudig dat is.<\/P><\/P>Core geoprocessing ondersteunt feature services als invoerparameters al enkele releases, waarom zou je dan Spatial ETL gebruiken tegen feature services? Nou, als je feature service wordt geëxporteerd naar een ander formaat, of je gebruikt enkele transformaties die Data Interoperability aangeven, of je feature service is erg groot en je wilt geen selecties gebruiken om het te verkleinen. Ik heb net een klant geholpen die dynamisch een ruimtelijke beperking moest afhandelen halverwege ETL met een FeatureReader transformer (meer daarover hieronder). Er zijn veel gebruikssituaties.<\/P><\/P>Data Interoperability draait om codevrije benaderingen, maar ik neem even een kleine zijweg in feature service REST API-queryparameters zodat je begrijpt wat er gebeurt. Hieronder staat een screenshot van de HTML-weergave van een feature service<\/A> Query-eindpunt. Let op dat er een Input Geometry<\/STRONG>-parameter is (geleverd als JSON) en je kunt instellen hoe deze wordt gebruikt, in mijn geval is het een Polygon<\/STRONG> waarvoor ik alleen features wil die voldoen aan de beperking Intersects<\/STRONG>.<\/P><\/P><\/P><\/P>Dus, de truc bij het toepassen van ruimtelijke beperkingen op feature services is gewoon het leveren van de geometrie!<\/P><\/P>In de blogdownload (Pro 2.3+) vind je het gebruikte voorbeeldgereedschap, maar de aanpak is heel eenvoudig, pas het gewoon zelf toe in je eigen modellen. Klik om deze afbeelding te vergroten om de kaart te zien die ik gebruikte, de feature set in de kaart en inhoudsopgave en het model dat als gereedschap wordt uitgevoerd. De feature set stuurt automatisch de analysegeometrie aan.<\/P><\/P><\/P><\/P>Het gebruikte gereedschap is het Model genaamd SpatiallyConstrainedGP<\/STRONG> dat een invoerparameter heeft van het type Feature Set. Tijdens uitvoering lever je een waarde door een laag of feature class te kiezen of handmatig een feature te maken door te bewerken in de kaart.<\/P><\/P><\/P><\/P>SpatiallyConstrainedGP<\/STRONG> wikkelt het ETL-gereedschap SpatiallyConstrainedETL <\/?STRONG> zo in, er is een modelgereedschap Calculate Value<\/?STRONG> tussen de invoer-feature set en het ETL-gereedschap:<\/P><\/?P>
<\/P>
Ruimtelijke beperkingen zijn veel eenvoudiger met feature services. Deze blog laat zien hoe eenvoudig dat is.<\/P>
Core geoprocessing ondersteunt feature services als invoerparameters al enkele releases, waarom zou je dan Spatial ETL gebruiken tegen feature services? Nou, als je feature service wordt geëxporteerd naar een ander formaat, of je gebruikt enkele transformaties die Data Interoperability aangeven, of je feature service is erg groot en je wilt geen selecties gebruiken om het te verkleinen. Ik heb net een klant geholpen die dynamisch een ruimtelijke beperking moest afhandelen halverwege ETL met een FeatureReader transformer (meer daarover hieronder). Er zijn veel gebruikssituaties.<\/P>
Data Interoperability draait om codevrije benaderingen, maar ik neem even een kleine zijweg in feature service REST API-queryparameters zodat je begrijpt wat er gebeurt. Hieronder staat een screenshot van de HTML-weergave van een
Alles wat er gebeurt met Calculate Value, is dat de invoer-feature set wordt omgezet in een JSON-string met een Python-fragment:<\/?p>
De JSON wordt vervolgens geleverd aan de gepubliceerde ETL-gereedschapsparameter Input Geometry (onthoud het Query-eindpunt!) en...<\/?p>
...het ETL-gereedschap doet zijn werk, waarbij alleen features worden overwogen die mijn feature set snijden...<\/?p>
..wat inhoudt dat er een spreadsheet wordt gemaakt die enkele perceeloppervlakte-totalen per geval van een attribuut samenvat:<\/?p>
Dat is het dus, pak gewoon JSON uit de kaart wanneer je een feature service-lezer moet voorzien van een Input Geometry-parameter. Als je een FeatureReader transformer gebruikt om een feature service te lezen, is de workflow iets anders, dan moet je de JSON converteren naar een echte FME-feature met een GeometryReplacer (de geometriecodering is Esri JSON) en deze leveren als initiator Spatial Filter-beperking van de FeatureReader, zoals dit:<\/?p>
Nu kunt u kaartgestuurde ruimtelijke beperkingen toepassen op uw ETL!<\/?p><\/?BODY><\/?HTML>
Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
