nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Historic Lines Issue

AdamHart1

I am trying to learn some of the basic editing operations of the Pro Fabric in a file GDB currently, and I am having an issue when I am merging parcels. When I run the merge tool, the parcel polygons of the parent parcels are set to historic, but the lines remain current. I read on some of the help documentation that you have to merge the line segments separately into an existing feature. However, when I do that, the resultant merged line shows up in the historic layer and current lines layer. Is there something I am doing wrong or what?

Najděte více příspěvků označených jako

Parcel Editing

Parcel Fabric Meetup

Accepted answers

All comments

jcarlson

Screenshots might be helpful to see if there's something particular going in in this case.

Do all the lines remain current? It ought to retire the line that previously separated the parent parcels, while retaining the boundaries defining the exterior of the merged child parcel. Unless a record is re-defining the bearing/distance values, it makes sense to keep them, as the merge record is not "creating" the exterior boundaries.

AdamHart1

Screenshot 2021-05-26 155808.jpg

Yes all of the lines on the exterior of the parcels remain current and the line in the middle is set to historic, which I know is supposed to happen. My issue is with the north and south boundaries of the new parcel in the screenshot. I would like to merge the two segments to have a line with new COGO measurements while the segments get set to historic for the parent parcels. When I do an identify after merging the two line segments (into an existing feature), it shows the merged line in the historic and current layer.

jcarlson

Oh, you shouldn't merge into an existing feature, as that will modify one of the input features and delete the other. When you're working with individual lines, you often need to use the "Set Historic" tool manually. In this case, you'd need to merge to a new feature, then set the input features as historic.

Copy Lines To

Alternately, I prefer to use Copy Lines To whenever possible. When you use the tool against parcel features, it will automatically retire the parcel and its lines, and will create copies of the lines in the active record. In that context, you'd absolutely want to merge your lines into an existing feature, as the existing lines have already been moved to "historic", and you'll be working exclusively with "fresh" features. Delete the inner boundary, delete one of the seeds, then build the record.

For the outer lines, not to worry. Note the global ID of the historic line, and the "parent line ID" attribute in the copy.

When you build the active record, if the new line has all the same geometry and attributes as its historic parent line, linked by that attribute, the new line is deleted and the parent line is restored. The fabric recognizes that if the new line is unchanged, the former line does not need to actually be retired.

But for those newly-merged lines, the change in geometry and attributes leads to the parent lines remaining historic.

ChristineLeslie

When I follow your workflow and merge the lines into an existing feature - I dont see any historic lines created (which is expected). It probably is better to merge to a new feature and manually set the parent lines as historic using the Set Historic tool. I see that the documentation does say to merge the lines to an existing feature and I will update that to merge to a new feature instead.

AmirBar-Maor

@AdamHart1

Beyond the great tips above, we would like to improve the software.

1. Do you always merge lines after merging parcels?

2. Why do you do it? Is this done in order to meet a tax map standard?

3. Would you also do it if the lines are not collinear? if not - is there a tolerance or is that more a cartographic thing?

4. If the merged lines have different COGO Direction values we would have to set the Direction on the merged line as NULL. Would that be OK?

Thanks,

Amir

AdamHart1

Thank you @jcarlson for all the tips on this. I will adjust my workflow and hopefully I can get the results I need.

@AmirBar-MaorTo answer your questions...

1. I don't merge lines 100% of the time, but I do almost all the time.

2. I do this because I maintain the county's tax maps, which are viewable on our county's website to the public. They are used by a lot of people. It's also cleaner to see just one measurement label on them after a parcel combination is done. And so it is easier to see the historic measurements if there is a discrepancy between COGO attributes. Another reason is that I make sure the boundary measurements match the tax description and legal description from deeds because our department does get questions about mismatching measurements quite often from title companies and taxpayers. Most of our county is not platted, so the legal descriptions are either PLSS-based or metes and bounds. So when a discrepancy comes up, it would be nice to see the historic measurements of the parent parcels to track where the error came from. We also do deed research to accomplish this.

3. If the lines are not collinear, I would not merge them nearly as much just because most of our county has metes and bounds descriptions. One exception might be along water boundaries. I would say that a directional tolerance of 2 degrees is the maximum I would use, but we aren't as concerned about the direction less than that tolerance right now. I don't have control points in the fabric right now, but that is a project we will be working on in the near future. Once those are in, then the direction would be more important.

4. Yeah as I stated above, that wouldn't be much of an issue right now since our public facing parcel data does not show directional labels, just distance.

Thanks again.

Adam

AmirBar-Maor

Thanks for the input @AdamHart1

1. Do you also merge 2 collinear curves that have the same radius (e.g. around a cul-de-suc)?

2. Are you able to make the decision whether or not to merge the lines when you merge the parcels?

AdamHart1

1. If the curves are a part of the same tax parcel, then yes I would merge them.

2. I'm not fully sure what you are asking for this one. If you're talking permissions, then yes I am. I am the only one editing the parcel fabric in our county. If you're talking about the workflow, then I don't believe I can merge the lines while I'm trying to merge the parcels. I have to merge them separately.

I had to clean up a lot of the data in the ArcMap fabric by using the "merge courses" tool since most of the tax parcels had multiple segments along the boundaries, which came from the legacy parcel data before migrating to the ArcMap fabric.

AmirBar-Maor

@adamh

We plan to include the capability of merging lines in ArcGIS Pro 2.9. If you have an Active Record and the merged lines are collinear it will:

Mark the parent lines as historic.
Mark any point between the merged lines as historic.
Combine the COGO values and preserve the direction if they are collinear.
Show a preview of the COGO values before you press Merge.

Here is a sneak peek:

Merge Lines with Active Record combines COGO.gif

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.