nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Choose Whether to Create Seeds from the ‘Copy Lines To’ Tool

SeanLyons

As an organization, we accept many types of plans from Surveyors. This includes posting plans, which contain parcel boundary linework but no related parcels. We use a digital submission process that creates simple feature class that represent survey plan information. The resulting line feature class that is created from the digital submission process is brought into the parcel fabric using the ‘Copy Lines To’ tool.

This is the most efficient way to bring in the geometry and attributes of the lines into the parcel fabric; however, the ‘Copy Lines To’ tool automatically creates seeds for each closed loop. In the case of the posting plans we work with, we do not need parcel seeds built for each closed loop of lines. This means that once the lines are copied into the parcel fabric and the seeds are created, the seeds need to be selected and deleted. This can be a tedious process.

We would like to be able to have the option to decide whether the ‘Copy Lines To’ tool creates seeds or not. This could look like a radio button that you can enable if you would like to create seeds when the tool is executed or disabled if you do not need to create seeds for the linework you are bringing in. This would streamline our workflow and save us time in the long run.

Example of a posting plan is attached, note there is no parcels created with this plan only lines.

E_POSTING_PLAN_S68_georeferenced_2018-07-17.pdf

ParcelFeatures_1.010after.PNG

Find more posts tagged with

Status: Open

Comments

jcarlson

If you copy, say, 3 out of 4 lines that make up a parcel, then copy the 4th line separately, no seed is created. Still tedious, but perhaps less so than deleting seeds.

Why don't you need parcels for these lines? Would they make more sense as a subtype in the Connection Lines layer?

SeanLyons

These plans are part of the BC land Survey system to help find existing survey evidence and then add missing posts based on the found posts, but they don't create a new parcel they only add more accurate lines and ties to control for an area. I am pretty sure we aren't the only Province that uses that concept.

The subtype would work in theory but with the issues copying into the connections line layer it isn't the best which is the other idea I just posted. Also not sure how well the LSA engine works with the connections lines layer.

AmirBar-Maor

@SeanLyons

If you want to copy & paste lines into any parcel fabric layer you can simply use the Copy and Paste Special command. This will allow you to preserve the source attributes and will not create seeds.

However, since your digital submission users a structured CAD file, in which you know what each CAD layer contains, you can automate the process and append the data to a named version.

You can see an example of ingesting a CAD file in this post. We are working on new geoprocessing tools that would make this even easier than it is now.

If your lines are not boundary lines, they should be modeled as 'connection lines' You can extend the connection line feature class with a field called 'ConnectionType' (for example) and have different non-boundary types: posting, tie lines, road centerlines... You can display them all in the same layer or separate certain values to different layers using a definition query.

Would this work for LTSA?

SarahSibbett

@AmirBar-Maor that's a great post you've linked to. I'll definitely be downloading the Pro package and looking at it in more detail.

In the case of LTSA, you know we were originally on the fence whether to store the posting plan lines in a survey parcel type or in connection lines (since these really aren't connection lines), but after speaking with you and your team and also looking at some downstream implications, we've pretty much landed on storing the posting plan lines as connection lines. We do have a line type domain to help identify surveyed connection vs. surveyed boundary lines, etc. Since we will be storing these in connection lines now, we can't use the Copy Lines To tool anyway - but if the Copy Lines To tool were enhanced to support Connection Lines in the future, then we will need the ability to select whether seeds are created.

AmirBar-Maor

@SeanLyons

The attached plan does contain lot numbers - was this intentional?

It also looks like:

A posting plan is a form of a 'boundary resurvey' of parcel boundaries.
The plan, like any other plan/record is registered/recorded.

Should the old parcel boundaries get retired?

If bullets 1 & 2 above are correct, a better workflow to reflect it would be:

Create a new record
Select the parcels to update
Use Copy Lines To active record and create seeds (parcel attributes are not changed)
Delete the copied lines
Copy the new lines from the posting plan
Build

The above workflow will create parcel lineage to reflect the updated boundaries.

If parcel lineage is not desired:

Create a new record
Select the parcels to update
Shrink to Seed
Delete parcel lines
Copy the new lines from the posting plan
Reconstruct from seeds

Thoughts?

SeanLyons

The lot numbers are intentional to help people reading the plan orient the data to the ground as well as surrounding plans. A posting plan does not redefine the lot it only replaces lost evidence or confirms the location of found evidence to hopefully match with original plan interpretations of where the evidence should be.

Both 1 and 2 are correct but we will not be retiring the old line work as the posting plan doesn't redefine the lots. We want to keep both sets of linework to preserve the correct lineage of lines and hierarchy of evidence. The posting plan record should not be used as the active record for anything except the posting plan linework.

@AmirBar-Maor

AmirBar-Maor

@SeanLyons

Any cadastral field survey attempts to locate, confirm, and collect the original demarcation in the field.

I assume that if there is a conflict between the original survey to a later posting plan, the posting plan will win, after all, it was conducted to resolve uncertainties - is that correct?

Sounds like you want to keep the original lines current - that is supported. You can create duplicate boundary lines stacked on top of each other, each associated with their plan.

You can consider this workflow:

Create a new record
Select the posting boundary lines
Copy
Paste special to the appropriate target lines
Create Seeds
Shrink to Seed
Build Active
Use Align Parcels tool to align the new parcels
From the record HUD - select all polygons
Delete them

You can also consider setting another category on boundary lines if you want to symbolize them differently. Even create a separate layer for them if needed.