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; } } }

Allow 'Reconstruct from Seeds' to work for overlapping seeds

MizukiKayano2

Currently, the Reconstruct from Seeds (as well as build active and build extent) will not work if you have overlapping seeds. You can click the button, but the tool does nothing. You have to delete your overlapping seeds, or, use the workaround we are using: move all but 1 of the overlapping seeds outside of the closed loop of parcel lines> reconstruct from seeds> move another overlapping seed into the area> reconstruct from seeds> move another overlapping seed into the area> reconstruct from seeds, etc. It's ok as a workaround, but certainly not efficient.

We would like the ability for the reconstruct from seeds tool to work even when there are overlapping seeds. One use case would be air space parcels - we typically have 4 or 5 air space parcels stacked on top of each other. If we need to shrink these air space parcels to seed, when it comes time to rebuild them, we would have to use our workaround of moving all but one of the seeds out of the closed loop of lines that bound the air space parcels> reconstruct> move another seed in> build, etc.

Find more posts tagged with

In Product Plan

Status: In Product Plan

Comments

AmirBar-Maor

@MizukiKayano2

The workflow is not clear. It looks like you start by shrinking multiple coinciding parcels to their seed. Is that correct?

Do they all share the same boundary lines or not? If not - which boundary lines belong to each parcel?

A screenshot might be helpful here to understand why you shrink multiple parcels to start with. How common is this workflow?

MizukiKayano2

@AmirBar-Maor

Example 1

Let's say that the area in red hash is the incorrect parcel shape (left). The correct shape has to include the cyan parts to the East and South (right). The quickest way to fix this is to shrink the parcel to seed, remove the incorrect lines that currently bound the parcel, and reconstruct from seed. (If there is a better method, please let me know.)

However, there are 5 parcels overlapping here. One for the parent subdivision, and 4 air space parcels with the same footprint. (To answer your question, yes, these are multiple coinciding parcels that share the same boundary lines.)

To accomplish fixing these parcels, we would shrink all 5 parcels to seed, remove the incorrect lines that currently bound the parcels, and reconstruct from seed. (If there is a better method, please let me know.)

The issue is, reconstruct from seed tool doesn't work if there are more than one seed within a closed loop. That's where our current workaround come in - we move 4 seeds outside the boundary, reconstruct one seed, move another seed into the boundary, reconstruct, and repeat, until all seeds are built.

Example 2

This is an example for multi-part parcels where some parts share the same boundary lines.

Let's say we have an existing parcel (left), and we receive new linework with a more realistic shape for the parcel (right). We would shrink the parcel to seed to start the quality driven workflow to improve this area. (in this case, we'd shrink the surrounding parcels to seed as well, as there are major clean up to do as the existing parcel shapes are very off.) Once we are satisfied with the new lines, we would reconstruct from seed.

However, if this parcel was the latest remainder parcel, there are more than the current parcel to fix (i.e. historic parcels).

Original parcel shape was 1+2+3 (historic)
There is a remainder parcel representing the shape of 2+3 after 1 was consumed by a new subdivision (historic)
The latest remainder parcel is 3, after 2 was consumed by a new subdivision (current)

That means if we shrink all 3 parcels (1 current, 2 historic), there would be multiple seeds to reconstruct.

To answer your question on how common this workflow is; we do this kind of quality driven workflows all the time (multiple times a week), especially in areas where the current fabric quality is low, and we receive updated linework. When we fix issues, we fix the current parcel, as well as the retired parent parcels.

AmirBar-Maor

@MizukiKayano2

For the first example, where you need to merge the error parcel (slivers) into the real parcels I would use the following workflow:

Make sure you have an active record
Select the parcel and the slivers
Open the Merge tool on the 'Existing Feature' tab, select the parcel to preserve,
Press Merge

Would this work?

Another option to consider:

Delete all parcels
Create one correct parcel
Use Duplicate to duplicate it 4 more times

FWIW- if the airspaces were to be 'floor aware', and each one has a different Floor Order value, each will be built/reconstructed independently. That means each will have it's own lines though.

AmirBar-Maor

@MizukiKayano2

Thanks for the detailed explanation.

For the second example, you have a multipart parcel - but only 1 part (out of 3) gets updated. Wouldn't it be easier first to Explode it into 3 parcels, fix the defective part, and then use 'Merge into Existing' to recreate the multipart again?

Other ideas that come to mind is to ignore the bad parcel, create a new one instead, and use the Transfer Attributes tool to transfer attributes between the bad to the good. Then delete the bad parcel and align the good one. If the surrounding parcels are very much off you can start by using the move/rotate/scale tool on points and edges to bring it closer. Moving points will also update any historic parcel that coincides.

