parcel fabrics vs. coverages vs. COGO editing

Discussion created by clarkecountyva on Mar 30, 2012
Latest reply on Feb 4, 2013 by arobinson-esristaff
I am trying to figure out how to move forward with our parcel editing.  Historically, our county has used coverages, which I learned when I got here.  Naturally, we wanted to move forward with something based in ArcMap instead of the old ArcEdit.  Parcel fabrics seemed to fit the bill.  It looks great on paper.

Conceptually, parcel fabrics is well thought out and practically sells itself.  It tracks historical parcels, maintains topology, fits parcels to the fabric or the fabric to the parcels, saves COGO and other survey attributes, and offers a weighted least squares adjustment of the fabric based on surveyed control points.  In practice, our experience with parcel fabrics has not lived up to the promise.

Our troubles with fabrics began early.  When editing I noticed that many of the fabric editing tools were grayed out, that I did not think should be grayed out.  So I called ESRI tech support.  As it turns out they should NOT have been grayed out.  Tech support had me try performing a "factory reset" by renaming my Windows registry key that contains ESRI settings as well as renaming the directory in my Windows profile that contains ESRI settings.  This did not fix the problem.  Ultimately, we determined that I had to create a new Windows profile to fix this problem.  This cost me about a day due to all the settings stored in the Windows profile for the many applications we use.  (Regardless, I must say that ESRI has the best tech support I have ever encountered.)

After fixing this initial problem, things seemed to be going more smoothly.  I entered about a dozen simple parcel subdivisions.  Then I got to a more complicated one.  The line work for the neighboring parcels was old, digitized from 19th century tax maps.  Of course the new subdivision had a modern survey.  So I assigned it a high accuracy, whereas its neighbors have a low assigned accuracy.  When I joined the parcel to the fabric, it stretched the parcel to the 19th century line work.  Whoops.  Okay, so I unjoined the parcel and re-joined it keeping the parcel lines fixed.  It took about 5 minutes for the join, but it looked much better as it conformed the fabric to the new line work.

But then I noticed something.  Some of the line work looked a little ragged.  I had recently changed the parcel boundaries to use a 1 point-line for symbology instead of the default fat line that the fabrics system uses.  I zoomed in on the fabric and noticed little slivers and gaps between the newly joined parcel and the neighboring parcels.  I searched the Land Records forum, and found this gem:  Apparently, gaps of 100 cm or less are considered acceptable in the fabric "topology".

Now, you might consider it a little anal retentive to take exception to these gaps and slivers in the fabric "topology."  However, consider that we have an online mapping application for our county that uses thin lines for the parcels.  The fabric line work is not going to look good in our online system.  I went back and inspected the other dozen or so subdivisions that I had entered, and every one of them had at least one instance of slivers and gaps in the line work.  Not only that, but the problem is worse for curves.  I tried matching up the chord length and the radius for the curves between the adjacent parcels and re-joining them.  Even choosing the ends of the arc as join links would not match up identical curves shared between adjacent parcels.

Let's get back to my complicated parcel where I had the fabric conform to the parcel lines.  This was apparently a poor choice as it really broke the fabric system around this parcel.  It caused multiple data corruption issues.  For one thing, all of the line work in that parcel was duplicated in the COGO attributes.  So for every line segments, there were two segments with the same start and end points.  Furthermore, unjoining and re-joining this parcel to the fabric ceased to function correctly.  The system would spend 5 minutes trying to join the parcel on a 2.8 GHz core i7.  Then it would silently fail.  It would not display any error messages, but when it was done, the parcel was still unjoined.  It took about 20 tries and an entire afternoon to get the parcel re-joined.

Some of the join attempts did not silently fail.  After some attempts, the parcel was mangled into a weird figure eight sort of thing that was a rectangle and a triangle joined at one corner.  Still, not the sort of thing you want.  The coup de grace was when joining finally corrupted the scaling.  Although the parcel looked properly joined, whenever you unjoined it from that point forward, it would shrink so that it no longer fit the fabric.  Somehow the joining system corrupted the scaling property of the parcel so that it had a scaling of 0.77 in its properties, although the parcel had been joined at full scale.  Did I mention that you cannot simply edit the scaling field of the parcel in the attributes table?  Apparently it is some kind of protected property that the fabric system manages.

My next inspiration was to try and correct some of the slivers and gaps in some of the less complicated parcels by putting in some control points and doing a fabric least squares adjustment.  That resulted in slivers and gaps that were way bigger than 100 cm.  Now I had parcels that overlapped their neighbors by about 10 feet on some of the lines.  Strike that notion.  The least squares adjustment seems even buggier than joining a parcel.

Finally, we contacted a neighboring county to find out about their experiences with fabrics.  As it turns out they get all their submissions in the form of CAD line work.  However, they don't use the parcel fabrics system as ESRI intends it to be used, as they freely admit.  Instead of relying on it to do its magic to match up parcel boundaries, they bypass all of those features.  What they do is export the parcel to be edited and all of its neighbors from the fabric.  They do the line work outside of fabrics and match up the adjacent parcels with the new line work.  Then they re-import all those parcels back into fabrics.

In summary, the parcel fabric systems seems to work acceptably for simple, rectangular style, parcels.  Unfortunately, we have a lot of more complicated parcels in my county, due to complicated topography.  In the end I had to go back to editing in coverages.  I could not export my fabrics back into a coverage because the fabric system had mangled the topology so badly.  Sure, I could have done a "clean" operation in the coverage, but that would have just averaged the mangling between adjacent parcels.  In the end, I had to re-enter all of the subdivisions into coverages.

Now you might argue that I should have filed a support incident for each and every one of these bugs and worked with tech support to try to resolve each one.  However, we are a small county in a time of lean local government.  I am the GIS department.  Not only that, I am half of the IT department.  Learning fabrics already cost me more time than I could afford.  The fabric system has existed for a couple of ArcGIS releases, so I expected it to simply work.  What I am seeing is something that is at best beta quality in a released product.  I do not have the luxury of enough time to work as another company's test engineer.  Frankly, I feel somewhat burned by ESRI, although I will get caught up, eventually.

I am really not sure where to go from here.  In the short term, I have a backlog of parcel edits that have to get done and exported for our online mapping.  I am doing this in coverages.  Perhaps I will get caught up by the time ArcGIS 10.1 ships.  Then, maybe we can re-evaluate parcel fabrics to see if it is release quality, yet.  Maybe my time would be better served learning the COGO tools in ArcMap.  What do other people think?  What are your experiences with fabrics and/or the other COGO tools in ArcMap?  What is the best approach to parcels in ArcMap?