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. 

[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:

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

Would this work?

Another option to consider:

1. Delete all parcels
2. Create one correct parcel
3. 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)?