Latest Contributions by TimHodson

hi Dean, The effect you were seeing where circular arcs fall outside the tolerance can be solved in two different ways, as specified by the bullet points. It’s either/or, not both. Sorry it was not very clear in the original post, I've edited the post to clarify. -Tim ... View more

@DeanAnderson2   I can give possible reasons for two of the items you mention, the one about circular arcs getting created when you don't what them to be, and the other about resulting feature geometry being outside the specified offset. Without seeing examples it's hard to know if these make sense for your cases. It is possible that the Simplify By Straight Lines and Circular Arcs GP tool can result in a circular arc that bows out beyond the Maximum Allowable offset from the initial feature’s geometry. This may occur if you chose the Fit to Vertices option, and it is also more likely to occur with a larger value for the Arc Angle Step. The algorithm works by taking the positions of the vertices and trying to fit straight lines and circular arcs and by allowing the positions of any of the original feature vertices (except the first and last vertex of the feature) to be iteratively varied within the Maximum Allowable offset until a best-fit circular arc and/or straight line can be found. This can result in a new circular arc that bows outside of the offset distance while not breaking the conditions of the algorithm because the original vertices that are used to define the circular arc are still within the allowable offset. Here's a graphic showing this:     To avoid the likelihood of this happening, you can either: Use the Fit to segments option instead, because this option uses the segment geometry, OR Reduce the value for the Arc Angle Step if you are using the Fit to vertices option. ... View more

Hello Diego, I suspect that you have geometries that are bezier curves. With ArcGIS Pro 3.1 we fixed a performance problem and a geometry problem like the one you show in your third image above. If you are not able to upgrade to ArcGIS Pro 3.1, you could consider converting your bezier curves to circular arcs or to polylines with straight line segments. For your reference: BUG-000155164 See also related post here: https://community.esri.com/t5/arcgis-parcel-fabric-questions/is-there-an-easy-way-to-track-down-features-that/m-p/1236543#M898 -Tim ... View more

For the ArcGIS Pro 2.6 release we fixed an issue on the parcel fabric line layers that addressed this problem. However, for standalone COGO layers there is a separate but similar issue where the unit is "hard-coded". This will be fixed in the 3.2 release. If you are seeing this problem in parcel fabric line layers and in a release that is later than 2.6 then please contact tech support. If /when you contact tech support please reference the following number; its for the bug mentioned above that will be fixed in ArcGIS Pro 3.2: BUG-000158885. ... View more

The ground to grid correction is applied when the data is entered. If you need to rotate and scale the features after they've already been created then a different approach will be needed to do that. There are a couple of options, you can set the ground to grid as before and then use the Trace lines button in the traverse tool, as explained in the above referenced video, around 31m29s. This should apply the ground to grid to the lines you trace. You could also use the rotate and scale tools on the selected line features (and polygons if needed.) Turn off the map or gdb topology (optional but depends on the situation) and then select the features you want to rotate and scale. Since you know the scale and rotation from the computed ground to grid, you can set the anchor at the commencement point location and then use the ‘A’ and ‘F’ shortcut keys to get the dialogs to type in the rotation [A]ngle and scale [F]actor as follows: ... View more

Hi @SenecaFrancis , using your example COGO line, I made a video showing how to set the ground to grid correction using the Interactive tool, and then using the Direction Distance tool after the correction has been set to create the line geometry between the two points. Since the correction is turned on, the end point of the line now matches the position of the "to" point. ... View more

Thanks @jcarlson @KarinPierce @anna_garrett for reporting this problem. I've reproduced the issue on 3.1.x. It is not reproducible in 3.0.x. We will work to find the cause, identify a solution, and get a fix into the next available patch. ... View more

Please note this similar idea; you may want to up-vote it as well: https://community.esri.com/t5/arcgis-pro-ideas/live-total-length-measurement-of-polyline-when/idi-p/1018975 ... View more

