Hier is waar het vandaag geregend heeft in Australië, een beetje rond Perth, veel in Queensland en voor de scherpzinnigen een beetje bij Cape York om de garnalen en krokodillen tevreden te houden. De legenda toont mm neerslag.<\/P>
<\/P>
Het Australian Bureau of Meteorology<\/A> publiceert downloadbare weersgegevens; mijn scenario is dat ik geïnteresseerd ben in het opnieuw publiceren van regenmeterwaarnemingen naar een hosted feature service, die op de kaart hierboven staat. Na wat zoeken ontdekte ik dat de gegevens beschikbaar zijn via FTP<\/A> met een schema beschreven in deze gebruikershandleiding<\/A>. De gegevens worden dagelijks vernieuwd. Hoewel ik de gegevens niet herverdeel in deze blog, vermeld ik dat ze gelicenseerd zijn onder Creative Commons<\/A>-voorwaarden zodat je mijn voorbeeld kunt implementeren als je wilt.<\/P><\/P>Hoewel de verversingssnelheid dagelijks is, kan elk bestand waarnemingen bevatten die meer dan 24 uur beslaan en van meerdere sensoren op een locatie komen. Hoe dan ook, wat ik wilde was dat de dagelijkse waarnemingen naar een feature service in mijn portal werden gestuurd; ik had de gegevens net zo goed naar ArcGIS Online kunnen sturen.<\/P><\/P>Deze periodieke synchronisaties vanaf het web<\/STRONG> zijn overal in GIS. Gegevensbeheerders maken het gemakkelijk om data handmatig<\/EM> te verkrijgen, ik ga je laten zien hoe eenvoudig het is om synchronisaties met Data Interoperability te automatiseren<\/EM>. Ik beschrijf Data Interoperability meestal als Esri's 'no-code' app-integratietechnologie. Volledige openheid, in dit voorbeeld heb ik wel wat Python gebruikt in de FME Workbenches die ik heb gemaakt, dus moet ik de claim van no-code<\/STRONG> iets nuanceren, maar ik kan wel zeggen dat het low-code<\/STRONG> is. Je kunt het zelf zien in de Workbenches.<\/P><\/P>Ik begon met het idee om het geplande proces een webtool te maken en het te plannen met Notebook Server. Dat zou misschien het leukst zijn om te bouwen, maar ik realiseerde me dat het gewoon niet nodig is voor mijn gebruikssituatie. Ik ben teruggevallen op een patroon waarover ik eerder geblogd heb<\/A>, namelijk het gebruik van Windows Taakplanner, maar dit keer op een server. Waarom niet de desktopsoftware aanpak gebruiken? Nou, om gebruik te maken van een machine met waarschijnlijk zeer hoge uptime waarvan ik weet dat die buiten mijn normale werktijden gepland kan worden.<\/P><\/P>Hier is de Workbench die het werk doet van het downloaden van de BoM productbestanden en het verzenden van features naar mijn portal's hosted feature service:<\/P><\/P><\/P><\/P>En ik kan het niet laten, hier is de Python, niet zo eng. Het zou onnodig zijn als de bestandsnamen op de FTP-site stabiel waren, dan had ik een FTPCaller<\/STRONG>-transformer kunnen gebruiken, maar ze hebben datumstempels als onderdeel van hun naam, dus was het makkelijker om dat met wat Python af te handelen. Terwijl ik de data aan het downloaden was heb ik ze ook een beetje opgeschoond (dubbele aanhalingstekens en nieuwe regeltekens verwijderd) en daarna alle waarnemingen doorgestuurd in de stroom.<\/P><\/P><\/P><\/P><\/P>Aangezien de gegevensbronnen niet veranderen heb ik alle parameters privé gemaakt, dit vereenvoudigt het commando om te plannen. Het enige wat ik hoef te doen is de Workbench op de server krijgen en ervoor zorgen dat hij draait. In de post-download vind je drie FMW-bestanden:<\/P><\/P>MakeRainGauges.fmw<\/STRONG><\/P>RefreshRainGauges.fmw<\/STRONG><\/P>RefreshRainGauges - Server Copy.fmw<\/STRONG><\/P><\/P>MakeRainGauges maakt een geodatabase feature class die ik in Pro gebruikte om mijn hosted feature service te initialiseren. RefreshRainGauges is gebouwd vanuit MakeRainGauges en verschilt alleen doordat hij schrijft naar de feature service, met initiële truncatie. Dat is de Workbench die ik wil plannen. RefreshRainGauges - Server Copy verschilt alleen van RefreshRainGauges in zijn Python-instellingen, om Python 3.6+ te gebruiken. Ik heb die naam niet op de server gebruikt, alleen om hem in de post-download te krijgen.<\/P><\/P>Op mijn portalserver was er wat setup nodig (ik heb één machine met alles erop geïnstalleerd, vergeet niet Data Interoperability te installeren en licentiëren!). RefreshRainGauges gebruikt een webverbinding naar mijn portal. In deze blog<\/A> beschrijf ik hoe je een portal webverbinding maakt. Deze moet gekopieerd worden naar de server voor de arcgis gebruiker<\/STRONG> die het geplande proces zal uitvoeren. De eenvoudigste manier is methode #2 in dit artikel<\/A>. Ingelogd op de server als arcgis maakte ik eerst een bureaubladkoppeling naar "C:\\Program Files\\ESRI\\Data Interoperability\\Data Interoperability AO11\\fmeworkbench.exe"<\/STRONG>, startte Workbench, importeerde toen het webverbinding XML-bestand en testte het lezen van de feature service. Ik kopieerde ook RefreshRainGauges naar een map en bewerkte deze om de Python-omgeving aan te passen aan de server (het voorbeeld was gebouwd met Pro 2.7 Beta maar de server draait Enterprise 10.8.1). Bij interactief draaien van de workspace toont het begin van het logboek het commando dat gepland moet worden:<\/P> Commando-regel om deze workspace uit te voeren:<\strong>
Hoewel de verversingssnelheid dagelijks is, kan elk bestand waarnemingen bevatten die meer dan 24 uur beslaan en van meerdere sensoren op een locatie komen. Hoe dan ook, wat ik wilde was dat de dagelijkse waarnemingen naar een feature service in mijn portal werden gestuurd; ik had de gegevens net zo goed naar ArcGIS Online kunnen sturen.<\/P>
Deze periodieke synchronisaties vanaf het web<\/STRONG> zijn overal in GIS. Gegevensbeheerders maken het gemakkelijk om data handmatig<\/EM> te verkrijgen, ik ga je laten zien hoe eenvoudig het is om synchronisaties met Data Interoperability te automatiseren<\/EM>. Ik beschrijf Data Interoperability meestal als Esri's 'no-code' app-integratietechnologie. Volledige openheid, in dit voorbeeld heb ik wel wat Python gebruikt in de FME Workbenches die ik heb gemaakt, dus moet ik de claim van no-code<\/STRONG> iets nuanceren, maar ik kan wel zeggen dat het low-code<\/STRONG> is. Je kunt het zelf zien in de Workbenches.<\/P><\/P>Ik begon met het idee om het geplande proces een webtool te maken en het te plannen met Notebook Server. Dat zou misschien het leukst zijn om te bouwen, maar ik realiseerde me dat het gewoon niet nodig is voor mijn gebruikssituatie. Ik ben teruggevallen op een patroon waarover ik
Hier is de Workbench die het werk doet van het downloaden van de BoM productbestanden en het verzenden van features naar mijn portal's hosted feature service:<\/P>
En ik kan het niet laten, hier is de Python, niet zo eng. Het zou onnodig zijn als de bestandsnamen op de FTP-site stabiel waren, dan had ik een FTPCaller<\/STRONG>-transformer kunnen gebruiken, maar ze hebben datumstempels als onderdeel van hun naam, dus was het makkelijker om dat met wat Python af te handelen. Terwijl ik de data aan het downloaden was heb ik ze ook een beetje opgeschoond (dubbele aanhalingstekens en nieuwe regeltekens verwijderd) en daarna alle waarnemingen doorgestuurd in de stroom.<\/P><\/P><\/P><\/P><\/P>Aangezien de gegevensbronnen niet veranderen heb ik alle parameters privé gemaakt, dit vereenvoudigt het commando om te plannen. Het enige wat ik hoef te doen is de Workbench op de server krijgen en ervoor zorgen dat hij draait. In de post-download vind je drie FMW-bestanden:<\/P><\/P>MakeRainGauges.fmw<\/STRONG><\/P>RefreshRainGauges.fmw<\/STRONG><\/P>RefreshRainGauges - Server Copy.fmw<\/STRONG><\/P><\/P>MakeRainGauges maakt een geodatabase feature class die ik in Pro gebruikte om mijn hosted feature service te initialiseren. RefreshRainGauges is gebouwd vanuit MakeRainGauges en verschilt alleen doordat hij schrijft naar de feature service, met initiële truncatie. Dat is de Workbench die ik wil plannen. RefreshRainGauges - Server Copy verschilt alleen van RefreshRainGauges in zijn Python-instellingen, om Python 3.6+ te gebruiken. Ik heb die naam niet op de server gebruikt, alleen om hem in de post-download te krijgen.<\/P><\/P>Op mijn portalserver was er wat setup nodig (ik heb één machine met alles erop geïnstalleerd, vergeet niet Data Interoperability te installeren en licentiëren!). RefreshRainGauges gebruikt een webverbinding naar mijn portal. In
"C:\Program Files\ESRI\Data Interoperability\Data Interoperability AO11\fme.exe" C:\Users\arcgis\Desktop\RefreshRainGauges.fmw
De rest is eenvoudig, maak gewoon een basistaak aan, het moeilijkste was uitvinden op welk tijdstip het commando uitgevoerd moet worden (ik zie data veranderen tot wel 1 uur 's nachts UTC dus koos ik voor 18 uur lokale tijd op mijn server, die zich in US West bevindt). Zorg ervoor dat de taak wordt uitgevoerd als arcgis niet is ingelogd en dat de arcgis gebruiker batch job rechten heeft (of administrator is, wat ik kan doen op mijn VM-machine maar jij waarschijnlijk niet mag).
Dat is alles, geautomatiseerd onderhoud van data die ik met iedereen kan delen! Ik sluit af met een screenshot van het verwerkingslogboek van gisteravond's synchronisatie:
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.