<\/HEAD>
We bevinden ons momenteel in de ontwikkelings- en testfase van de implementatie van de Parcel Fabric voor onze county, en zijn geconfronteerd met EXTREME prestatieproblemen waar niemand een antwoord op lijkt te hebben.<\/P>
<\/P>
Als korte achtergrond: We hebben al (maanden geleden) een langdurig opschoningsproces van onze percelen voltooid – het vereenvoudigen van de lijnvoering door overtollige vertices te verwijderen en het merendeel ervan te planarizeren tot 2-puntslijnen (behalve een minderheid van perceelgrenzen die natuurlijke kenmerken volgen zoals hydro, enz., die als linestrings zijn gelaten). Deze opschoning verwijderde meer dan 10 miljoen overbodige vertices. Onze opgeschoonde perceel- en verkavelingsgegevens werden vervolgens verder verwerkt en geladen in het door ESRI geleverde staging schema (FGDB) waar alle topologie fouten/problemen werden gecorrigeerd, en uiteindelijk geladen in een nieuwe Fabric (FGDB). Deze bron Fabric FGDB werd daarna geladen in onze Development SDE (ArcSDE 10.3.1 | Oracle 11.2.0.3) database via de Copy Parcel Fabric tool.<\/P>
<\/P>
Ons eerste prestatieprobleem trad op bij het proberen om de Fabric als versioned te registreren. Omdat het versioning proces een reeks "analyzes" uitvoert op alle Fabric objecten/tabellen voorafgaand aan de registratie zelf, lijkt het proces te hangen – terwijl het in werkelijkheid gewoon erg lang duurt om te voltooien. In ons geval betekent "erg lang" dat zowel de "Parcels" als de "Lines" feature classes elk 4-5 uur nodig hadden om te voltooien. Een vluchtige blik op de tabellen (en hun verschillende aangemaakte indexen) toonde aan dat alleen al de "Lines" feature class 2,9 miljoen lijnen/records bevat. Hoewel dit voor mij enigszins verontrustend is, heeft niemand bij ESRI gesuggereerd dat dit per se buitengewoon is.<\/P>
<\/P>
Nadat het eindelijk geregistreerd was, begon ik met wat rudimentaire bewerkingstests, voornamelijk gericht op eenvoudige Parcel Fabric Workflows zoals een perceelsplitsing. Direct, op het punt in de Workflow waar de Construction tool wordt geactiveerd, vertoont de cursor/kruisvormige aanwijzer een verbijsterende vertraging, die verandert in een pointer met een zandloper wanneer deze door het kaartvenster wordt bewogen (alsof er een intensieve bewerking gaande is). Als je hem met rust laat (de muisbeweging stopt), keert de kruisvormige aanwijzer na 10-15 seconden terug... maar zal weer veranderen in een zandloper zodra je probeert hem opnieuw te bewegen. Als je de niet-reagerende pointer binnen snap-afstand van een constructielijn-feature beweegt en wacht, gedraagt hij zich alsof hij vastklikt zodra de kruisvormige aanwijzer terugkeert. Vanaf dat punt, als je LANGZAAM de cursor langs het reeds vastgeklikte feature beweegt, blijft hij een actieve kruisvormige aanwijzer. Als je echter te snel beweegt of buiten de kleverige tolerantie van de snap-omgeving (10 pixels) gaat, wordt de kruisvormige aanwijzer weer een zandloper. Als je geduldig genoeg bent om tijdens deze tijd daadwerkelijk een lijnfeature te construeren, blijft hetzelfde gedrag zich voordoen gedurende het hele proces van toevoegen van vertices en vastklikken aan overeenkomstige lijnfeatures. Wanneer klaar kun je de geconstrueerde features bouwen zoals je normaal zou doen.<\/P>
<\/P>
Na verdere tests ontdekte ik dat als ik de 'Classic Snapping' omgeving inschakel die je toestaat te bepalen welke lagen en feature types in je TOC beschikbaar zijn voor snapping (in tegenstelling tot de nieuwere standaard snap-omgeving waarin alle lagen altijd snap-enabled zijn), en ALLE lagen uitschakel voor snapping, het prestatieprobleem verdwijnt. Op dit punt dwingt de Fabric nog steeds af om naar zichzelf te snappen (wat noodzakelijk is), zelfs wanneer alle lagen zijn ingesteld om niet te snappen. Het moment dat je echter de Lines FC inschakelt, stopt de prestatie abrupt.<\/P>
<\/P>
Interessant genoeg doet dit gedrag zich NIET voor in een FGDB. Dit leidt mij tot de conclusie dat er een unieke interactie is tussen ArcMap, SDE en de Oracle database als het gaat om de data-intensieve Lines FC. Ondanks dat ESRI verschillende aanvullende manieren heeft geboden om direct (via SQL) opnieuw analyses uit te voeren op de Fabric tabellen en ruimtelijke indexen te regenereren, enz., is er geen verbetering bereikt, noch heeft iemand (via SDE Intercept en Oracle trace-bestanden) enige duidelijke bottleneck geïdentificeerd... Dit is GEEN I/O probleem, noch lijkt het een SQL verwerkingsprobleem te zijn.<\/P>
<\/P>
Ik keer terug naar mijn zorg over het enorme aantal records in de Lines feature class, maar heb geen manier om te onderbouwen hoe/waarom/als dit een geldige zorg is. ArcMap lijkt duidelijk moeite te hebben met realtime interactie met de Lines data, maar ik kan hier geen functionele verklaring voor geven behalve mijn observaties. Duidelijk creëert de FGDB zijn eigen soort ruimtelijke indexen en dergelijke op deze grote feature class, maar draait toch soepel. Ter vergelijking zou Oracle zelfs robuuster moeten zijn en zou het moeten kunnen omgaan met een datatabel met slechts 3 miljoen records – toch is hier de prestatie erbarmelijk slecht. Dus blijf ik terugkomen op iets wat de applicatie doet, en niet alleen aan de database zelf ligt.<\/P>
<\/P>
Als iemand soortgelijke ervaringen heeft met of inzicht in dit probleem, zouden we dat zeer waarderen!<\/P>
<\/P>
Gavin<\/P><\/BODY><\/HTML>
