<\/HEAD>
Nous sommes actuellement en phase de développement et de test de la mise en œuvre du Parcel Fabric pour notre comté, et nous avons rencontré des problèmes de performance EXTRÊMES auxquels personne ne semble avoir de réponse.<\/P>
<\/P>
Pour un bref contexte : Nous avons déjà (il y a plusieurs mois) terminé un long processus de nettoyage de nos parcelles – simplifiant le tracé en supprimant les sommets excessifs et en planarisant la majorité d’entre eux en lignes à 2 points (sauf pour une minorité de limites de parcelles suivant des caractéristiques naturelles comme l’hydro, etc., qui ont été laissées sous forme de lignestrings). Ce nettoyage a supprimé plus de 10 millions de sommets superflus. Nos données nettoyées de parcelles et subdivisions ont ensuite été traitées davantage et chargées dans le schéma de staging fourni par ESRI (FGDB) où toutes les erreurs/problèmes topologiques ont été corrigés, puis finalement chargés dans un nouveau Fabric (FGDB). Ce FGDB source du Fabric a ensuite été chargé dans notre SDE de développement (ArcSDE 10.3.1 | Oracle 11.2.0.3) via l’outil Copy Parcel Fabric.<\/P>
<\/P>
Notre premier problème de performance est survenu lors de la tentative d’enregistrement du Fabric en tant que versionné. Parce que le processus de versionnage exécute une série d’« analyses » sur tous les objets/tables du Fabric avant l’enregistrement lui-même, le processus semble se bloquer – alors qu’en réalité, il prend simplement beaucoup de temps à se terminer. Dans notre cas, « beaucoup de temps » signifie que les classes d’entités « Parcels » et « Lines » ont chacune pris 4-5 heures pour s’achever. Un examen rapide des tables (et leurs différents index créés) a révélé que la classe d’entités « Lines » seule contient 2,9 millions de lignes/enregistrements. Bien que cela m’alarme quelque peu, personne chez ESRI n’a suggéré que cela soit excessif, per se.<\/P>
<\/P>
Après avoir enfin réussi à l’enregistrer, j’ai commencé quelques tests d’édition rudimentaires, me concentrant principalement sur des workflows simples du Parcel Fabric comme une division de parcelle. Immédiatement, au moment du workflow où l’outil Construction est activé, le curseur/croix montre une latence épuisante, devenant un pointeur avec un sablier lorsqu’il est déplacé dans la fenêtre cartographique (comme si une opération intense était en cours). Si on le laisse tranquille (en arrêtant le mouvement de la souris), la croix revient après 10-15 secondes… mais elle redevient un sablier dès que vous essayez de la déplacer à nouveau. Si vous déplacez le pointeur non réactif à proximité d’une ligne de construction et attendez, il se comportera comme s’il était accroché une fois que la croix revient. À partir de ce point, si vous déplacez LENTEMENT le curseur le long de la ligne déjà accrochée, il restera une croix active. Cependant, si vous bougez trop vite ou dépassez la tolérance collante de l’environnement d’accrochage (10 pixels), la croix redeviendra un sablier. Si vous êtes assez patient pour commencer réellement à construire une ligne pendant ce temps, le même comportement continuera tout au long de l’ajout des sommets et des accrochages aux lignes correspondantes. Une fois terminé, vous pouvez Construire les entités construites comme d’habitude.<\/P>
<\/P>
Après des tests supplémentaires, j’ai découvert que si j’active l’environnement « Classic Snapping » qui permet de contrôler quelles couches et types d’entités dans votre TOC sont disponibles pour l’accrochage (par opposition au nouvel environnement d’accrochage par défaut où toutes les couches sont toujours activées pour l’accrochage), et que je désactive l’accrochage sur toutes les couches, le problème de performance disparaît. À ce stade, le Fabric continue d’imposer l’accrochage à lui-même (ce qui est nécessaire), même lorsque toutes les couches sont réglées pour ne pas s’accrocher. Le moment où vous activez la FC Lines cependant, c’est là que la performance chute brutalement.<\/P>
<\/P>
Fait intéressant, ce comportement ne se produit PAS dans un FGDB. Cela me conduit à supposer qu’il existe une interaction unique entre ArcMap, SDE et la base Oracle concernant la FC Lines très gourmande en données. Malgré qu’ESRI ait fourni plusieurs méthodes supplémentaires pour réanalyser directement (via SQL) les tables du Fabric et régénérer les index spatiaux, etc., aucune amélioration n’a été obtenue, ni aucun goulot d’étranglement apparent identifié (via SDE Intercept et fichiers trace Oracle)… Ce n’est PAS un problème d’E/S, ni un problème apparent lié au traitement SQL.<\/P>
<\/P>
Je reviens à ma préoccupation concernant le nombre énorme d’enregistrements dans la classe d’entités Lines, mais je n’ai aucun moyen de confirmer comment/pourquoi/si cela est une préoccupation valide. ArcMap semble clairement avoir du mal à interagir en temps réel avec les données Lines, mais je n’ai aucune explication fonctionnelle à offrir hormis mes simples observations. Clairement, le FGDB crée ses propres types d’index spatiaux sur cette grande classe d’entités mais fonctionne tout aussi bien sans problème. En revanche, Oracle devrait être encore plus robuste, supportant aisément une table avec seulement 3 millions d’enregistrements – pourtant ici la performance est abominable. Ainsi, je reviens toujours à quelque chose que fait l’application elle-même et pas simplement la base de données.<\/P>
<\/P>
Si quelqu’un a eu des expériences similaires ou des idées sur ce problème, nous vous serions très reconnaissants !<\/P>
<\/P>
Gavin<\/P><\/BODY><\/HTML>
