Latest Contributions by TimHodson

‎02-09-2024

Thanks @SarahSibbett - I totally understand the request in the idea, and it absolutely makes sense to have this consistency with Move tool and the way it behaves with Map topology in Pro. Thanks for clarifying! My previous responses are only to make sure anyone reading this post are aware of the "Snap line ends to path" capabilities as an approach to get around this current limitation in Align Features when working with parcels. When using the Align Features tool, I'd also recommend avoiding the option "Preserve shapes outside the alignment area", as this will add extra vertices at the locations that intersect the perimeter of the alignment area. The methodology you describe with the Move tool also requires the "Stretch Topology" button to be turned on. For parcel boundaries this would (likely?) always be necessary. On a separate but related note, we have development work in progress (release version TBD) to enhance the move tool to be aware of parcel edges, independent of layer visibility. -Tim

‎02-08-2024

Thank you @MizukiKayano2 @SarahSibbett for reporting this bug - I can confirm the tool does not complete when using the "Snap lines ends to path" option while projecting on the fly, and while "No Topology" is set. For your reference: BUG-000164978 On the other case, I see how we are getting different results, and how this idea applies. In my case with the videos above the topology had not yet been validated, whereas in your case the topology validation has introduced a vertex via the connection line, and so the polygon's segment is bending at that location. There is also a vertex on the line, but its behavior is as expected and the line does not bend at the vertex. To workaround this you could shrink the polygons to seeds first, run the align features just on the lines, and then reconstruct from seeds. Another approach is to run the SLACA (Simplify By Straight lines and...) tool with a small tolerance on all the surrounding parcel polygons to remove these vertices, and then run the Align Features. Both of these approaches seemed to be effective for me.

‎02-08-2024

@SarahSibbett thanks for the additional info. This is very helpful. I'll research further, and report back here. Just to confirm though: the results shown in the video above when not projecting on the fly and with "No topology" set... those results are what is expected, correct?

‎02-07-2024

Hi @MizukiKayano2 , Thank you for the new videos. I've simulated your scenario. Below is a video using the Align Features tool, with the "Snap line ends to path" option turned on, and with topology turned off altogether. ("No Topology" set in the Quality tab) Does this get you to your intended end result? -Tim

‎02-02-2024

Hi @MizukiKayano2 and @CathyAppleton Please try the option to "Snap line ends to path"and let us know if it solves the problem. This option is the most conservative in terms of introducing new vertices and is much better at preventing the creation of bends in the lines. -Tim

‎01-29-2024

Hi @SamuelLingeman - would you please provide some more information? A screen shot showing your entries would be good. If you could provide your data that'd be useful too. I'll send you a private message. Thanks, Tim

‎01-22-2024

Hello @TomNeer and @DennisTebo There is an add-in available that will set the ground to grid values whenever changing the active record. It leverages enhancements made to the Parcel Fabric API with 3.2. If you have 3.2 or higher, you can install the add-in from here. There are some schema changes required. To use the add-in: after installing it you opt-in to the functionality by creating two [double] fields on the Records feature class called 'DistanceFactor' and 'DirectionOffset'. Type in, or calculate the appropriate direction offset and combined scale factor values into these fields for the records in the records feature class. The map's ground to grid correction will change to the (non-null) values found in these fields whenever a record is activated. If the value in the activated record is null, then it will not change the currently set ground to grid value. Set Ground To Grid From Active Record You can also use the add-in button called 'Save Ground To Grid To Record' on the active record's heads up display menu to save the map's ground to grid correction values to these fields. Existing values will be overwritten. For all who use this add-in please provide feedback on its functionality; this will influence our implementation of the functionality in the core product in a future release. If you are a developer : - the code is available here. - in brief, with 3.2 the API provides a new event that is fired when the map's active record is changed. -Tim

‎11-21-2023

Hello All, In ArcGIS Pro 3.1 this add-in was not refreshing the CAD layer properly after the tool was run. The workaround was to shut down and restart Pro to see the layer properly placed. For ArcGIS Pro 3.2 and higher a new version of the add-in is available that properly refreshes the layer. If you are using ArcGIS Pro 3.2 or higher, it's recommended that you download the latest version of this add-in from here. In general, add-ins are designed to be forward compatible, however in some instances changes in the underlying .Net SDK require that a newer version be compiled to get improved functionality, as is the case here. If you have the prior version installed, first remove it, and then replace it with this version. -Tim

‎11-09-2023

Hello @ndunn54 the Circular Arc tool can double as a curve calculator. Here's a previous post with the same question that has more information about that: https://community.esri.com/t5/arcgis-pro-questions/curve-calculator-for-arcgis-pro/m-p/393360#M17395 Does this help for your situation? Thanks, -Tim

‎11-07-2023

Looking forward to hear all of your feedback! With today's release of 3.2, here’s the updated doc that covers the support for the new measurement types in the least squares adjustment. See the section called “Geodetic azimuths and ellipsoid arc distances in the least-squares adjustment”. Also, the following help doc has been updated to include the new step (Step 5) in the configuration to ensure that the adjustment analysis layers for Geodetic Azimuth and Ellipsoid arc distances show up in the table of contents when you run the least squares: https://pro.arcgis.com/en/pro-app/latest/help/data/parcel-editing/use-geodetic-directions.htm -Tim

