Latest Contributions by TimHodson

Hi Betty, The problem with the Control point moving when joining has been fixed, and was also released in a patch for 10.3. Do you have the latest patches installed? See: Patches and Service Pack - Esri Support Also, the message about the radial lines is a known problem, but it does not affect the end result, the message is just incorrect, and it typically occurs when there are origin connections attached to the parcel. That is also fixed in 10.4. Regarding the problem of the bends in the lines; is there any rotation on the parcels? Also, you inferred that for some of the lines you do not have record values. For those, did you set the line accuracy to a 6? If you have concerns about one, some, or all of the radial lines within the cul-de-sac, then you could set one or more to accuracy 7, and see if that improves the result. If necessary and in order to maintain the structure of the cul-de-sac, you could also set ALL the radial lines in the cul-de-sac to accuracy category 7, but then work out the correct radial bearing and distances, and add 3 or 4 connection lines to serve as radial lines. When creating connection lines, the bearings always go in a direction outward, away from the parcel, and be sure to make the bearings on the connection lines be relative to the parcel that they are connected to. (Related note, for origin connections the bearings go the other way, 180 degrees different, lines proceed in sequence in towards the parcel.) Do you notice high computed minus observed (c-o) residuals, and what are you using for your Distance Residual Tolerance? You could start to set that tolerance lower, until you force it to report a failure, so that you look for the '##' again as it may provide some clues. Also check if you have any Close points reported, and if you do you can use the mean points tool to merge them. Also take a look at long lines that are not boundary lines, because error/mistakes in those lines are magnified compared to the shorter lines, and they also don't show up in the parcel misclose information. Double-check to make sure their distances are in ground, and confirm that their bearings are a match with the rest of the parcel relative to the parcel's rotation. One quick way to do this is to open the parcel with a long connection line and use measurement view to see if the line goes off at an unexpected angle. Are there any multi-part parcels, or parcels with inner rings (donut parcels)? If so check the part connector bearings. Also, regarding the control points. The bending of the lines could be due to an ill-fit with the control points. How many control points and parcels in this adjustment? You can do a check-fit on the control dialog to see if there are any significant outliers in the control points. Find the largest outlier, de-activate it, then re-run the check-fit. This way you can try to find any potential problem control points. This is does not work as well for parcel data that has a lot of initial distortion. It's not necessarily a good idea to de-activate multiple control points at once, so if you find a possible bad control points, de-activate just the one with the highest residuals from the check-fit, then run the adjustment...etc. If you discover that although you know you have entered all good record bearings/distances, that somehow the system generated lines (that were not directly COGO'd) are inconsistent with the data you actually COGO'd, then take a look at the add-in called The Parcel Fabric Quality Control. The add-in will allow you to filter for big outliers, and inverse bearings and/or distances based on your filter settings, so as to keep the good/original entered record data intact. Of course, when inversing data proceed with caution(!) since it works off geometry, and so if the geometry is distorted the inversed data will not be as close to record as you'd like. The Parcel Fabric Quality Control add-in is here: http://arcg.is/1nRHU30  Once you've installed the add-in click the help button on the toolbar to see the details about how to use the different tolerances. -Tim ... View more

Ryan, The jobs are used for handling the multi-user environment implemented for parcel fabrics. Once the edit in a version has been reconciled and posted, the jobs are committed. Committed jobs have a limited role and serve only as a way to track parcels that had been edited, but this (parcel edit tracking) can also be achieved by standard editor tracking. Committed jobs can be cleared without adversely affecting the parcel fabric. If you are on 10.4 and are using SQLServer, then you may benefit from improved performance by clearing committed jobs from the job book. To learn more about that, please see the thread in this post: 10.4 Parcel Fabric processes have slowed considerably -Tim ... View more

Mike, Thanks again for reporting this, and for sharing your data via tech support. I'm responding again here to share findings with other customers who may have experienced similar issues with SQLServer. The delay was caused by a combination of 2 things: some changes made to the cursor model for 10.4 on SQLServer, and the Uncommitted records (Status=0) in the jobs table. The latter records are accumulated when editing directly against default, instead of in a version. We recommend editing in a version since posting the version will automatically commit the job for you (Status=1). If there is a need to edit directly on default, then after the edit we'd recommend manually committing the job afterwards. To clear out the jobs table, you can un-register the fabric as versioned, then use the Delete Fabric Records add-in 's Truncate command to "Drop all fabric jobs" -Tim ... View more

