POST
|
I am not sure I would count John's story as a success, yet. As he says, "We have been in pilot phase for about 6 months now and look to moving our editing to production after the summer." He seems confident, however, so I would count that as a plus for fabrics. My real concern in seeing the two testimonials here is that both of these localities have teams of parcel editors. Again, we are a small county with approximately 10,000 parcels--an order of magnitude smaller than Denver with 450,000 parcels. We do not have the resources for a 6 month (or longer) trial of the fabrics. Ideally, a solution should just work without a lot of workarounds. In any event, we have entered the 10.1 pre-release program, and will look at fabrics again, time allowing. Rob
... View more
05-02-2012
08:41 AM
|
0
|
0
|
263
|
POST
|
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: 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. 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. 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. 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. 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. 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). 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. 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). 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. 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. 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
... View more
04-25-2012
10:55 AM
|
0
|
0
|
980
|
POST
|
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
... View more
03-30-2012
06:50 AM
|
0
|
12
|
5061
|
POST
|
Hi, I have worked through the web training courses "Introduction to Editing Parcels Using ArcGIS Desktop 10" and "Managing Parcel Data Using ArcGIS Desktop 10." I have managed to import my coverage data into a parcel fabric using the "load a topology to a parcel fabric tool." I am trying to do my first task, which is something that is really common in my county, but is not addressed in the training. In this instance I have a fairly complex boundary line adjustment between two parcels owned by the same person. I have COGO attributes for ONE of the parcels from a new survey. The other parcel was digitized from old tax map data and has not had a modern survey. I have figured out that I can unjoin the parcel with the modern survey and COGO in the new lines. Now, how do I edit the other parcel--which lacks a modern survey-- in order to follow the new boundary line of the other parcel? Is there a trace tool? What is the best way to accomplish this? Thank you. Robert W. Fuller Clarke County, Virginia
... View more
02-25-2012
03:06 AM
|
0
|
1
|
2328
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|