Sorry if these questions have been asked before. If there is some documentation that already covers this, let me know. Anyway, I have read up quite a bit on Parcel Fabrics as implemented under ArcMap but never got around to actually creating one. Now that ArcGIS Pro has significantly expanded both the scope of how one can work with parcel fabrics along with the "ease" of creating one, I am looking at finally taking the plunge. That being said, I do have a couple of questions with respecting to preparing our data prior to using it for building the Parcel Fabric. My main parcel data source will be a polygon feature class provided by the county assessor that contains parcels and right-of-ways as polygons. My current questions are:
1.) What should we do with the right-of-way polygons? Do we leave them in the source parcel polygon FC and let them get imported into the Fabric along with the parcels or should they be removed first and imported via a separate process? Is best practice to use right-of-way polygons or it is better to use road centerlines instead (which I also have)?
2.) What do we do about complex and unusual parcel types, such as parcels that reside wholly within the boundaries of another parcel or that are broken up by intersecting parcels? Below is an example of the sorts of parcel geometries that I am having to deal with (right-of-way polygons are shaded in grey):
Anyway, I am sure I will have more questions as I get more into the weeds on this project. If there is a better place where I should be asking these sorts of questions, please let me know.
i'm still trying to learn how to use my fabric in pro but this is what i've done in vanilla arcmap -
the performance of the fabric went down significantly when i imported my ROW polygons and unless they were *absolutely* *perfectly* *aligned* with my parcels it didn't look for function right. so those are kept in a regular polygon FC under the fabric. i maintain a street centerline line FC in the same way. when you import a line FC like that, it gets converted into a .5' or 1' polygon and it was nightmarish.
anyway your townhome or landlocked parcels will be fine. the fabric will generate connection lines between the surrounding parcel and the interior parcel that keeps everything in line.
what i did initially to test the landlocked or donut parcels (because i had the same concerns!) was just find the most complex part of my parcels and make it into a test fabric to see what it did. some of the documentation is murky and i just made a sandbox fabric to mess up and i could just delete and start over with no real tangible loss.
just as an aside, these are some things to watch out for if you have these master planned subdivisions that have huge sweeping curves and a ton of tiny lots:
-MAKE SURE ALL YOUR CURVES MATCH EXACTLY!!!!!!! THEY WILL CAUSE GAPS IF THEY DON'T!
-the fabric may generate rogue connection lines where they don't need to be when you're working block by block. i don't have an example handy - but if there's a multilot block that you're constructing from a parent parcel there's a chance the fabric will think it needs a connection line but it doesn't. i'm still not sure what causes it.
Awesome, thanks for these tips Anna!. They are definitely helpful in avoiding possible pitfalls. Those of us who have complex and legacy parcel geometries really have our work cut out for us.
yeah. i found from talking to another office similar to mine that they migrated from shapefiles that were held in a topology and they had a worse time migrating than i did. they didn't have any COGO data or anything really to work with.
when i came on in 2015 we migrated straight from the old coverages we'd been using for decades and apparently that's why we didn't have a boatload of problems. some of my issues were only unique because of the age of the software we'd been using.
don't forget that legacy systems have unique problems so a solution may have to be hammered out without specific help from the documentation. you got this.
Well, thanks for the vote of confidence. After removing the RoW polygons from my source parcel layer, I am finding that there are quite a lot of errors. Things like RoWs that are broken/incomplete, intersected by owner parcels, not the current path the RoW follows, or RoWs that are just straight up missing. Fun Stuff.
Yes, of course. The issue is that after doing so, it because obvious how badly ROWs were actually managed by the city/county. Not so much a data problem, but a land use policy problem that stretches back decades. Just trying to figure out how we are going to clean this mess up.
ohhh man get ready to find like 20 years worth of mistakes. i recall finding mistakes that dated to before i was born (34 year old mistakes!!!!). if you have centerline data, you should be able to make a temporary "fix this" polygon by doing a select by location with your centerlines and parcel data. that should make the QA process go faster.
Yeah, that was my thinking as well. What I am finding out is that in decades prior the city allowed developers to build public roads rough-shod over intervening parcels without going through an entitlement process to create ROW clearances for these roadways. In some cases they were just granted easements and in many others they didn't even bother with that.
when i came across easements similar to yours that don't show up on any of the documentation (plat, survey, metes & bounds description, etc) and i make a placeholder parcel for it in my lots & units layer. i set up a plan for it with any relevant information and recording numbers for the ghost ROW. i don't cut it out from my tax parcels - which is what gets exported for public use - because it doesn't appear in the legal parcel description. it's just there for reference.
that's the really sticky part - like you'll have to make a determination on how to best handle that by your state's applicable laws and your office's purpose. i maintain what ESRI calls assessor parcels, so i'm pretty hard bound by legal descriptions. conflicts and issues like this are a total pain.