Voici mes données thématiques, les données cadastrales de l'État du New Jersey (~3,5 millions d'entités, 4,4 Go avec 45 champs), avec mes remerciements à l'équipe technique du NJ pour leur aide à la réalisation de cet exemple.<\/P>
Je vais bientôt expliquer pourquoi une parcelle est mise en évidence...<\/P>
<\/span><\/P>Tout d'abord, en référence au titre du post, cette discussion n'est pas liée à ArcGIS Online, vous pouvez travailler avec ArcGIS Enterprise et mettre en œuvre ce flux de travail, alors restez avec moi. Le défi de maintenir une couche d'entités hébergée de big data est courant.<\/STRONG><\/P>Le problème que nous essayons de résoudre ici est l'application d'une mise à jour de données à un service en direct lorsque la transaction de mise à jour est très volumineuse, dans notre cas des dizaines de milliers de modifications cadastrales sont écrites plusieurs fois par an, les entités peuvent être riches en points et le schéma est large. Si vous écrasez le service en utilisant l'interface utilisateur principale d'ArcGIS Pro, cela consomme une session pendant longtemps, donc mettons en place une automatisation plus efficace en utilisant ArcGIS Data Interoperability et écrivons uniquement la transaction delta.<\/P>Pour être précis, le mode d'écriture des changements recommandé pour les transactions plus importantes est upsert. Cela nécessite que le service d'entités cible ait un champ clé avec une contrainte d'unicité, ce que possèdent les données thématiques. Les upserts sont envoyés par morceaux de 10 Mo plutôt que par ensembles d'entités avec un nombre maximal de lignes supporté par le service (2000 pour les données polygonales).<\/P>Maintenir des services d'entités hébergés en appliquant une transaction delta comme modifications est une voie bien connue, la détection des changements dans ArcGIS Data Interoperability est idéale pour cela. Cependant, il y a quelques points à noter ici :<\/P>Les données entrantes pour la mise à jour sont au format file geodatabase<\/LI>L'espace de travail cible est un service d'entités hébergé<\/LI>Les jeux de données ne sont pas co-localisés<\/LI><\/UL>Cela implique quelques problèmes :<\/P>Le streaming local des données de la couche d'entités hébergée pour calculer le jeu de changements prendrait beaucoup de temps<\/LI>Les champs géométrie, date et numériques doivent avoir leur précision concordante pour une détection correcte des changementsLes différences subtiles de valeurs nécessitent une manipulation soigneuse<\/LI><\/UL><\/LI><\/UL>Les problèmes d'accord sur la précision peuvent être résolus avec la configuration des outils ETL, mais pour éviter complètement ce problème, l'approche que nous adopterons est de télécharger le service d'entités cible sous forme de file geodatabase distincte, ainsi les différences de précision dépendant du stockage ne sont pas un facteur. Ensuite, le jeu de changements peut être facilement calculé localement entre deux classes d'entités file geodatabase et le delta écrit efficacement.<\/P>C'est là qu'intervient la parcelle mise en évidence sur la carte. Les parcelles peuvent avoir une géométrie complexe, les limites peuvent comporter plusieurs segments, et les segments peuvent être des vraies courbes. Bien que le stockage des vraies courbes dans les couches d'entités hébergées soit pris en charge, leur édition est limitée. Voici quelques propriétés pertinentes de mon service d'entités cible :<\/P>{"allowGeometryUpdates" : true,
"supportsTrueCurve" : true,
"supportedCurveTypes" : ["esriGeometryCircularArc"],
"allowTrueCurvesUpdates" : true,
"onlyAllowTrueCurveUpdatesByTrueCurveClients" : true}<\/code><\/pre>Ce que vous pouvez retenir c'est que bien qu'une certaine édition des vraies courbes soit théoriquement possible, toutes les courbes du type esriGeometryEllipticArc ne sont pas prises en charge pour l'édition, et devinez quoi, un trou circulaire en forme de beignet dans une parcelle a une géométrie elliptique. De plus, notre client outil ETL n'est pas reconnu comme un client vrai courbe.<\/STRONG><\/SPAN><\/P>Si vous utilisez une version d'ArcGIS Data Interoperability qui ne prend pas en charge l'écrivain Esri ArcGIS Feature Service, vous devrez utiliser les outils d'administration du service d'entités pour définir onlyAllowTrueCurveUpdatesByTrueCurveClients sur false.<\/STRONG><\/P>Une façon simple de gérer les vraies courbes est de les convertir en polylignes lors des comparaisons géométriques ou lors de leur écriture dans le service d'entités en utilisant le transformateur ArcStroker, avec contrôle sur la déviation maximale par rapport à la vraie courbe. Cela remplace temporairement tout segment d'arc par des polylignes pour la comparaison géométrique et définitivement pour toute parcelle écrite qui a été mise à jour ou est nouvelle.<\/SPAN><\/P>Voici quelques vues de l'espace de travail qui réalise tout le travail, d'abord la vue Main...<\/SPAN><\/P>
<\/span><\/SPAN><\/P>...puis le transformateur personnalisé bouclant vert pâle looping custom transformer qui attend la fin d'une exportation file geodatabase...<\/P>
<\/span><\/SPAN><\/P>L'exportation file geodatabase prend un temps variable selon l'activité d'ArcGIS Online.<\/STRONG> J'ai lancé l'outil à une heure programmée qui correspondait à 3h00 UTC, l'exportation a duré 23 minutes. J'ai vu des durées allant jusqu'à 10 minutes ou une heure, mais aussi des échecs lors des tests aux heures chargées pour ArcGIS Online. Il est recommandé de programmer l'outil hors des heures chargées en Amérique du Nord et Europe , j'ai donc choisi 3h00 UTC.<\/SPAN><\/P>Pour appliquer un « codage défensif », juste avant et à l'intérieur du transformateur bouclant qui attend la fin du travail d'exportation, il y a quelques transformateurs Emailer qui envoient les détails de soumission du travail et les détails en cas de d'échec du travail. Le support Esri aura besoin à la fois des informations sur le travail et sur l'échec pour diagnostiquer le comportement du service en cas d'erreur ; veuillez ouvrir un ticket support si vous rencontrez des problèmes.<\/SPAN><\/P>Voici un exemple du corps d'un email contenant les détails du travail:<\/SPAN><\/P>Service d'entités:<\/P>https://services.arcgis.com/FQD0rKU8X5sAQfh8/arcgis/rest/services/NJParcels/FeatureServer
Tâche d'exportation du service d'entités:<\/P>
9f77069e-e212-46bb-8696-b7ce4f54c882::FQD0rKU8X5sAQfh8<\/P>
d'un élément service:<\/P>
4480efce4518473096613597d461e55f<\/P>
vers un élément export:<\/P>
1fc913da28174608b9a65859bcc8b9b0<\/P>
démarré à l'heure locale:<\/P>
2026-01-26T07:03:23.5436242-08:00<\/P>
Type est fichier et Taille est 4823392256<\/P>
Voici à quoi ressemble un message d'échec d'exportation (la traduction s'arrêtera) :<\/SPAN>
Tâche d'exportation du service d'entités a échoué avec statut failed<\/P>
L'échec s'est produit à l'heure locale 2026-01-26T09:05:01.0944432-08:00<\/P>
L'identifiant du travail était 9f77069e-e212-46bb-8696-b7ce4f54c882::FQD0rKU8X5sAQfh8<\/P>
La réponse au statut demandé était<\/P>
{"status": "failed","statusMessage": "failed","itemId": "4480efce4518473096613597d461e55f"}<\/P>
L'espace de travail se trouve dans le téléchargement du blog, vous devrez le modifier avec vos identifiants ArcGIS Online , les détails du service d'entités et les paramètres du transformateur Emailer .<\ /SPAN ><\ / P >< P >< STR ONG >Merci de commenter sur ce forum avec vos expériences et questions !<\ / STR ONG ><\ / P >< P >& nbsp ;<\ / P >
