<\/HEAD>
We gaan op reis naar de bodem van de zee, maar de echte boodschap hier is het vermogen van ArcGIS Data Interoperability om verbinding te maken met het web (of ergens anders) en feature- en mediagegevens in een geodatabase-featureklasse met bijlagen te krijgen zonder te hoeven programmeren. Nou, slechts een heel klein beetje, maar je hoeft je niet druk te maken over de details zoals een programmeur.<\/P>
<\/P>
Een collega kwam naar me toe met de vraag of ArcGIS Data Interoperability CSV-positie- en tijdgegevens van missies van een onderzeeër en gerelateerde mediacontent kon samenbrengen en alles in een geodatabase kon krijgen. In productie zullen alle databronnen op het web staan. Geen probleem. Data Interoperability gaat niet alleen over formaten en transformaties, het gaat ook over integraties, en die bouwen zonder coderen.<\/P>
<\/P>
<\/P>
<\/P>
Python komt in beeld als laatste stap die veel ingewikkeld ETL-werk voorkomt. De combinatie van een ETL-tool en een beetje ArcPy is een enorme productiviteitsvermenigvuldiger voor alle interoperators daarbuiten. Verken de post-download voor hoe de CSV- en mediabronnen samen worden gebracht - heel eenvoudig - hieronder staat het hele 'programma':<\/P>
<\/P>
<\/P>
<\/P>
ArcGIS Data Interoperability heeft een geweldig 'verkooppunt', namelijk dat je gecodeerde workflows kunt vermijden en het visuele programmeerparadigma van Workbench kunt gebruiken om gegevens van A naar B te krijgen in de vorm die je wilt. Ik laat collega's vaak zien hoe ze integratieproblemen efficiënt kunnen oplossen met Data Interoperability en het is altijd prettig om te zien dat ze 'het snappen' dat uitdagingen niet met code hoeven te worden aangepakt.<\/P>
<\/P>
Laag niveau coderen is wat we vermijden.<\/STRONG> ArcGIS geoprocessing tools zijn toegankelijk als Python-functies; het gebruik van geoprocessing tools op deze manier is gewoon een opdrachtregel-aanroep van wat je toegang toe hebt in het Geoprocessing-paneel en de Analysis-linttools-galerij enzovoort. Als dit nieuw voor je is, bekijk dan eerst de Get Count<\/STRONG>-tool uit de systeemtoolbox en gebruik vervolgens het resultaat in het Python-venster.<\/P><\/P>Hier is de toolervaring:<\/P><\/P>
<\/P>
<\/P><\/P>Nu in het Catalog-paneel Geschiedenis-weergave, klik met de rechtermuisknop op het resultaat en stuur naar het Python-venster:<\/P><\/P>
<\/P>
<\/P><\/P>Je ziet de Python-expressie die gelijkwaardig is aan de tool:<\/P><\/P>
<\/P><\/P>Let op, ik heb geen code geschreven...<\/STRONG><\/P><\/P>Waar wil ik naartoe met dit? ArcGIS Data Interoperability-concepten verschillen iets van kern-geoprocessing doordat invoer- en uitvoer parameters<\/><\/> vaak ouderwerkruimten zijn en niet featuretypes of tabellen daarin. Je schrijft bijvoorbeeld vaak naar geodatabases, in welk geval de uitvoerparameter van de ETL-tool de geodatabase is<\/> , niet de featureklassen en tabellen zelf, hoewel deze wel zijn geconfigureerd in de ETL-tool.<\/> <\/> <\/> Wat als je iets moet doen vóór, tijdens of na je ETL-proces waarvoor er een krachtige ArcGIS-geoprocessingtool beschikbaar is maar wat erg moeilijk zou zijn om in Workbench te doen?<\/> <\/> Je gebruikt hoog-niveau ArcGIS Python-functies om dit werk in Workbench te doen.<\/> <\/> <\/> Ik geef zo meteen een eenvoudig, krachtig voorbeeld, maar eerst enkele Workbench Python-tips.<\/> <\/> <\/> Workbench stelt je in staat je Python-omgeving te configureren; om conflicten met Pro's pakketbeheer te vermijden kies je gewoon voor de standaardinstellingen:<\/> <\/> <\/> In Tools>FME Options>Translation<\/> controleer je dat je Pro's Python-omgeving verkiest:<\/> <\/> 
<\/> <\/> In je Workbench controleer je dat je Python Compatibility deze voorkeur gebruikt.<\/> <\/> 
<\/> <\/> Nu weet je dat de ArcGIS Python-omgeving gebruikt kan worden.<\/> <\/> Voor mijn use case geef ik een echt voorbeeld (bijgevoegd hieronder) waar ik geodatabase-bijlagen moet aanmaken en laden. Dit kunnen we niet volledig in Workbench doen (behalve op de manier die ik je zal laten zien) omdat het geen bijlagen-relatieklasse kan aanmaken. Je zou dat handmatig kunnen doen vóór het laden van gegevens, maar dan moet je nog steeds afbeeldingen omzetten naar blobgegevens, koppelingsidentificatoren beheren en andere dingen die hoofdpijn veroorzaken, dus laten we ArcPy gebruiken. Handmatige stappen sluiten ook uit dat nieuwe geodatabases met de ETL-tool worden aangemaakt, wat ik wil ondersteunen.<\/> <\/> Het voorbeeld schrijft een featureklasse die bestemd is om bijlagen te hebben, en een tabel die gebruikt kan worden om ze te laden. Je kunt de verwerking onderzoeken, maar het belangrijkste element om te inspecteren is het afsluitscript dat wordt uitgevoerd na voltooiing, zie Tool Parameters>Scripting>Shutdown Python Script<\/> .<\/> <\/> Hier is het ingesloten script:<\/> <\/> 
<\/> Dit is niet veel code, een paar imports, toegang tot het woordenboek dat beschikbaar is in elke Workbench-sessie om uitvoerpadwaarden op te halen die tijdens runtime worden gebruikt, dan slechts twee regels die geoprocessingtools als functies aanroepen om de bijlagen te laden.<\/><\/><\/>Dit is een geweldige manier om ArcGIS' krachtige Python-omgeving te integreren in ETL-tools.<\/>
Oplettende mensen zullen ook een gescripte parameter in de werkruimte opmerken, deze gebruikt geen ArcPy dus ik kan niet beweren dat dit laag niveau coderen vermijdt, het was gewoon een manier om flexibel een map aan te maken voor het downloaden van afbeeldingen tijdens runtime. Er zijn verschillende manieren om Python in Workbench te gebruiken<\/>
, maar ik zou afbreuk doen aan mijn boodschap hier dat je kunt beginnen met de eenvoudige en krachtige - gebruik ArcGIS geoprocessing waar het werk bespaart. Geniet ervan!<\/>
