POST
|
We upgraded to 10.4 last month and our department was also upgraded to Windows 10. Our parcel fabric is in the process of being converted from conversion status to record status. In other words our parcels that were imported from a geodatabase will be converted to record as we work through our county. I have been working in an area converting it to record and what I have noticed since the upgrade is that my join points are not sticking!! In my workflow I will re-create some parcels then rejoin an adjoining boundary to the new parcels. Then I started noticing that my previously joined - point to point - points are now line points and I have to rejoin them in addition to joining to my new parcels. This is happening over and over again and I'm getting really really frustrated!! One other mapper has noticed the same thing. I used to be able to set a poly in the fabric, create new polys, join the existing to the new - just in that area and the rest of the poly would stay put. Now they're pulling away from their set join points. Attached is a pic where the line points had previously been all point joins (point to point). Why the change I wonder? ~Betty
... View more
10-04-2018
01:04 PM
|
0
|
0
|
223
|
POST
|
What if you created a field for your parent parcel number and manually edited that field when retiring a parcel? Would that work?
... View more
08-30-2018
09:32 AM
|
0
|
2
|
692
|
IDEA
|
I have accidently hit the 'Switch Selection' button on my table (of a single selection) instead of the Clear Selection button and now I'm waiting waiting waiting waiting! for it to switch the selection to over 79k records. AAArrgghhh!! If only I could stop this re-selection otherwise if it doesn't refresh soon I will have to bail and lose my edits and I don't wanna #StopButton
... View more
05-31-2018
10:38 AM
|
0
|
0
|
184
|
POST
|
What happened w/us is that we were using a custom maptile checkout program that wasn't clearing out the version locks after the version was posted & deleted. What we ended up doing was, in an edit session, select the parcel with the lock and attempt to open it. For us, this would generate an error message about the poly being locked and it would reference the version name that locked the parcel. The owner of the version would then need to create another version with the exact same name, make it active, start editing, reconcile & post, stop editing then delete the version. This removed the parcel lock and we could go forward. I hope this helps! ~b
... View more
03-12-2018
11:56 AM
|
0
|
0
|
1083
|
POST
|
What does this message mean? And how can I get around it? Join Parcel, "Unconnected parcel groups will be split, try joining again."
... View more
06-02-2017
10:01 AM
|
0
|
3
|
525
|
POST
|
Thanks again Anna! Good to know, I hadn’t thought of looking in the job book
... View more
04-19-2017
12:27 PM
|
0
|
0
|
1083
|
POST
|
Thanks Anna. Are you working in a parcel fabric? I was thinking the parcel fabric was different a different animal than a geodatabase. We used a GDB prior to parcel fabric and we did have to compress/rebuild/etc regularly even though it wasn't versioned. I will definitely check into that though. It did cross my mind that some sort of 'clean up' needed to happen. This is all happening now that ALL of our parcels are in PF and all of the mappers are working in it although I don't know if it's related. Thanks again, I appreciate the reply!
... View more
04-19-2017
10:26 AM
|
0
|
3
|
1083
|
POST
|
We have been working in the parcel fabric for a couple years now. We use versioning and have 6 editors doing parcel maintenance. I am one of the 6 but I also check the fabric for things like missing start/end dates, construction polys left in the fabric...things like that. Lately, even after a version has been posted and deleted, when there are polys that need to be deleted and I attempt to do so I get an error stating the parcel is locked but it doesn't happen to all polys. I have been able to delete some. These versions have been posted & deleted at least a week if not a month ago. Right now I have about at least 60 polys that need to be deleted. To keep them out of the active parcel fabric I can make them historic. I can also edit their attributes, but I cannot re-join them nor can I delete them. Does anyone know why that would be? I understood that once a version is posted those parcel locks are supposed to disappear. (Still true if the version has not been deleted right away?) Also I believe that some of the editors post their version, hang on to it and delete it a couple days later. Could there be some sort of interference with posting a version but keeping it around in the version manager for a couple days longer? I know one editor, when she couldn't delete her parcels, created a new version with the original version name, reconciled and posted then deleted that version and started a new one but was still unable to delete her parcel(s) - now part of the 60. I'm stumped! I hope someone has a clue for me that I can chase to figure out why this is happening.
... View more
04-18-2017
04:58 PM
|
0
|
9
|
2206
|
POST
|
Thanks again Tim. I suspected the rotation was as you explained. I tried to find the parcel that was flying away when I went to rejoin it (I had asked about this previously). Since this conversation started I have moved on to another area to test. If I find the suspect parcel, or one like it, I'll make better notes and screen shots and send it to tech support. I'm pretty sure there wasn't a long connector line, although there is an area that had a ridiculous radius...49,220.69' (from a highway r/w so....there ya go) but I can't recall if the suspect parcel was part of that or not. For now...moving on. I wanted to let you know my successes and how I got there. I found that replacing, not recycling, parcels/descriptions/subdivisions, etc worked best. Initially I thought I could take a parcel, unjoin, re-enter and be good to go. However with the accuracy factor, unless I also include that in my recycling process (all the lines in the grid were of an accuracy of 6), it was slow and had, on occasion, generated unexpected results that were hard to resolve. Since we are trying to update our converted parcels to record, it makes more sense in the long run to delete an area (I don't even unjoin them for safekeeping any longer), take a bite sized area, delete, re-create and join. Then I take the parcels touching the exterior boundary and make them match at least via a join process for now until I can re-create them. This process also helps keep our live parcels intact until we're through with the working maptile. I liken all of this to playing chess, not checkers It took two more areas after the first before I came to this conclusion. I was able to get through an area in a week (approx. 89 Lots/Units, 75 Tax Parcels (which most are Duplicated or merged from Lots) and 6 Subs) and get into the Adjustment portion (unfortunately I have a bad section corner so I couldn't get to a final adjustment but at least I could identify my problem areas and fix what I could). I considered this a success. The previous 2 areas took much longer. Also, using the Parcel Fabric Control toolbar is helpful in identifying problem areas as well as having the ability to recalculate lines (distance and direction) without record. If this sounds like a ridiculously long, laborious process and there's a better way, I'm open. In the meantime I think our plan will be along this route I've described and we'll keep on keeping on while processing our normal workload too. It'll be a beautiful thing when the next generation of mappers come aboard! <?!?> Thanks Tim! You've been a great help! ~betty
... View more
06-22-2016
04:10 PM
|
1
|
0
|
1014
|
POST
|
One question I would ask is how do I use the Rotation and Scale information in adjustments? When I reviewed certain parcels after the adjustment their Rotation & Scale did not seem cause for concern however I did have one Lot with a 359-37-37 Rotation and others more in the 0 range of rotation. Scales ranged from 0.99 to 1.00 (ish) When is there concern? It never seemed to be a problem for me but I might not have known what to look for. And while I'm asking, sometimes when I rejoin a parcel it flies out of view. I have to zoom out, sometimes quite are, to find the parcel and move it back in place. What causes that? The error residuals do not look serious. Does this have to do with Rotation and Scale too?
... View more
05-11-2016
11:35 AM
|
0
|
1
|
1014
|
POST
|
Thanks once again Tim. Your information and points to my specific problem were invaluable! One of the biggest things I learned from your reply was the direction of Connection Lines. I like to use them when I have a connection between section corners, or other corners that aren't necessarily part of the Starting point to POB Origin Connections. That will be helpful moving forward. I also installed the patch. So...here's what I did and here's what I found. After your last reply I was able to get my one problem area (described above) fixed by working with the parcels to the N and S, editing their distances (merging courses, unjoining, editing and rejoining) and also fixing the Accuracy. I suspect that was one of my biggest problem. The parcels to the N and S were part of the plat that had little to no record information on it and I was saving its adjustment for last. Once that problem area was fixed I moved on to the oldest plat. That plat originally took up the whole quarter section. Since its recordation (100+ years ago) there have been many plats cut out of it. When I started this journey I initially reviewed the lines common between the one old plat and the new plats. I populated the old with the new(er), since the old had little to no record information. I'm not sure that was a best practice looking back. Because of all my editing I knew I had to rejoin the old plat and the original dedicated R/W in order to pick up line points I knew had been dropped along the way. In the course of rejoining I would find errors, fix them then go back to rejoin once again. One of my biggest problems was a 49220' radius curve along a highway. That curve gave me grieve in that the radial lines did not always get to the same radial point. The Mean point tool got a workout! In the end I was able to connect all the parcels that shared the curve (a dozen or so) to one radial point. Finally it seemed I had fixed everything and rejoined the old plat & r/w and was ready to start the final adjustment stage. I would run the adjustment, fix an area with large distant errors, save, run the adjustment again, find more errors, fix, save, run until all I had left were Line point errors and fairly large distance residual which was due to the radial point. The final adjustment ended up with a 60' distance error (a 20' distance residual) because of that radial point. I did not know how to fix it without doing major adjustments to the parcels. My justification for keeping such a big residual was that as long as the radial lines are ending up at the radial point, and the radius is so dang long(!), 60' wouldn't reflect any huge difference in the map. The other errors were all pretty small however there really was a long list of Line point errors, nothing huge just a lot of them. I could tell they were primarily from the old plat and its r/w. I let it go! All along, except for the radial point, most of the distant residuals were fairly low. I didn't have any Close points so that tells me I did a good job taking care of those on the front end. Without the old plat & r/w in the mix I never had more than one or two line point errors. I had four well fit control points, and other than the flinging to Canada, control points were never a problem. If I were to do it over again, I would not set individual Accuracies on the parcel lines. I would let the Accuracy hierarchy rule, with exceptions of course (there will always be exceptions). I think I would edit the new plat, updating their data to record, then place the old plat in as 'new', meaning I would add it whole and cut the newer plats out of it. I think that would have saved me more time than it took to fix it along the way, primarily because this was converted data edited with record data which, I think, made the errors more prominent. I hope all made sense and I hope anyone else out there getting their feet wet in the parcel fabric adjustments will get some good points and help from what I went through and what Tim shared. I think I will go back and use the Parcel Fabric Quality tool to see how that works and what the quality of my test area ended up to be. After that, my next step is to write this up for my boss and find out where we go from here. I might want to try an area without so many parcels but maybe a few old plats and less control. I think I'm up for it!
... View more
05-11-2016
11:11 AM
|
2
|
0
|
1014
|
POST
|
Thanks Tim! Your reply was very helpful. I made some discoveries and some changes from your information. Plus I found the reason I was getting a '##' on every line after I got my first successful adjustment. I had to re-joined a parcel to a control point and it sent the control point up into Canada (maybe not that far, but it was far, far away!) All of my lines were then 10s of 1,000s of feet off. No wonder everything was suddenly out of whack! Once I fixed the XYs of the control point the adjustment was great. I continued doing small areas of my test section, moving from the oldest to the newest subdivisions and had continued success until...... I hit a problem area. I do get a successful adjustment but when the parcels adjust, it moves a couple parcels in a way that is unacceptable. I cleaned up some errors (Invalid line categories in particular) and got the same or similar results. I've narrowed it down to 4 points that are adjusting 3 to 7+feet. I reviewed the common N-S lines and made their bearings the same direction (some were going NW/SE and others NE/SW) All are now NE/SW except for my one record parcel. The reason I didn't make all parcels of the one direction is because I have an old, old plat without bearings and a newer plat with a NE/SW bearing (the source of my decision to go with the NE/SW directions). But I do have a record description within the old, old plat that has a NW/SE bearing. The newer plat and the record description are about 150' apart. My next suspect that I thought might be causing a problem is a common line with a road r/w from within the old, old plat. I unjoined the r/w but the adjustment results were the same. I know it is difficult to follow my diatribe and I've included 2 screen shots that I hope will help paint a picture of what I'm trying to explain: The image on the left (or top - with the yellow points highlighted) is pre-adjustment with the points that have the largest movement highlighted. The image on the right shows where Point OID 65460 & 65459 moved the most. The other two still moved 3+ ft. I am having a hard time determining why those points adjusted so far. Everything measures close to record distance (where there is record). I've checked everything within the parcels and their adjoiners. I've re-joined them hoping that would help. The only other issue I'm not sure how to resolve, and I don't know how much it could be contributing to this movement, is the radial lines for the parcel labeled '#09186' and it's overlaying TaxParcel. The radial lines into the cul de sac are listed as 'Incorrect Category - Radial' in the adjustment report. Hmmmm....I'm pretty sure they're radial lines! However their bearings pretty much match the lines leading to the point of curve on both sides. Not much I can do about that. This is only about a quarter of the total parcels included in this adjustment. I can't adjust this area alone as it does not have joins to control points. The parcels and small subdivision to the north have the control connections. The other (smaller) issue at this time is...why do my control points' XY coords change so radically when I join, or re-join, a parcel to it? Per Tim's note, I added a Z value to the control points that were Null hoping that would help. Suggestions anyone? Could this be related to something outside of the area of adjustment, a parcel that is not in my selection? Maybe the accuracy attribute is an issue? The parcel labeled '#10085' and its overlaying TaxParcel have an accuracy of 3, the underlying lot labeled '39' is Null but its related plan is a 6 (also related to this plan is the r/w which I unjoined) . I assume this is ok as the lot & r/w will inherit from the plan's accuracy. Looking forward to any ideas or suggestions. Thanks again! ~betty
... View more
05-04-2016
12:54 PM
|
1
|
0
|
1014
|
POST
|
Hello~ We have been in the parcel fabric for a couple years and all is well Our data was computed when brought in to the fabric. We're now heading into our next phase of doing adjustments however we know we can't do adjustments on computed data. The plan is to get parcels updated with record data and start doing adjustments. We have great control in most areas. I'm getting started now and have my test area. I've added the record data and accuracy to everything I can in my test area. After that I did an adjustment to approx. 285 Lots & Units, 192 Tax Parcels, 25 Subdivisions and 2 Encumbrances....and it failed miserably. I reviewed the log, fixed the points then tried to fix the lines that were bombing out (the ones that had the double pound sign which I read is a fatal error, guaranteed to fail the adjustment). The only thing I knew to do to keep these lines from creating the fatal error, was to change their accuracy to a 7 - a non participant in the adjustment. This is not ideal but for now, and to get a successful adjustment, it seemed the right thing to do. Still my adjustment fails. My next step was to focus on a smaller area. This next adjustment is approx. 39 Lots & Units, 20 Tax Parcels and 3 Subdivisions. I had a couple fatal errors that were easy to identify (and taught me a little more about line types - Precise Connect vs Orig Connect vs Connection lines). I fixed those lines and adjusted again. Now the adjustment is taking over an hour and it looks like every single line was the double pound sign fatal error. I'm not sure what I'm doing wrong. I'm looking for any tips and tricks. I've read the best practices and ideas for data that is poor quality. It suggests starting with some new parcel data then adjust around the new parcel(s) however we want to bring our poor data up to good data then be able to adjust from there. That seems like a reasonable plan. Some of what I'd like to discuss include: How important are the attributes of the lines, as in the Computed field? If I've changed the line to reflect the record, do I have to go back to every line and change to 'Computed = No'? Does the line type have to match the poly type? We've been guilty of creating a TaxParcel and "oops! that should have been a Lot not a TaxParcel" and we've only changed the attributes of the poly. Is that a big no-no?? I also notice that 'ParcelType' field in our Line table has Nulls, '0' and '-1' (<--that doesn't seem right). This is enough to get the conversation started and hopefully answer some questions. Please let me know how it's going for anyone who is having success and your best advice Thanks much! ~Betty
... View more
04-21-2016
10:51 AM
|
2
|
7
|
7031
|
POST
|
Here's what I found out and here's what I did: The error appears to be from a multipart poly with a portion that touches only by their corners (think of 2 business cards touching at the corners). I broke up the poly into 3 pieces and created a geodatabase with a dataset for staging. Via that process of creating lines & a topology, I used the 'Load a Topology to a Parcel Fabric' tool which appended that parcel into my ParcelFabric. In the fabric, I merged those polys back together. Afterwards I had 2 or 3 other parcels in different staging sets with the same problem and was able to resolve it via this same procedure. I hope this helps anyone else who may come across this type of error or something similar.
... View more
11-20-2013
08:18 AM
|
0
|
0
|
398
|
POST
|
Hello~ I have created my Type5_Subdivisions staging polys and arcs. The topology is good and now I'm ready to use the 'Load A Topology to a Parcel Fabric' tool. All parcel Types have loaded ok except for one poly in the Subdivision type5. The error is: 'Line sequencing error on parcel 1323 (parcel not imported)' I have found a definition for a line sequencing error but how do I fix this so I can get this one parcel into the fabric with the rest of its buddies? It is a rather large parcel with many 'holes' in it from subsequent subdivisions however I have other similar polys that have loaded ok. Maybe I could dissolve the lot polys again and extract the one poly into a second Type5_Subdivision staging dataset and then import that into the fabric. <--- That did not work 😞 Any other ideas would be appreciated! This is only 1 of 47 townships that will be eventually imported and if I can figure this error out, or at least a work-around, I'll have more confidence with the remaining parcels. Thanks 🙂 ~b
... View more
11-04-2013
11:05 AM
|
0
|
1
|
3426
|
Title | Kudos | Posted |
---|---|---|
1 | 06-22-2016 04:10 PM | |
2 | 05-11-2016 11:11 AM | |
2 | 04-21-2016 10:51 AM | |
1 | 05-04-2016 12:54 PM |
Online Status |
Offline
|
Date Last Visited |
01-25-2022
11:41 AM
|