Here are the links to the resources from the chat and slides: Pro Concepts page Parcel API Pro Concepts page COGO Developer Summit 2023 Slides and sample code on Github. Parcel Utilities add-in: Item on ArcGIS Online Code COGO Line Features add-in: Item on ArcGIS Online Code Transform CAD 3.x add-in: Item on ArcGIS Online Code Full list of ArcGIS Online add-ins from Esri parcel team Additional recording of technical session from 2021 Esri Developer Summit: ArcGIS Pro SDK .Net Introduction to the Parcel Fabric API ... View more

Hi Frank and Jason, What you describe is a bug, and is not the intended design. Thank you for reporting it. When using planarize, the COGO distances are recomputed when the lines are split; in these cases the existing COGO attributes get re-proportioned, and the COGO Type is then set to "Computed" on the resulting shorter lines. For the cases where planarize is snapping line ends together and the lines are not getting split, then the COGO distances should not be getting updated. Instead of using Planarize to do this snapping, you could instead use the GP Snap tool on the line selection, use the End snapping as the snap type, and use a small tolerance. In my tests of this it seems to be an effective solution. Example something like the following: Does this work to solve the problem? -Tim   ... View more

I'd recommend contacting Esri tech support and reference this post and the case number as per our e-mail correspondence. That would help add weight for us to get patches based on the release you're using.   ... View more

Hi Michael, The short answers to both questions is yes. Beziers are different to circular arcs, and they are a supported geometry type for features in a parcel fabric. There are, however, some limits to using beziers in the current release, described below. Additional information: Feature geometry is built up from segments. A segment can be a straight line, or a parametric geometry. A parametric geometry can be a circular arc, an elliptic arc, or a bezier. These parametric geometries are referred to generically as "curves", but when used in the context of parcel data and COGO we are, 99.9% of the time, referring to circular arcs. In the COGO world "true curves" and circular arcs have become synonymous. Limits of beziers when using Build command: Beziers may be used in the fabric model to represent natural boundary features, however we have seen cases where straight lines have been turned into bezier curves even though they are still geometrically straight. Beziers should be reserved for natural boundaries. If your fabric has very large natural boundary features with many bezier curve segments there are known limits that cause performance problems when running the Build command, for example. These issues are being addressed and fixed for the next release of Pro. (3.1) We are also investigating the feasibility of providing a patch for this on earlier releases. What about transition curves and spirals? The other curve we see in COGO workflows is the "transition curve" used for highway and rail centerlines. This incorporates the use of spirals, and combining them with circular arcs and/or straight lines to form smooth, tangential transitions to represent long linear features. Spirals cannot be represented parametrically in Pro; they are handled differently and are represented as a densified polylines.  (For more specific info see this topic in the Concepts documentation for the COGO SDK) -Tim     ... View more

Hi Josh, you had me thinking there for a minute... The reason that is not available as a topology rule is that there is only one point feature class that's shared between all parcel types. You could add the rule "Point must be covered by end point of" for all of your parcel types' lines, and for your connection lines, but then you would have an error feature on all of your points except for those points that happen to be on the endpoint of a line of ALL the parcel types that connected at that one location, and there would also have to be a connection line's end at that same location: that'd be a rare case.           ... View more

Hi Matt, The beziers may have been introduced as a result of running the GP Smooth Line tool, or by using the editing tool called Generalize with the Smooth option. The SLACA tool intentionally does not alter the geometry of features with parametric segments such as beziers, circular arcs and elliptical arcs, as this would be considered to be data corruption by customers who'd like to keep their beziers intact. To answer your question, I have not found an out-of-the-box way to detect bezier curve geometries in Pro. I was looking into the GP tool called Calculate Geometry Attributes, but it does not report on specific parametric geometry types. That may be a good Idea to add as an enhancement for that GP tool. There is an add-in (currently unpublished) that I can share with you. It will select features (within the active map's extent) that have geometry segments that are beziers. I'll direct message you to find out more about your ArcGIS Pro release etcetera. -Tim         ... View more