parcel fabrics vs. coverages vs. COGO editing

4977
12
03-30-2012 06:50 AM
GordonRussell
New Contributor
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:  http://forums.arcgis.com/threads/27097-Avoiding-gaps-and-slivers-in-the-parcel-fabric.  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?

Rob
Tags (2)
0 Kudos
12 Replies
AmirBar-Maor
Esri Regular Contributor
Hello Rob,
I am happy to hear you have decided to move forward with your parcel editing technology. You should find it relatively easy to migrate from coverages to the parcel fabric from quality and conceptual aspects. Moving forward from the old ArcEdit and learning to edit parcels in ArcMap required a learning period, but I am sure you will find it more efficient and productive once you have mastered it. Many users have performed similar analysis prior to migrating to ArcGIS and are currently successfully using the parcel editor to maintain their parcels. We are always interested to get feedback in order to improve our software.
Here are a few recommendations\observations:

  1. When you open a tech support incident, please be sure to inform the technical analyst your issue has to do with the Parcel Editor toolbar\Parcel Fabric. This will not only get categorized properly but also be addressed and reviewed by the right person.

  2. You�??re inability  to start construction from the plan directory is most likely to do with having an open parcel �?? use the Parcel Detail window and make sure to use the red X button before starting a new construction. Another reason might be having parcels that point to a plan that does not exist (most unlikely - this will not happen if you follow best practice). The best thing to do would be to contact tech support and provide a screen shot that shows which tools are disabled. It would also be good to know if you can edit other fabrics, such as the Tax Editing Map from the resource center in order to figure out if this issue is data related.

  3. Joining is all about getting the correct links established. The links ensure correct topology. If you miss links your topology will not be correct and you might see slicers and gaps. Any line point that is more than 100 cm (3.3 feet) from a line will not be snapped to the line (leaving a gap) �?? can be change in the registry. If you intend to run adjustment (LSA), it is irrelevant which join mode you are using as LSA is using your record measurements and accuracy to find the best position (a solution with minimal weighted residuals). Joining is about TOPOLOGY. LSA is about ACCURACY.

  4. Before migrating to the fabric read and follow the data migration white paper (http://www.esri.com/library/whitepapers/pdfs/loading_data_parcel_fabric.pdf). If you import data that has bad record measurements (COGO), you should expect to encounter issues when you join and\or run LSA.

  5. Slivers are usually an indication you missed links. Submit the data to tech support if you feel you found a bug in the system and we can have a look and provide recommendations. You will also find in the next release (10.1) improved functionality to generate the links and the ability to bend �??straight�?� lines if they are joined to a bent line.

  6. QA (�??three lines of defense�?�): After you COGO a new parcel make sure it has a reasonable closure (QA1 �?? identify bad COGO on entry), then examine the residuals during join (QA2 �?? identify issues with surrounding parcels or new parcel) and lastly, if you run adjustment, you can identify lines with big residuals (blunders).

  7.   Use the latest release (currently 10.0 SP4). We continue improving our software between releases and every service pack is geared to fix bugs as well as improve the functionality. Since you are preforming your analysis now, release 10.1 is a few months away and you can test it if you join the beta program.

  8. Following best practices would put you on the right pass. If your neighbor county opts to edit parcels outside of the fabric, and freely move boundaries around, not only do they make the process highly inefficient, but introduce errors and future challenges (easily seen after the next high resolution imagery is acquired and compared against the parcels).

  9. If you are seeing a scale of 0.77 it indicate you have issues with you measurements and\or joining process. The scale factor should be around the ground to grid value.

  10. Many counties are using the parcel fabric to manage their parcel data which contains complex geometries. There are many resources available, from the tutorials in the help documentation to videos that demonstrate how to work with the software.

  11. Please submit a tech support with your data and screenshots of the issues you are having and we will be happy to examine them.

Amir
0 Kudos
PaulBushore
Occasional Contributor
Hello,

Well said Rob, I am currently reviewing the options available for us to move forward and I am taking a look in to the Parcel Fabric as well as the other option you spoke of, exporting the parcels in to plan-specific geodatabases, doing the editing there, and re-importing in to the fabric exactly because of the possible issues you brought up.  This is the process others I have spoken to have taken as well.  I would like to hear from some people that have successfully implemented the Parcel Fabric, especially those that have been able to do it with minimal technical support from ESRI. I am particularly concerned over the "gap" of 100cm and having to change a registry key to change it.

Will keep looking in on this discussion and will try to add what I can.

Amir, I took Rob's post to say that he is NOT moving forward with the Parcel Fabric...but rather reverting back to editing coverages.
0 Kudos
GordonRussell
New Contributor
Amir,

This is a lot of good information for a beginner, and perhaps belongs in some kind of FAQ.  Thank you for taking the time to reply.

Here in Clarke County, we are not exactly beginners.  We invested some time importing our parcels from coverages and learning to use the fabric system.  We worked through both of the online training courses, "Introduction to Editing Parcels" and "Managing Parcel Data."  We also read the online documentation.

We stumbled across the data migration white paper while trying to import data into the parcel fabric.  Had we not, we never would have managed to get our data imported into the fabric system.  I am not sure what you mean by, "If you import data that has bad record measurements (COGO), you should expect to encounter issues when you join and\or run LSA."  Do you mean that the parcel fabric system cannot deal with older surveys, perhaps from the 19th century?  If so, that is a bit of a problem for our county.  Some of the parcels are old family or horse farms that have not had modern surveys.  Our county is not in a position to pay for the survey of these old parcels, nor force the owners to do so.

As for your comments on our inability to start construction, tech support did of course think of such things as a parcel being open.  They remoted into our system to observe the problem for themselves.  It was not a matter of user error, but some broken cruft somewhere in the Windows user profile. The baffling part of it was that renaming the ESRI registry hive and ESRI's directory in the profile was inadequate to solve the problem.  We had to create a new user profile.  In the end, the tech support guy decided to close the incident, and did not want a copy of the broken profile.  Obviously, they have seen this sort of problem before, or they never would have suggested trying a different profile.

As for joining, we do understand the difference between this and the LSA (using control points.)   As I said, it was an inspired stab in the dark to try and work around a bug in joining by using the LSA.  Unfortunately, it did not fix the sliver problem.  It in fact made it far worse.  The slivers we have been seeing are on the order of a few centimeters.  They show up especially on curves, even when both ends of the curves are used as joining points (and the chord length and radius of curvature is matched between the adjacent parcels.)  I am glad to hear that there may be some improvement in this in 10.1.

As for having the latest service pack for ArcGIS, we are using service pack 4.  We never would have seen the bug that duplicates or triplicates parcel lines had we not been on service pack 4.  As I later discovered from the weekly Parcel Fabrics Forum, that was introduced with service pack 4, along with some other bugs.  The advice we got was to revert to service pack 3, although we have not done so since we are no longer using the parcel fabric system.  We also tried to join the beta program, but could not seem to download 10.1, perhaps because it is so close to release.

Finally, on that scaling item, it was a parcel that had been rejoined a couple of times in order to attempt to fix some slivers. The parcel had no scaling the first couple of times it was joined.  Somehow the scaling got corrupted after multiple rejoins.  Because it was joined with a scaling of 1.0, but had an incorrect scaling of 0.77 in the attribute table, whenever you unjoined it from that point forward, it would shrink to 3/4 of its joined size.  There was no way to fix this because the scaling factor is a protected field (and the fabric system is presumably not supposed to corrupt it.)

In the end, our overall impression is that the fabric system is very ambitious.  It has everything we would want in a parcel system.  Unfortunately, there are so many bugs to work around, that it is much more efficient for us to edit in coverages.  I have to wonder if parcel fabrics do not suffer from second system syndrome.

Rob

Hello Rob,
I am happy to hear you have decided to move forward with your parcel editing technology. You should find it relatively easy to migrate from coverages to the parcel fabric from quality and conceptual aspects. Moving forward from the old ArcEdit and learning to edit parcels in ArcMap required a learning period, but I am sure you will find it more efficient and productive once you have mastered it. Many users have performed similar analysis prior to migrating to ArcGIS and are currently successfully using the parcel editor to maintain their parcels. We are always interested to get feedback in order to improve our software.
Here are a few recommendations\observations:

  1. When you open a tech support incident, please be sure to inform the technical analyst your issue has to do with the Parcel Editor toolbar\Parcel Fabric. This will not only get categorized properly but also be addressed and reviewed by the right person.

  2. You�??re inability  to start construction from the plan directory is most likely to do with having an open parcel �?? use the Parcel Detail window and make sure to use the red X button before starting a new construction. Another reason might be having parcels that point to a plan that does not exist (most unlikely - this will not happen if you follow best practice). The best thing to do would be to contact tech support and provide a screen shot that shows which tools are disabled. It would also be good to know if you can edit other fabrics, such as the Tax Editing Map from the resource center in order to figure out if this issue is data related.

  3. Joining is all about getting the correct links established. The links ensure correct topology. If you miss links your topology will not be correct and you might see slicers and gaps. Any line point that is more than 100 cm (3.3 feet) from a line will not be snapped to the line (leaving a gap) �?? can be change in the registry. If you intend to run adjustment (LSA), it is irrelevant which join mode you are using as LSA is using your record measurements and accuracy to find the best position (a solution with minimal weighted residuals). Joining is about TOPOLOGY. LSA is about ACCURACY.

  4. Before migrating to the fabric read and follow the data migration white paper (http://www.esri.com/library/whitepapers/pdfs/loading_data_parcel_fabric.pdf). If you import data that has bad record measurements (COGO), you should expect to encounter issues when you join and\or run LSA.

  5. Slivers are usually an indication you missed links. Submit the data to tech support if you feel you found a bug in the system and we can have a look and provide recommendations. You will also find in the next release (10.1) improved functionality to generate the links and the ability to bend �??straight�?� lines if they are joined to a bent line.

  6. QA (�??three lines of defense�?�): After you COGO a new parcel make sure it has a reasonable closure (QA1 �?? identify bad COGO on entry), then examine the residuals during join (QA2 �?? identify issues with surrounding parcels or new parcel) and lastly, if you run adjustment, you can identify lines with big residuals (blunders).

  7.   Use the latest release (currently 10.0 SP4). We continue improving our software between releases and every service pack is geared to fix bugs as well as improve the functionality. Since you are preforming your analysis now, release 10.1 is a few months away and you can test it if you join the beta program.

  8. Following best practices would put you on the right pass. If your neighbor county opts to edit parcels outside of the fabric, and freely move boundaries around, not only do they make the process highly inefficient, but introduce errors and future challenges (easily seen after the next high resolution imagery is acquired and compared against the parcels).

  9. If you are seeing a scale of 0.77 it indicate you have issues with you measurements and\or joining process. The scale factor should be around the ground to grid value.

  10. Many counties are using the parcel fabric to manage their parcel data which contains complex geometries. There are many resources available, from the tutorials in the help documentation to videos that demonstrate how to work with the software.

  11. Please submit a tech support with your data and screenshots of the issues you are having and we will be happy to examine them.

Amir
0 Kudos
AmirBar-Maor
Esri Regular Contributor
There are many users who have migrated to the parcel fabric on their own without any help from Esri. Since Parcel Editor is part of ArcGIS Desktop and does not require additional license, it is hard to tell how many users have migrated without Esri�??s support. Migrating to the ArcGIS Solution for Land Records usually requires the following:
1.       Data migration �?? this is not rocket science but in order to achieve the minimal quality requires for data migration, this process requires analysis and some form of cleanup. Migrating from coverages (or polygons) is usually easier than migrating from lines (CAD).
2.       Basic ArcGIS Training - users need to get familiar with ArcGIS Desktop and Enterprise Geodatabases, including versioning.
3.       Parcel Editing �?? The Parcel Editing feature dataset (and the Parcel Fabric) included with the Local Government Information Model is configured to streamline your editing workflows. Plenty of resources are available including the Tax Parcel Editing Map and videos. These workflows will be made even easier in version 10.1.
4.       Local Government Solution - instead of spending time to develop a unique data model and maps, the solution is ready to use and allows users to focus on the above rather than �??inventing the wheel�?� over and over again. This solution is based on best practices and has already been implemented by many. The solution offers many maps and apps, for desktop, web and mobile and will continue to offer more resources and improvements in the future.
5.       Technical support �?? if you find any issue in the software, please contact technical support. If you think the solution or the software should work differently to support your workflows, we are always happy to listen and improve.
The tools are designed to work with old surveys from previous centuries that have low accuracy. This is taken into account when running least squares by giving lower weights to lower accuracies. By Bad Measurements\COGO I mean really bad values where the geometry is far off from the stated length or bearing. This is sometime caused by splitting a line and not updating the length. Look at these tools to help identify those geometries. I cannot determine the cause of your slivers and scaling without examining your data. I can only guess bad measurements and links could be causing it. You might also want to convert your multi-segmented curves to true curves before migrating them to the fabric. You will have to submit a tech. support incident and attach your data for someone to have a look and determine the cause.
I am attaching a document with links to useful resources in version 10.0.

We will also be happy to talk with users in the upcoming user conference in San Diego to learn more about any difficulties and how we can improve.
0 Kudos
KyleConboy
New Contributor II
I work for a county who also is looking at making the move to the parcel fabric.  I've just started the process and was excited at the potential but now after reading the above posts am leery of moving ahead. 

Can Abarmaor provide us with the numbers of localities using the parcel fabric or some success stories?

Rob and pmbushore thanks for your posts and can you guys post more as you go along.  It would be appreciated by someone who is a little behind you in the process.
0 Kudos
AmirBar-Maor
Esri Regular Contributor
Dear qwerty123,
There are dozens of successful migrations stories to the ArcGIS Local Government Solution for Land records .
It would be inappropriate to publish their names & contact data without getting their consent.
I would appreciate if customers directly respond and share their success stories.
Amir
0 Kudos
JohnFell
Occasional Contributor III
All,

After reading about your frustrations in your forum posts I can understand why you might feel like things are hopeless. I think it is easy throw your hands up in the air when you come against so many obstacles.
I've spoken with others who have expressed concerns about how to get their data into the fabric and use it effectively to maintain and improve their parcel data. For the past few months a group of individuals using the parcel fabric or those who are interested in using it have been meeting to discuss solutions to some of the issues they face. They have also talked about things others have learned sharing editing tips and good practices. It has been a great group and I have learned a lot in participating.

I can tell you about how we decided to go to editing in the parcel fabric when considering how to move forward in maintaining our data. We have been editing parcel data for about 10-12 years now. We have been editing in coverages since then. With the news of ArcInfo Workstation going into mature support early in 2012 we knew we had to start making decisions about how we would maintain our parcel data in the future. We spoke with a consultant about developing custom tools to help us leverage ArcMap editing of geodatabase feature classes. When considering this possibility we realized that ESRI was going to support the parcel fabric as a medium for maintaining parcels in future releases. The parcel fabric data model had many desirable qualities for us:


  • Ability to track history on parcel changes

  • Ability to maintain topological integrity through internal rules (much like in the coverage editing environment)

  • It was an out of the box solution that would not require additional consulting fees or maintenance costs

  • Least squares adjustment provides the option to improve fabric data as new control is imported in

Given these and other factors we decided to move towards the parcel fabric solution.

I can honestly say that importing our data into the fabric took some planning. We had to learn about the fabric data model. Our staff had to be trained not only in editing in the fabric but in editing in ArcMap as well. Previously they had only used ArcMap as a viewer. We worked closely with ESRI staff that was patient and understanding and willing to help us 110% to find an answer to our problems. Anytime we had an issue we would contact ESRI tech support or one of the developers of the parcel fabric. We had to have regular meetings on how our current workflows would translate into the fabric editing environment. We had a few hiccups such as one described earlier. Our data was not perfect. Bearings had been inversed on a number of lines and the topology loader geoprocessing tool read these in as bad COGO attributes. Amir provided a tool that helped us find any COCO bearings that were not matching up to the shape attributes properly based on a specified tolerance. Also we had a lot of subdivision lines that did not line up with the parcel or lot lines. This caused problems with the joining process. ESRI staff counseled us on pros and cons of how to address the issue. We have since come to a work around that has helped us better solve the problem. Many times we had bugs come up but ESRI staff was working diligently to get the bug issues address either with a hotfix or in the next service pack to be released.

We started our system in a development environment so our production system was not touched while we tested the fabric. We have been in pilot phase for about 6 months now and look to moving our editing to production after the summer. Some of the benefits we have seen from moving to the fabric already have been:


  • Editors have said that the editing workflows are more efficient

  • We were able to do away with maintaining annotation and are now strictly using labels to display dimensions, lot, and block numbers

  • The parcel history tracking component will allow us to work year round rather than having to stop during the summer months due to the Annual Review Board

Again, from time to time we do have problems and incidents come up. But we remember why we moved in this direction, contact ESRI tech support, and keep regular backups of our data. I don't regret moving our data to the parcel fabric and feel like it will not only improve the quality and quantity of our editor�??s work but over time it will just get better.

Suggestions I would make to anyone interested in the parcel fabric as an option:


  • Contact your ESRI sales rep to let them know of your interest. They will help you stay in touch with those that can help find answers when there are many questions.


  • Remember that there are many who have implemented this and are successfully using it.


  • Begin your implementation in a development environment. Only move your production editing to the fabric model after all testing is complete.



  • Become familiar with how your data might fit into the Local Gov't Data model and try to conform as much as possible to it.



  • If you have an issue, error, or slowdown in your workflow contact ESRI tech support, your sales rep, or write to the fabric forum. Carefully document what you were doing when you got the error.


Look into the parcel fabric as a good long term investment in your parcel data. I'd be more than happy to talk to anyone that is interested in trying to use the fabric or to answer questions.
0 Kudos
DouglasGenzer
New Contributor II
Hi All,
I�??m weighing in from the City and County of Denver.  Sure, we�??ve also run into our share of bugs with the Parcel Fabric, but things are running smoothly for us these days.  We converted from ArcInfo Region Coverages,  have worked through the data issues that crop up, and have always found a solution.   We had challenges with editors learning the software, but now they are all up-to-speed.  We have over 450,000 lots, parcels, and subdivisions in our deployment.  Three separate agencies (Survey, Assessment, and Enterprise GIS) have access to the data.  We use Workflow Manager to handle versioning and this has drastically improved communication and coordination between the agencies (email notifications).   If anyone wants to hear about our experience in more detail, feel free to contact me directly at douglas.genzer@denvergov.org

Doug Genzer | Senior GIS Analyst
Technology Services - DenverGIS | City and County of Denver
0 Kudos
KyleConboy
New Contributor II
Thanks to John, Doug, and Amir for your replies.  It helps to hear about some success with the parcel fabric.  Did you guys encounter the gaps that were mentioned above.  if so, what was your workaround? 

I'm from a small county who only has ~ 14,000 parcels.  We have been updating our parcels since 2003 using an Autocad/ESRI solution setup by a third party consultant.  All of the COGO work, annotation, tax map printing is done in Autocad.  A coverage is created at the end of the process with some QA/QC checks done in ARCINFO.  Due to the third party software we are currently using we are still using ARCINFO 9.3.1 but are hoping to upgrade to 10.0 over the next couple of weeks.  I've read all the professional articles and the white paper and am at the point where i guess i need to setup a test of the local govenrment model/parcel fabric when we make the switch over.
0 Kudos