Betty, Thanks for starting this discussion. It sounds like you’ve made a good start by updating your lines to the original record data. Having the adjustment fail when first running it is fairly normal/expected; the reported results can be used for QA and to better understand your data, and to choose a Distance Residual tolerance, as described below. Of course you should not expect to see things in the report get worse after making changes to the parcel data. I’d like to help you figure that out, and I may contact you to get your data, but in the meantime here are some answers to your questions. With fabric adjustment you’re making a best fit of all the record data by matching it to the control points. The adjustment will create a balance between the control point positions of a few good known locations in a network, and the COGO record values on all of the lines used in that adjustment. If there is a significant mismatch in making this balance, it could be due to one or more of the control points, or one or more of the record distances or bearings. The control point may be out of sync if it is not referenced to the correct fabric point. I’ll go through the information that is important for the adjustment, and the attributes that affect the adjustment versus attributes that do not directly impact the adjustment. The following attributes impact the adjustment directly: Accuracy (on plan, parcel and lines tables), Bearing, Distance, Radius, and Category, (on lines) the X Y Z coordinate attributes (on control), and true-mid-bearing flag (on plans). All the other attributes are computed information, or are non-spatial cadastral information. The line category attributes are related to parcel structure (example boundary lines, connection lines etc.); the adjustment will report parcels without the correct structure, but it is not very common to run into this problem. For the plan table, the accuracy value is required, and it has a direct impact on fabric adjustment results. Aside from true-mid-bearing setting, it’s the only attribute for Plans that can be changed to affect adjustment results. You should set that accuracy to the level that matches the survey date of the subdivision/plat/deed etc. (see doc). Similarly, for parcels, the accuracy category is the sole attribute that will affect adjustment, however the attribute is null by default and the accuracy is inherited from the plan when running an adjustment. You will most likely not need to manually add an accuracy value to the parcel, unless you want to explicitly over-ride the value inherited from the Plan (this should be rare). Also for lines, accuracy category is null by default and is inherited from the Parcel or Plan, but it can be set directly for a line in order to over-ride the value it’d otherwise inherit. (Setting accuracy on a line is a bit less rare, see tips below on Accuracy values.) Tips on using Accuracy category values (1 through 7) Setting lines to accuracy 7 is like removing the line completely, so while this is OK for some lines, for others it may be a problem as it could weaken the network, or break network connectivity. In general, setting accuracy should be done at the Plan level, and should be set based on the date of survey, as defined in the accuracy table description (see doc: About accuracy—Help | ArcGIS for Desktop ) You typically should not have to change accuracy on individual parcels or lines. However, if you’d like to reduce the influence of a particular line to the lowest possible without breaking connectivity, then use accuracy category 6 instead. More about accuracy category 7: There are some valid cases for setting accuracy 7, such as for long lines that you did not directly COGO in, such as radial lines that are not part of a cul-de-sac, or part connector lines that are (typically) system generated, but as mentioned, be aware that this can break connectivity. Tips on control points Add elevation data to the control points. Make sure that the control points that you are using have elevation values (z values) populated. They do not have to be very accurate elevations, so if you have control points that do not have a Z, then you can add the standard topographic base map to your map, and use the elevation from the nearest topographic layer contour, nearest spot height, or bench-mark. Note that the units of the elevation may have to be converted when using this technique. This is important because the record distances are presumed to be ground values, and the adjustment will use the elevation information on the control points to compute the combined scale factor. Without this factor applied, you are more likely to have lines that are detected as outliers, even though they are actually good record values. The distribution of the control points should not be such that the control is bunched together in one area of the network. Rather they should be well distributed and, as a very approximate rule of thumb, ratios of control points to parcels can range between 1:20 to 1:200. Tips on overlapping parcels When you have Lots and Units, and the Tax Parcels are a direct duplicate of these Lots and Units, and share the same points, then it is not necessary to select the lots as well as the tax parcels when running the adjustment. This just increases the amount of data that the adjustment processes. Although it is important for there to be lots of redundant information in the adjustment, it is not meaningful if it is just duplicated overlapping lines, with the same record values. Since the fabric points are shared between the lots and tax parcels, all parcels connected to those points will still be adjusted even though they may not have been directly participating in the adjustment. So for these cases you can choose to minimize what the adjustment processes by turning off selection for the layers that have the duplicate parcels, and only selecting the Lots, for example. Tips on Connectivity and line categories Sometimes you can have data where there are fabric points very close together and that are not connected with a line. These points should be averaged/merged using the mean point tools, or else the parcel should be re-joined so that this connectivity is created. Tips on reading the report After running the adjustment, it’s useful to temporarily save the report file, and refer to it when going back into the data to check on the reported items, and make changes as needed. As mentioned before, the adjustment report is a good way to QA your data, and find possible data entry problems, or connectivity (topological) problems. The double hash “##” next to a value in the report indicates that the record value for that line does not match well with the other measurements in that part of the network. This means that there may be a possible mistake in the data at this location, such as a mistyped bearing or distance, or a transposed number on the actual record, and so on. If you see the “##” next to bearing values, then it is likely that it is a radial line, a connection line, origin connection line, or a part connector line that has a bearing that does not have a correct bearing with respect to the parcel it’s attached to. This can happen when there is a rotation on a parcel. Tips on the adjustment tolerance The Distance Residual tolerance is the value that is most typically changed to get an adjustment to complete. The default value is 0.348 feet (0.1meters.) If you see a ‘##’ next to a distance value, look at the residual value, and divide by 3. This is a rule of thumb for determining an initial value to use. However, if you find you are making this value very high (more than 25 feet) then there are likely other problems that need to be resolved. There are a few things that may need to be expanded on, and this should hopefully keep the discussion going. -Tim ... View more