‎10-17-2023

With soon to be released ArcGIS Pro 3.2, the above mentioned behavior with the Planarize tool and COGO attributes has been changed. The COGO will now not be recalculated on the lines that are only snapped. Otherwise, when the lines are split where they intersect, the software will continue to work as it currently does (in 3.1 and prior), with COGO distances recomputed/re-proportioned and their COGO Type set to "Computed".

‎10-17-2023

Mark, I see messages similar to this when trying to delete a feature class if I have forgotten to first remove the parcel type from the fabric. You should be able to delete those feature classes. To remove the parcel type, right click on the fabric in the Catalog pane, and click Manage->Remove Parcel type, then in the GP tool that's presented, enter the name of the parcel type to be removed. You'd repeat this for each parcel type. After removing the parcel type, the feature classes should be "released" from their controller, and you can try the delete again.

‎10-09-2023

Hi @ElisseDeleissegues1 , To your question and reference to use of the NGS point. I know you are asking for other methods, but I'm curious about how you are currently using the NGS point reference, if at all? The reason I ask is that last year and earlier this year a few of us on the parcel development team had the opportunity to review a large number of land records documents from in and around Honolulu. We noticed that the NGS point reference used for the point of beginning appears on most (pretty much all?) of the documents. I see this same NGS-reference pattern on the document you've shared. Based on our research we found that NGS references are valuable for geolocating parcels with better than expected positional accuracy. It requires the use of feature templates that use geodetic azimuths, as described here: https://pro.arcgis.com/en/pro-app/latest/help/data/parcel-editing/use-geodetic-directions.htm I will follow up with additional information on this method. Regarding the painted locations for the centers of cul-de-sacs. The painted /surveyed locations used for the photo-control could serve double-duty as a tie-in to the parcel boundaries if there is a physical marker in the asphalt (iron pipe or similar) that can be positively identified as the "true" (in parcel boundary sense) center of the cul-de-sac, and that is what gets painted/surveyed. -Tim

‎08-28-2023

Hi Nick, yes you have answered your own questions correctly. @NickN wrote: My understanding is that the adjustment uses COGO to calculate adjustment vectors of the fabric points. In the case of a tax parcel and lot parcel being identical, the fabric points will be shared between the two sets of lines, correct? Yes. This would be what we'd expect to see. Sometimes you need to use the merge points tool when there happen to be exactly overlapping stacked points, or very close points that really should be a single point to represent a single shared corner. @NickN wrote: Are lines without COGO ignored in the adjustment calculations, but still affected by the adjustment when applied? Yes. @NickN wrote: ...we should be able to only backfill COGO on the Lot lines correct? When an adjustment is run and points moved, since the points are shared all lines shared between points are adjusted, even the ones without COGO. Yes. A general tip on running the least squares; note that you can also select the lines that you want to process in the least squares. Selecting the parcel polygons does work to include the boundary lines for the parcel, but it will not include any connection lines that are attached to the parcel. You need to select those connection lines as well. For this reason I personally like to simply work with the lines (parcel lines and connection lines), and directly select those lines to be processed. It's a bit less ambiguous about what lines are going to be used. As you note, if the line has no COGO, then even if it's selected it will not be "seen" by the adjustment. -Tim

‎08-24-2023

This is fixed in the latest patch 3.1.3 that was released today. ArcGIS Pro 3.1 patch 3 (3.1.3) is now available to download from My Esri. https://support.esri.com/en-us/bug/the-merge-parcel-points-tool-returns-topology-errors-bug-000159260 Thank you again for reporting it.

Online Status	Offline
Date Last Visited	Friday

My Ideas

Latest Contributions by TimHodson

Re: Allow the Align Features tool to honour Map Topology instead of GDB Topology

Re: Allow the Align Features tool to honour Map Topology instead of GDB Topology

Re: Allow the Align Features tool to honour Map Topology instead of GDB Topology

Re: Allow the Align Features tool to honour Map Topology instead of GDB Topology

Re: Allow the Align Features tool to honour Map Topology instead of GDB Topology

Re: Transform CAD Layers in ArcGIS Pro

Re: Combination (scale) Factor

Re: Transformation Tab in ArcGIS Pro

Re: curves

Re: Exposing Direction Types in Parcel Fabric Least Squares Adjustment

Re: How to quickly "snap" all lines together in a subdivision?

Re: Parcel Fabric Local Government Model GBD Feature Class Deletes

Re: Fixed Points from Survey

Re: Fabric COGO and Adjustments

Re: Merge Points: Inconsistent Behavior?

Re: Is there a method to have the line associated ...

Re: Splitting Continuous Lines at vertices based o...

Re: Parcel Alignment Failed

Re: Topology errors when loading parcel fabric

Re: curves

Group Owners Group

PLSS Editing

ArcGIS Parcel Fabric - SDK for Add-ins and Scripting