Is it needed to shrink the historic parcel to seed? If it shares the same points it will also move to the new point location.

Also, keep in mind that Build does not build historic parcels.

MizukiKayano2

@AmirBar-Maor Thank you for your response.

Yes, those methods would work. In fact, that is how we would 'repair' parcel shapes in ArcMap Parcel Fabric.

However, one reason why we want to avoid merge/duplicate/explode is, we would like to retain the global IDs of the parcels as much as possible.

This is due to downstream impact. We publish out a parcel change product, where customers can see the changes made to the fabric.

Every new global ID is an 'Add'
Every global ID that no longer exist is a 'Delete'
Global ID that had attribute or shape changed is an 'Update'

When we perform quality based changes to a parcel, we would like them to show up as an"Update". As we are preparing for migration to the ArcGISPro Parcel Fabric, we wanted to take advantage of the Seed to accomplish that. The Seed would retain all the attribute, including the global ID, while technicians are free to update the linework bounding the parcels.

Currently, when we make quality based updates to parcels in ArcMap Parcel Fabric, we end up publishing a whole lot of Adds and Deletes, and no Updates. It would be a huge improvement for us and the customers if we can avoid that in ArcGIS Pro Parcel Fabric.

Being able to reconstruct overlapping seeds would enable us to perform quality based edits without all the 'noise'.

AmirBar-Maor

@MizukiKayano2

To fix the sliver, if you use 'Merge into Existing ' feature, it will preserve the feature and its GlobalID. See the screenshot above.

You can probably use DBMS Views to show the Adds, Updates and Deletes.

MizukiKayano2

@AmirBar-Maor

That's great, I didn't know that (I was used to ArcMap creating a new object upon merge.)

I would still like to reiterate my interest in allowing 'Reconstruct from Seeds' to work on overlapping seeds.
There are many opportunities where we want to move parcels out of the way to be able to perform complicated modifications to lines, especially when multiple parcels overlap (i.e. active parcels, historic parcels, and other parcel classes.)

In ArcGIS Pro, we cannot 'unjoin' parcels, so shrinking to seeds and reconstructing later would benefit the quality-driven-cleanup experience for technicians.

AmirBar-Maor

@MizukiKayano2

Good point about "getting parcels out of the way" for cleanup purposes. Shouldn't that be its own tool? Like a "parcel magic wand" that makes parcels disappear until you press another button?

MizukiKayano2

@AmirBar-Maor

Magic wand would be nice! As long as when the parcels re-appear, they 'fill up' to the extent of the updated&cleaned up lines. (i.e. to mimic reconstruct from seed)

It would be good to have a view of 'hidden' parcels (like in ArcMap where I could see unjoined parcels in the Parcel Explorer).

AmirBar-Maor

@MizukiKayano2

From my understanding, your organization decided to combine the historic parcels and current parcels into a single layer.

Is it possible that we are trying to solve a problem that can be easily prevented by working with the default layers (separate layers for historic and current)?

MizukiKayano2

@AmirBar-Maor

Yes, we have decided not to 'hide' historic parcels with a definition query, so if the shape was incorrect and requires modification before we add in a new subdivision, we would clean up. This keeps the genealogical path of parcels from their origin to their current state clean, and also avoids unexpected error when performing least square adjustments.

We also have other parcel classes that share boundaries that may require correction at the same time, for example, when an interest (in the Encumbrance parcel class) shares natural boundary with a subdivision (in Property parcel class).

JackBovee

Sorry for the thread necro, but we've only been using the Pro Fabric for a little over a year now and I just stumbled on this issue.

In our situation, we have several "shared interest" tax parcels across our county, especially in plats. While there is typically a "parent" parcel number, we have copies of the geometry associated with the each shared parcel occupying the same space. The purpose for this is to assist the department that handles land transfers so there's a visual representation of a parcel (and associated pieces) on the main county web map (see picture below).

So last week I was doing some cleanup work on parcel boundary curves that were left over when we converted from the ArcMap fabric a year ago. As I don't want to be creating historical records for this work, I was using the Shrink to Seeds / Reconstruct from Seeds method, outside of a record. Everything went well until I went to expand the seeds in this particular area (see picture below). Ultimately had to abandon 2-3 hours worth of cleanup work because I couldn't figure a solution at that point in time as to why it wasn't expanding. Figured out the whole, "expand one seed at time" trick, but there are some areas in the county that have 30+ associated tax parcels stacked up, and I'd rather not have to manually manipulate each seed every single time I need to make any edit.

AmirBar-Maor

@JackBovee

Thanks for providing the use case.