Hi Mike, There's a section in the What's New at 10.4 doc, that may help to solve your problem: http://desktop.arcgis.com/en/arcmap/latest/get-started/introduction/whats-new-in-arcgis.htm#GUID-BFAB27B8-04AA-4C21-90D0-C63B7A7A4E59 Beginning with ArcGIS 10.4, geodatabases in SQL Server      require the SQL Server database options READ_COMMITTED_SNAPSHOT and      ALLOW_SNAPSHOT_ISOLATION be set to ON. When you upgrade your geodatabase      in SQL Server, the Upgrade Geodatabase tool sets these in the database.      When you create a geodatabase in SQL Server using the Create Enterprise      Geodatabase tool, the tool sets these options in the database. If you use      the Enable Enterprise Geodatabase tool to create a geodatabase, you must      either set these options to ON in the database before you run the tool, or      grant the geodatabase administrator the permission to ALTER the database.      If the geodatabase administrator has ALTER database permission, the Enable      Enterprise Geodatabase sets READ_COMMITTED_SNAPSHOT and      ALLOW_SNAPSHOT_ISOLATION to ON in the database. To use ArcGIS 10.4 with SQL Server databases or 10.3.1 or earlier release geodatabases, you must manually set on READ_COMMITTED_SNAPSHOT in the database. ... View more

Hello Donny, It sounds like this may be related to the code used to create the polygon. I suspect the code may not be using the simplify method prior to storing the row in the feature class? I wrote a function (adapted from old VB code) to try to reproduce your case. Though I was not seeing the specific problem you describe, I found that you can get odd results if you do not use the simplify method. In my case polylines oriented counter-clockwise, when converted to polygons, result in a negative Shape_area attribute in the stored polygon unless the Simplify method is called first. IPolygon::SimplifyPreserveFromTo Please see the attached code and comments for more info. -Tim ... View more

There are some parcel-fabric-specific code snippets available for download from this location on AGOL: http://www.arcgis.com/home/item.html?id=816ce8cc1ddc4ac2a034f64914947912 Also, on GitHub the code for the published parcel editing/fabric add-ins is available: Esri/parcel-fabric-desktop-addins · GitHub ... View more

An update to the ArcGIS 10.3 Parcel Fabric Maintenance Patch was published on 8/10/2015. Available at the same location, here.​ ... View more

Thanks Jeff. Did you notice the problem prior to saving edits, or do you now have instances of control points stored in the database that have had the incorrect unit conversion already applied? If you (or anyone reading this) have a large number of instances of the wrong control points stored in the database as a result of this problem, there is a way that these can be repaired. Since we know that the coordinates are getting a unit conversion applied, we can detect the control points that are well outside the proper extent, export them to a table (dropping some of the system fields), recalculate the X and Y fields by multiplying them by a scale factor, and then re-import them using the Control point Importer. Once it’s been determined that the process occurred correctly, then the control points that are in the wrong location can be deleted. I’ve uploaded a toolbox to AGOL with a script for exporting the control. Here are the steps to follow after downloading it: Drag the control fabric class that has the incorrect control points onto a new map. You should see two clusters of control points, one of the clusters being at the incorrect location Use the Zoom tool and zoom to the location of the incorrect control so that all are within the map extents In the toolbox double click the script called “Export Parcel Fabric Control To Table” Set the source table to be the Control layer For the Data Extent parameter, click the dropdown and pick “Same as Display” Choose the location for the exported table Click OK The table is added to the Table of Contents Open the Table Confirm that the X and Y values are well outside the correct range Right-click the X field column and click Field Calculator If your original data is in US Feet then calculate as follows: *0.3048006096012192 If your original data is in International Feet then calculate as follows: *0.3048 Do the same steps for the Y field column, and Calculate the Right-click the Fabric in the Catalog window, and click Import->Control Points Navigate to the table that you exported, and that you updated the coordinates on Accept the default values in the Control import wizard and then add the fabric to the map Confirm that the control points that had been changed are now back in the correct location If all’s OK, Start Editing, and go back to the incorrect control points, and delete them. ... View more

Jeff, Note that there is a workaround for the problem as indicated in the bug description. I hope that this workaround can be used until the update is available. We're currently testing the fix, and working on publishing an updated patch for 10.3--it will be available as soon as possible. There will also be a 10.3.1 patch to follow that addresses this same problem. Apologies to all those affected. -Tim ... View more

For an example of capturing and listening for parcel editor events, please see code for attribute assistant, as demo'd at the 2/26/2015 land records meetup. The code is published on GitHub here: http://bit.ly/1FXwJct The attribute assistant methods use editor events. The code added to support fabrics, uses objects class change events from the geodatabase fabric tables, and re-broadcasts these as editor events. -Tim ... View more