Official Workflow: Export Tax Parcels from ArcGIS Pro Parcel Fabric

[JohnFell]

Our organization is required to export parcels to multiple data formats (e.g., SDE feature class, shapefiles, etc.) in a multi-user parcel editing environment. I was curious if the official workflow for exporting parcel types from a branch-versioned geodatabase is discussed in the recent meetup video Parcel Fabric Data Management and this blog post Query Branch Versioned Parcels using spatial views?

I ask because we are planning our own migration to the ArcGIS Pro Parcel Fabric and we rely heavily on the ability to export parcel fabric parcel types.

I am also concerned because my colleague @Geographic_Mythos alerted me to an issue with intermediate reconcile and post operations resulting in duplicate, parcel feature variations displayed in the final SQL view (see attached parcel id). If this is an unavoidable side-effect of archiving, is there another solution that would display the unique features for a specific parcel type's latest reconcile and post operation? Or perhaps this has been resolved with the most recent version of ArcGIS Pro 3.2?

We appreciate all that you do and thank you for any help you could provide.

@KenGalliher1 

@AmirBar-Maor 

@JasonCamerano 

@DanielStone 

[Geographic_Mythos · Accepted solution]

@JohnFell Glad to see you guys are still working toward your goals in getting into the Pro Fabric. 

I can't speak to the 3.2 question (still testing it locally myself atm), but I can say that those two links from earlier do not 'completely' address your concern from what I recall. We've spent some more time with some of the Land Records group and a different individual in Services to flush out some more of the details in the SQL in the back end to deal with that.

We've got a lot of things that happen with the View we've been working with the teams on from a bunch of runs at this. Some of our findings are editing workflow specific, meaning we could easily avoid some of the duplication or potential errors by being more mindful of our workflows. Some of my other findings, would suggest some interesting behaviors in the Archival methods as they exist presently. 

There are quite a few things that I could enumerate on this topic, but it would be a fairly lengthy list to post up here! Let me know if you want me to go through them.

[JohnFell]

@Geographic_Mythos Awesome! Thank you for that info. We will consider the archiving aspect of the branch-versioned data in our workflows. I will reach out to you offline to get the details. 

[AmirBar-Maor]

@JohnFell 

Could it be that both you and @Geographic_Mythos  think too much like DBAs?!  🙂

You can export data from your enterprise connection to multiple formats using geoprocessing tools. If the connection is to the default version it it will only export the features in the default version. 

But...

Why all this export and ETL when you can provide a service in a map and allow interested parties to download data themselves? That way they know that they are downloading the most current data.

Of course, once downloaded - the data goes stale... this is another advantage of using a service.

IMHO  - we should move away from ArcInfo Coverages and Shape files.

You can also publish geoprocessing services that extract data or use the screening widget mentioned in this post - https://community.esri.com/t5/arcgis-web-appbuilder-questions/export-to-shapefile/td-p/1047422

I remember the days when we had our own copy of imagery files - nowadays we use a service instead.

I hope this helps.

[Geographic_Mythos]

All good points Amir, and sure I think more like a DBA, but some of my requirements cannot be fulfilled with the service as it presently is configured to work.

At the moment, the way an Archive behaves limits me to a calendar representation of our data. Which I am sure for many people is fine. However, many changes to the land record, do not necessarily fall within the calendar year in which an edit could be reasonably applied.

Further complicating that point, a lot of our data requirements have me posting 'stale' data for the public at large to consume for not just the current version, but past versions as well. Legally, certain changes to the property record can go back as far as 5 years, and in some limited scenarios, they can go back 10.

Creating a View of those transactions outside a calendar, allows us to preserve the data for a tax year in which something was applied. We may have to change parcels in place in the Fabric, that had a change filed lets say today, but was effective for 2 years ago. While the service can easily show this change today, it is not great at having to present data that was for 2 years ago, and still show how that changed progressed to today, something I know that I have spoken with both you and @DanielStone about at length.

Were I just showing people today information, I would not hesitate to  just putting out a simple service as opposed to ETL, wouldn't argue that point at all, and if my reality was that simple, well, I wouldn't be talking about it here.