Workflow for editing Right of Way in parcel fabric

[RyanKelso]

I�??m having trouble coming up with a good workflow for editing the boundaries between existing Right of Way and Tax Parcels in a parcel fabric (v10.1).  I'd love to get any ideas from experienced parcel fabric users or hear how others might do this.  Here are some things that I think are contributing to my problem and some specific issues I'm running into:

• Our countywide parcel and R/W data is of poor quality but is the only reasonable option for creating our parcel fabric.




• R/W polygons are, for the most part, only split at township lines.  Thus, many of them are large �??spider web�?� polygons with multiple donut hole areas which can make them difficult to work with.  More on that after the next two points...




• I�??m trying to take a day-forward approach to improving parcel accuracy by completely re-creating parcels using surveyed information, when available, before completing parcel splits, BLA�??s, etc.  This often creates an obvious mismatch between the re-created parcel�??s road frontage lines and the existing R/W lines.  Especially when curves are involved, as they often are with R/W, I�??m not sure what approach to take to edit the mismatched R/W lines so they align with the parcel lines exactly.




• I�??ve tried to fix small portions of R/W by using Construct From Parent, marking some lines unbuildable and constructing more accurate lines, or by unjoining then deleting and constructing new linework.  By only trying to fix a small portion of a large R/W, I�??m trying to mix accurate linework into inaccurate linework and it never seems to work very well.  Things don�??t line up very well or get distorted.




• If I use Construct From Parent on any of these �??spider web�?� R/W polygons that have the donut hole areas, when I Build Parcels it creates R/W island polygons in every donut hole area.  This leads to some annoying clean-up work to delete all of the island polygons and the potential to have erroneous parcels if I fail to catch all of them.  Is there any way to prevent this, besides the obvious route of splitting the R/W polygons so there are no longer any donut holes (a big task for a 2500 sq mi county)?




• If I unjoin a R/W that spans a large area, edit some lines, then join it back, I�??ve got hundreds of join links to create.  Auto Join doesn�??t always seem to work very well, but I don�??t know if I�??m quite using it right.  Any thoughts on this approach?

If this doesn't make sense I can show a simple example.  Thanks for any help!

[ChrisBuscaglia]

rkelso,

I wouldn't maintain anything in your parcel fabric that doesn't represent the original record.  In your example, the ROW that you are maintaining is not a true representation of the legal record.

A couple suggestions

1. Use simple feature classes and "cut" the ROW by Subdivisions  - that is, if you maintain them...sounds like you may not be maintaining them.

2. Delete the large spider-web parcels and simply leave them off until you slowly replace ROW over time - as new subdivisions are recorded, or have time to re-enter the Subdivision boundaries.  The lots then can be used to "cut" into the subdivision parcels (using the remainder tool).

Chris Buscaglia
Local Government Solutions Team

[RyanKelso]

Thanks for your reply, Chris.  I'm interested in your thought about not maintaining anything in the fabric that isn't a true representation of the legal record, since that is basically everything for us.  Gotta start somewhere.  I do like your suggestions.  Could you elaborate a little on your reasoning for this?  For one thing, it seems to me that the parcel fabric editing tools are just not very well suited for the kinds of edits I described in the original post.

Our tax parcels are also approximations of the legal record, some are pretty close and others not so much.  As we are preparing to switch to parcel fabric, my testing strategy has been to recreate tax parcels using the recorded information as needed for further maintenance, and to move (join) existing points to the more accurate ones.  You mentioned subdivisions; I have them but the data is even less reliable so I don't plan on importing them to the fabric.

Ryan

[ChrisBuscaglia]

Thanks for your reply, Chris.  I'm interested in your thought about not maintaining anything in the fabric that isn't a true representation of the legal record, since that is basically everything for us.  Gotta start somewhere.  I do like your suggestions.  Could you elaborate a little on your reasoning for this?  For one thing, it seems to me that the parcel fabric editing tools are just not very well suited for the kinds of edits I described in the original post.

Our tax parcels are also approximations of the legal record, some are pretty close and others not so much.  As we are preparing to switch to parcel fabric, my testing strategy has been to recreate tax parcels using the recorded information as needed for further maintenance, and to move (join) existing points to the more accurate ones.  You mentioned subdivisions; I have them but the data is even less reliable so I don't plan on importing them to the fabric.

Ryan

I'll restate.

I should have said "maintaining anything that isn't the best representation that you can come up with for the legal record".

My point was more about the spider-web road, this isn't how it was conveyed and no matter what your spatial accuracy is, I wouldn't maintain it.

Our Land Records maintenance solution is designed to work with any level-of-accuracy parcel base.

Chris Buscaglia