This topic shows up in a 2019 post but an update would be helpful. We have two separate Parcel Fabrics but each has a different projection and we would like to merge them. Obviously, they must be in the same projection. Does the Parcel Fabric require special consideration(s) when re-projecting?
Good news: the geoprocessing tool Project supports parcel fabrics.
If the target spatial reference uses a different linear unit, the COGO dimensions will convert the values accordingly.
In your case you can:
Neither parcel fabric will reproject. Identical error message for both, see below. Both databases passed topology checks.
Is this an ArcMap Parcel Fabric you are trying to project? If yes: this is not supported.
Please make sure to provide the FEATURE DATASET as input and not the parcel fabric data controller.
If this is a feature dataset that contains an ArcGIS Pro parcel fabric it should work. If it doesn't;t work with your data please contact technical support.
In this example, I've used ArcGIS Pro 3.3 and accepted the defaults. Make sure to select the
1. The District 3 GIS Analyst tried to drag and drop the Feature Dataset from one of our parcel fabrics into a new and fresh parcel fabric but received an invalid error again.
2. Then he tried the “Copy Parcels” tool for the Ada fabric to a new fabric and dataset, but received a “geometry has null Z values” error. Some of our surveyed control points are x and y values only so they logically have a null Z value. Error message is attached.
The "geometry has null Z values" error message has nothing to do with a missing Z Attribute value. It is hard to speculate and would be best to examine the data, environment, and workflow.
Please contact technical support and submit a case.
We finally took a digital sledgehammer approach by exporting all data as shapefiles from the two differently projected Parcel Fabrics. Those shapefiles were then all reprojected to a third projection after which they were imported into a brand-new Fabric with that third projection. Time required for migration and data table cleanup was a little over 16 hours. Fabric functionality appears to be unimpaired, and all data (points, lines and polygons) is correctly spatially located. Consider this thread to be closed now.
It's great to hear you solved the issue. I would recommend not to use SHAPE files. They will densify your true curves, truncate long field names, have no concept of domains and the list goes on... Instead always export to a file geodatabase.
If you have corrupted your true curves you can either repeat the process using a file geodatabase or use the geoprocessing tool Simplify by Straight Lines and Circular Arc (AKA 'SLACA'). Just make sure to supply all polygons and lines as input in the same run to avoid creating a topological mess.
I did see the curve issue but haven't addressed it yet. Truncated field names and domains were identified and resolved. I believe we did try to export to a file geodatabase but it was not possible because it was a different projection.
If you export to a feature dataset in a file geodatabase you are constrained to the spatial reference of the feature dataset.
But if you export to the root level of the file geodatabase you can use any spatial reference.
You can always keeping tidy by creating a feature dataset that matches the spatial reference of the source data and then export to it.