Select to view content in your preferred language

Large administrative boundaries with standard tax parcels

962
4
06-29-2022 01:25 PM
Labels (1)
Paul_Christensen
Frequent Contributor

I have been running the Pro Parcel fabric since July 2020 and I am currently running the most recent version, 3.0. Recently, I decided to try and add my larger boundaries such as tax districts and city limits into my fabric as authoritative parcel types. They are all in the same fabric that I run standard tax parcels from.

I am running into some pretty large performance issues. Districts and city limits don't change often, but they end up being incorporated into my every day edits because they are now in my fabric.

If I build extent over several tax parcels, the tax district builds and the Dirty Area ends up being extremely large instead of just the few parcels that I intended to build which makes Validation very slow. 

Using tools such as Merge Points, if I select a point that happens to be shared with a district, Pro locks up for minutes at a time before it becomes active again because of the large polygon size.

This and many more issues makes me want to take these authoritative boundaries back out of the fabric.

What is the recommended data structure for something like this? Should I put them into a different fabric? Is it unusual for authoritative boundaries to be mixed in with tax parcels? I want to at least keep city limits, because recording annexations will be very useful with parcel lineage and fabric tools.

4 Replies
AmirBar-Maor
Esri Regular Contributor

@Paul_Christensen 

Thanks for posting this question. 
Would you be able to open a technical support case and provide your data so we can have a look into it?
The polygons of administrative parcels do not participate in the topology and should not create a large dirty area.

If you update a point that is shared with an administrative boundary, it should take a bit longer to update the administrative parcel polygon which usually has a large and complex (multipart) geometry. But it should never feel like the software is freezing, at a minimum it should show a progress dialog.

If you do open a case please mention this post to expedite the process.

 

Paul_Christensen
Frequent Contributor

Absolutely, case created. Thank you Amir

Paul_Christensen
Frequent Contributor

I spoke with a tech rep and ended up with 4 concerns.

Build Extent over several small parcels creates a very large and displaced dirty area. The extent built is not "dirty", however a different area of the map is. The area I built is the small red rectangle in the SW area of the screenshot, but the dirty area is nowhere near that area.

  • This only occurred when working in an area encompassed by administrative parcels. If I created a new tax parcel far outside the boundaries, build extent worked as expected and the dirty area only encompassed the area built.

Paul_Christensen_2-1657025929383.png

When selecting a point that is shared with an administrative boundary, Merge Points locks up UI for minutes at a time and nothing else can be accomplished.

  • This also occurs with very large standard non-admin parcel types. For instance, I have a large lake in my county that has a Zoning polygon. If I select a point that is used by this large polygon, Merge Points locks up.

Paul_Christensen_3-1657026323060.png

 

Align Features does not align admin parcels. 

  • I manually moved several vertices for an admin parcel and a non-admin parcel. I then used align features to bring them back to where they should be. The admin parcel did not align and the non-admin parcel aligned as expected.

Using Copy Parcels to export my fabric for upload to technical service, I had one small issue in the output fabric where two parcel vertices were merged and the lines were not. I only discovered this when validating the fabric and an error occurred be because the lines no longer coincided with the polygons. The vertices were within the horizontal tolerances so Clustering shouldn't have affected this. This isn't related to my original posting, it was just a side bug that occurred when working with tech support.

  • The vertices are .016551 apart and the tolerances are .003280.

Paul_Christensen_0-1657025612826.png

 

 

0 Kudos
AmirBar-Maor
Esri Regular Contributor

@Paul_Christensen 

We will need to look into your data to reproduce and understand the issue. Please submit a technical support case and provide your data.

We are now all busy getting ready for the user conference, so it might take a few weeks until we get a chance to look into it.

 

0 Kudos