Hier is mijn vakinhoudelijke data, de kadastrale gegevens van de staat New Jersey (~3,5 miljoen features, 4,4 GB met 45 velden), met dank aan het NJ tech team voor hun hulp bij het samenstellen van dit voorbeeld.<\/P>
Ik zal zo uitleggen waarom één perceel is gemarkeerd...<\/P>
<\/span><\/P>Allereerst, met verwijzing naar de titel van de post, is deze discussie niet gebonden aan ArcGIS Online, je kunt ook met ArcGIS Enterprise werken en deze workflow implementeren, dus blijf bij me. De uitdaging van het onderhouden van een gehoste feature layer met big data is algemeen.<\/STRONG><\/P>Het probleem dat we hier proberen op te lossen is het toepassen van een data-update op een live service wanneer de update-transactie zeer groot is, in ons geval worden tientallen duizenden perceelbewerkingen meerdere keren per jaar geschreven, de features kunnen punt-rijke data bevatten en het schema is breed. Als je de service overschrijft via de standaard gebruikersinterface van ArcGIS Pro verbruikt dit een sessie voor lange tijd, dus laten we efficiëntere automatisering toepassen met ArcGIS Data Interoperability en alleen de delta-transactie schrijven.<\/P>Specifiek wordt voor grotere transacties de changeset schrijfmodus upsert aanbevolen. Dit vereist dat de doel-feature service een sleutelveld heeft met een unieke beperking, wat de vakinhoudelijke data heeft. Upserts worden in blokken van 10 MB verzonden in plaats van sets features met het maximale aantal rijen dat door de service wordt ondersteund (2000 voor polygon data).<\/P>Het onderhouden van gehoste feature services door een delta-transactie als bewerkingen toe te passen is een bekend pad, change detection in ArcGIS Data Interoperability is hiervoor ideaal. Er zijn echter enkele aandachtspunten:<\/P>De binnenkomende data voor de verversing is in file geodatabase-formaat<\/LI>De doelwerkruimte is een gehoste feature service<\/LI>De datasets zijn niet co-located<\/LI><\/UL>Dit impliceert enkele problemen:<\/P>Het lokaal streamen van de gehoste feature layer data om de changeset te berekenen zou lang duren<\/LI>Geometrie-, datum- en numerieke velden moeten qua precisie overeenkomen voor correcte change detectionKleine waardeveranderingen vereisen zorgvuldige behandeling<\/LI><\/UL><\/LI><\/UL>Precisie-overeenkomende problemen kunnen worden opgelost met ETL-toolconfiguratie, maar om het probleem helemaal te vermijden nemen we de aanpak om de doel-feature service te downloaden als een eigen file geodatabase, zodat opslagafhankelijke precisieverschillen geen factor zijn. Daarna kan de changeset eenvoudig lokaal worden berekend tussen twee file geodatabase feature classes en wordt de delta efficiënt geschreven.<\/P>Hier komt het gemarkeerde perceel op de kaart in beeld. Perceelsgrenzen kunnen complexe geometrie hebben, grenzen kunnen uit meerdere segmenten bestaan en segmenten kunnen true curves zijn. Hoewel het opslaan van true curves in gehoste feature layers wordt ondersteund, is het bewerken ervan beperkt. Zie hier enkele relevante eigenschappen van mijn doel-feature service:<\/P> {"allowGeometryUpdates" : true,
"supportsTrueCurve" : true,
"supportedCurveTypes" : ["esriGeometryCircularArc"],
"allowTrueCurvesUpdates" : true,
"onlyAllowTrueCurveUpdatesByTrueCurveClients" : true}<\/code><\/pre>Wat je hieruit kunt afleiden is dat hoewel enige true curve-bewerking theoretisch mogelijk is, curves van het type esriGeometryEllipticArc niet worden ondersteund voor bewerking, en raad eens, een cirkelvormig gat in een perceel heeft ellipsgeometrie. Ook is onze ETL-toolclient niet bekend als een true curve client.<\/STRONG><\/SPAN><\/P>Als je een release van ArcGIS Data Interoperability gebruikt die de Esri ArcGIS Feature Service writer niet ondersteunt, moet je met behulp van de feature service admin tools onlyAllowTrueCurveUpdatesByTrueCurveClients instellen op false.<\/STRONG><\/P>Eén eenvoudige manier om true curves te beheren is ze om te zetten naar polylijnen bij geometrievergelijkingen of bij het schrijven naar de feature service door gebruik te maken van de ArcStroker-transformer, met controle over maximale afwijking van de true curve. Dit vervangt elk boogsegment tijdelijk voor geometrievergelijking en permanent voor elk bijgewerkt of nieuw perceel dat wordt geschreven door polylijnen.<\/SPAN><\/P>Hier zijn een paar weergaven van de werkruimte die het hele proces uitvoert, eerst de Main-weergave...<\/SPAN><\/P>
<\/span><\/SPAN><\/P>...dan de lichtgroene looping custom transformer die wacht tot een file geodatabase-export voltooid is...<\/P>
<\/span><\/SPAN><\/P>De file geodatabase-export duurt variabele tijd, afhankelijk van hoe druk ArcGIS Online is.<\/STRONG> Ik heb het gereedschap op een gepland tijdstip uitgevoerd dat neerkwam op 3 uur 's nachts UTC, het duurde 23 minuten voor de export. Ik heb ook tijden gezien van 10 minuten of een uur, maar ook mislukkingen tijdens drukke periodes voor ArcGIS Online. Het wordt aanbevolen om het gereedschap buiten drukke tijden in Noord-Amerika en Europa te plannen, daarom gebruikte ik 3 uur 's nachts UTC.<\/SPAN><\/P>Om "defensive coding" toe te passen zijn er net vóór en binnenin de looping transformer die wacht op voltooiing van exporttaken enkele Emailer-transformers die details sturen over bijeenbrengen job-details en bijeenbrengen foutmeldingen, mocht dat voorkomen. Esri support heeft zowel job- als foutinformatie nodig om problemen met je service te onderzoeken bij fouten. Open alstublieft een support call als je problemen ondervindt.<\/SPAN><\/P>Hier is een voorbeeld van een e-maillichaam met bijeenbrengen job details:<\/SPAN><\/P>Feature service:<\/P>https:\/\/services.arcgis.com\/FQD0rKU8X5sAQfh8\/arcgis/rest/services/NJParcels/FeatureServer<\/><\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<\/>\/<>
