|
POST
|
Some fields in the parcel fabric are flagged as non-editable or read-only, and some are not. If you look at the properties of the Z field in the Control attribute table, you can see that Make field read only is checked, and we are not allowed to change this for some reason. I'd certainly want to do what you're trying to do, so I find this an odd restriction. If a parcel fabric field is not flagged as read-only, such as SurveyDate, then you can use Field Calculator. My idea for a work around... Export the control points to a regular feature class or shapefile. Do the join and field calculation as you were trying to do. Import the control points from this feature class or shapefile and set the import up so the imported control points will be merged with the existing control points, and in the process update the Z using the imported control point data.
... View more
06-18-2014
11:50 AM
|
0
|
0
|
828
|
|
POST
|
I ran into this a couple of weeks ago. I think you need to edit your parcel fabric's accuracy table, which I'm guessing is currently empty. In an edit session, run the Make Parcel Fabric Table View tool in the Parcel Fabric Tools toolbox > Layers and Table Views toolset. In the tool's dialog, change "Select Parcel Fabric Table" to Accuracy. Then you have a table to open and add accuracy categories to. I opened the tax parcel editing map template with the Bloomfield Township, MI sample data and just copied the values from that database's accuracy table. Viewing and editing the parcel fabric Accuracy table About accuracy in the parcel fabric -Ryan
... View more
03-31-2014
10:42 AM
|
0
|
0
|
422
|
|
POST
|
Hmm, I tried doing what you're describing and didn't have trouble creating a join link between a control point and the beginning point of an Origin Connection to POB line. It even populated the Associated Network PointID on the control point. The only time I could get that error you mentioned to pop up was trying to create a link on the POB connector line (a line point) to the control point. If you join the parcel without any links and it's placed in the right spot, you could then match the control point to the parcel point. I wouldn't think there is anything wrong with that, but hopefully one of the esri folks or anyone with more experience with this than I will chime in here. Sorry I couldn't be more helpful!
... View more
03-21-2014
08:19 AM
|
0
|
0
|
708
|
|
POST
|
Hi Jeff. That error is what pops up if you try to create a join link on a curve, which isn't allowed. If you try to create a link between two regular boundary points, does that work? If you constructed your parcel in its correct space but joined it without any links, then it's probably just floating there without being topologically connected to the surrounding parcels, albeit in the right place. So you'll want to rejoin it and establish the links. Also, after choosing Append File... if you just click Close, the parcel will come in as unjoined if that's ever something you'd want to do.
... View more
03-20-2014
03:19 PM
|
0
|
0
|
708
|
|
POST
|
Thanks for that info, Tim. I'll admit that it took me a while to understand the difference between the construction environment (multiple parcels) and creating a single new parcel. But this explanation sort of just echos what I was wondering about in the first place: that when creating a single new parcel, the Breakline, Planarize Lines, and Create Parallel Offset tools can't be used. They are only available with the construction environment. It seems like they should be available when creating a single new parcel as well, I thought it could be a bug or something rather than designed behavior. For example, I was creating a single new right-of-way parcel. I had an engineer's ROW plan that used multiple centerlines, stationing, and L/R offsets rather than metes and bounds. It was a complex construction and I didn't realize at first that these tools I've mentioned weren't available in this environment. They would have made it easier. And it would be nice to retain the ability to define attributes immediately.
... View more
03-18-2014
09:15 AM
|
0
|
0
|
837
|
|
POST
|
In case anybody else encounters this issue, there is a bug where a parcel's rotation value is not being applied to a line string. The workaround is to use multiple regular two-point lines instead of line strings, but hopefully this will be fixed soon as line strings are ideal for natural boundaries.
... View more
03-18-2014
08:29 AM
|
0
|
0
|
693
|
|
POST
|
When I create new parcels in my parcel fabric, I usually just click the New Parcel button on the Parcel Editor toolbar. From there I can change the plan or template if I need to. The problem is, using this method, the Planarize Lines, Breakline, and Create Parallel Offset tools aren't available. These tools are extremely useful when creating a new parcel!! The other way to create a new parcel is to open the Plan Directory, right-click a plan, and click Construction. Now this method allows me to use Planarize, Breakline, and Create Parallel Offset, hooray. But there are a new set of problems with this method. I can't set the properties of the parcel before it gets built, can't view the misclose or any other closure information, the Parallel Line and Centerline Offset tools become unavailable. Is it supposed to work this way or am I experiencing some unusual behavior with the tools? If this is working as intended... yikes... I'd like to hear an explanation that might help my understanding of using these tools. The inconsistencies between New Parcel and New Construction are both confusing and frustrating.
... View more
03-07-2014
11:30 AM
|
0
|
2
|
1019
|
|
POST
|
Interesting, by snapping do you mean digitizing? If you simply digitized, I would agree with you that you shouldn't see mis-close for the resulting parcels. Can you submit a incident for this and submit the parent parcel as a Cadastral XML? Chris Yes, I was digitizing the river centerline/natural boundary as a line-string, snapping from the last segment added via the construction grid back to the point of beginning. Upon creation, the parcel has no mis-close, but it appears to me that when a parcel has a rotation value and a line-string, opening the parcel somehow distorts the line-string thus "breaking" the closure. I submitted an incident before you replied here, but I will make sure to add a cadastral XML.
... View more
02-28-2014
06:40 AM
|
0
|
0
|
693
|
|
POST
|
Well, I am trying to build a completely new parcel after deleting the inaccurate one, in this case the basis of bearing tool can't be used (it's grayed out). The survey I have uses true north, my coordinate system uses grid north, there is a rotation I can't account for when constructing a new parcel and trying to digitize the natural boundary with a line string off an ortho photo projected in my map. I tried creating a new parent parcel (a quarter-quarter section) and then constructing from parent so I could use the basis of bearing tool. I constructed new lines from the survey then digitized the natural boundary with a line string, using snapping so the parcel's closure was perfect. Everything looked good when I built the new parcel, but when I open it, there is a misclose. Not sure what is going on there. Ryan
... View more
02-25-2014
02:29 PM
|
0
|
0
|
693
|
|
POST
|
I'm using parcel fabric (10.1) and I've got a parcel with very poor accuracy that has a natural boundary (river). I'd like to delete it and construct a new parcel to replace it. The problem with this is, the survey has a basis of bearing which you can't apply when building a new parcel. So if I enter the lines off the survey then digitize the river boundary off an ortho as a line string, the river boundary gets improperly rotated when I rotate the parcel during the join process. This is obviously not the right way to do this, what would be a better way?
... View more
02-24-2014
09:03 AM
|
0
|
5
|
2103
|
|
POST
|
I gave this a try (in 10.1) and Analyze Differences for me came up with 63 differences. I noticed that the vast majority of the differences were apostrophes being translated as spaces. Annoying but not a critical issue. Did you check if the "missing fields" were actually missing? Those fields you mentioned were there for me. Most of the remaining differences were: Dataset Property: ControllerMemberships="BuildingInteriorSpace_Topology 5 1 1 false" vs. "". I have no clue what that is. Two of the differences, Dataset Property: Height="1" vs. "4567" and Dataset Property: Width="1" vs. "6661" for Hillshade, are simply from exporting schema only. I agree that XRay should be able to do a better job of minimizing differences between exported/imported schemas, even if some of the differences are trivial.
... View more
02-21-2014
07:14 AM
|
0
|
0
|
421
|
|
POST
|
I noticed this too. jmward made a post a couple of days ago about how importing the LGIM schema into a new geodatabase turns out a large number of differences when you "Analyze Differences" between the new and old GDB with XRay. When I imported LGIM schema with XRay and ran the differences tool myself, I also had a large number of differences but I noticed that the vast majority of them are simply missing apostrophes. I tried exporting and importing an XML workspace document using geoprocessing tools rather than XRay and it did transfer the apostrophes correctly this way, but this doesn't allow you to change the spatial reference.
... View more
02-21-2014
06:54 AM
|
0
|
0
|
447
|
|
POST
|
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
... View more
02-20-2014
09:11 AM
|
0
|
0
|
698
|
|
POST
|
I'm glad you got the editing workflows functioning, I ran into a similar problem and was trying to remember what I had to do. I think, when trying to use the TaxParcelEditingMap.mxd template, I had to remove all of the parcel fabric layers from the map, enable the information model in the catalog window, then drag the fabric back into the map. Then the workflows functioned.
... View more
02-19-2014
12:33 PM
|
0
|
0
|
847
|
|
POST
|
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!
... View more
02-14-2014
02:22 PM
|
0
|
3
|
3663
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-07-2024 12:35 PM | |
| 1 | 07-26-2018 04:07 PM | |
| 1 | 02-09-2017 10:27 AM | |
| 2 | 02-07-2017 03:20 PM | |
| 1 | 02-29-2016 02:15 PM |
| Online Status |
Offline
|
| Date Last Visited |
07-01-2025
08:41 AM
|