I got that the create Parcel\Keep and Join\Trace fabric to create join links can do the job. However, it appears that the trace can’t produce and identical boundary on top of the existing one as shown in the screenshots below
There is no auto-complete polygon feature in the parcel fabric. The idea is that boundaries should reflect the record dimensions and thus must be entered by the user. Autocomplete will not ensure that dimensions in the fabric match dimensions in the plan (legal document).
Right. But why the “trace” method explained in the screenshots above has no option to create common boundary?
What might be the best practice to add new parcel that shares one of its boundaries with an existing one.
Unfortunately, I couldn’t follow the help as there is no concrete examples that can be followed.
The common boundary must be entered. When creating a new parcel in the fabric you must enter the whole complete traverse - all the boundaries must be entered. The parcel must close back onto the starting point. The parcel is then joined to the parcel fabric layer. This is by design. New parcels are never "auto-completed" by any tool. The parcel boundaries must be entered and reflect the dimensions on the legal recorded document.
Each shared boundary in the fabric consists of two lines - one for each parcel sharing the boundary. Joining takes care of stitching the parcels together
That’s clear for me now. My point how to work with “trace” so that the shared boundary can be DIGITIZED AUTOMATICALLY instead of digitizing it point by point.
Is this still possible (to automatically digitize the shared boundary by trace tool)?
The trace link tool establishes join links between new parcel points and existing fabric points. It saves you time by attempting to generate the join links automatically. However it does not automatically create parcel boundaries.
As I said before - if what you are doing is digitizing boundaries, the fabric might not be the most efficient tool for you. Spatially and legal accuracy can never be achieved with digitized or rubbersheeted boundaries (in most cases). If you are concerned with spatial and legal accuracy - then the parcel fabric is the way to go - but there is more work involved Im afraid
Correct. The only reason that we need to work with fabric environment is to keep the history in case of parcel split\merge. Our focus is not the accuracy at this stage.
Fabric environment keeps how the “native” state of any parcel before being split or merged. This property is not available in any other data format. In this case, Owners stored in stand-alone table can still be mapped to their “history” parcels! Great documentations of how parcels evolve.
Given that I need, at this stage, to take the advantage of keeping the history of parcels by working with fabric environment, I want to enjoy having all the capabilities available in the standard editor bar (or equivalent tools in the fabric editor bar) like: