|
POST
|
Hello All, These are good questions/comments. There are many ways to integrate parcel data from many sources into the Parcel Fabric, including shapefiles/CAD files/etc. One way to think about it is to build out a simple GP tool that creates a loading source for new parcels coming in (the same way that you migrated parcel data to the Fabric to begin with). If the data is a polygon shapefile, convert the polys to lines, validate the topology and load them to the Parcel Fabric as unjoined (or joined depending how well they fit) and go through the process of joining them (or not if you chose to load using joined parcels). You can also simply copy-paste new line-work from any source into a new construction and build parcels...but you'll have to manually re-assign parcel attributes. Chris Buscaglia Local Government Solutions Team
... View more
01-23-2014
06:38 AM
|
1
|
0
|
826
|
|
POST
|
Is it possible to get a closure error ratio (MiscloseRatio property) reported back in Deed Drafter? The distance and bearing are useful, but the closure error ratio tends to be the crux in deciding the accuracy/validity of a legal description. I really hoped this tool would be something I could implement with my staff but without the closure error reporting I have to reconsider current workflows, etc... which just isn't worth it. Just one clarification, it is a very good tool but could be awesome! The misclose ratio is currently not supported in the user interface, but is something that can be viewed when integrating the new parcel into the Parcel Fabric using ArcGIS desktop. I would add this to http://ideas.arcgis.com/. Chris Buscaglia Local Government Solutions Team
... View more
01-23-2014
06:31 AM
|
0
|
0
|
1489
|
|
POST
|
Bottom line, without getting into too much detail, you'll want to make sure not to remove anything from the database that came stock with the Local Government Parcel Fabric (some standard Parcel Fabric fields cannot be deleted) , instead modify domain descriptions, extend domain values, and change layer names to represent local nomenclature. Chris
... View more
01-07-2014
08:02 AM
|
0
|
0
|
3943
|
|
POST
|
One thing that I didn't mention, but is a very important item. The domains and set of values can be modified and extended. [ATTACH=CONFIG]30286[/ATTACH] For example, I'm looking at the simultaneous conveyance type here - you can see the available (not exposed stock) values that represent different subdivision types. You can modify the descriptions, and even add your own. This would be the first thing that I would evaluate before changing the layers in the map. Just keep in mind, if you remove required values (Tax, Lots, Subdivision) you will disturb the automated workflows. Let me know if this is enough information to get you started. Chris
... View more
01-06-2014
06:41 AM
|
0
|
0
|
3943
|
|
POST
|
Thanks for pointing me in the right direction Chris. You suggested earlier in the thread that the alias names of some of the layers could be altered to suit local business practices. Given that there are significant differences in cadastral terminology and nomenclature between my jurisdication and the US, what additional opportunities if any exist to customize/localize the LGIM to better suit my needs and still retain the OOB workflows and functionality? If you were to drag-and-drop the Parcel Fabric from ArcCatalog into ArcMap (included in the download, or simply create an empty Local Gov't Info Model Fabric), you'll see that there is a default "theme" applied to the Fabric. You can expose items that are included in the information model already (like ownership) and modify symbols and alias if needed. [ATTACH=CONFIG]30222[/ATTACH] I would also take a deep dive (if you haven't already) to see what commercial-off-the-shelf workflows are supported and which of those make sense to your particular business. http://resources.arcgis.com/en/help/main/10.2/index.html#/Parcel_editing_workflows/00wp00000063000000/ We also understand that these workflows have been designed and configured to streamline the editing process and may require subtle modifications to existing workflows, but also understand that they fit the majority of maintenance workflows (even internationally). Moreover, if you feel that a workflow simply isn't supported, there are manual workflows with the parcel maintenance tools to get you through the work. This is a good forum to bring those to the table so that we can take a look and make recommendations. If you have any concerns, please send them our way and we can direct you to the right help and resource. If you have feedback and need something that you're not seeing, please feel free to let us know. Please sign up for the Land Records Meetup, this is a great resource as well! http://www.meetup.com/Esri-Land-Records-Meet-Up/ Chris
... View more
01-03-2014
07:48 AM
|
1
|
0
|
3943
|
|
POST
|
Yes, I'm located in Canada and in the Province of British Columbia more specifically. We have one land title registry that is managed by the Province and we have one taxation assessment authority which is also managed by the Province. Among many other things including absolute certainty of title for prospective purchasors and lenders, this ensures that every titled parcel receives a unique ID (the PID) and that the taxation Folio ID's are also unique as well. The original geometry of surveyed (platted?) lots is always maintained until such time that they become the subject of an additional subdivision or consolidation with a neighbouring parcel. In most cases the geometry of a single PID and accompanying Folio ID is coincident. However, there are some cases where a single Folio ID is made up from the original geometry of multiple PIDs which are usually spatially adjacent. What steps do I need to take to migrate tax parcels that are made up from multiple owner parcels and at the same time, preserve the geometry of the original owner parcels? Every type of parcel is a individual load into the Parcel Fabric. If you take a look at the staging GeoDatabase as part of the Tax Parcel Editing template (http://www.arcgis.com/home/item.html?id=666f22f143e6454c8ecb6334dc8b5b43) you'll see that each parcel type is broken into explicit loading sources. [ATTACH=CONFIG]30220[/ATTACH] In the previous post I was attempting to draw a parallel between the Lot and Tax Parcel, the same pattern would be used for Ownership and Tax... Hopefully this clears things up, let me know. Chris
... View more
01-03-2014
06:51 AM
|
0
|
0
|
3943
|
|
POST
|
Sounds like you may be in Canada, I think that your assumptions would be correct. If you were to look at the Parcel Feature class as part of the Parcel Fabric, you'll notice that the 'Name' field is used for multiple identifiers. For example, the 'Name' Field is aliased to "Lot or Unit Number" for platted lots, "Parcel Identification Number" for Tax Assessment numbers, "Encumbrance Name" for easements and encumbrances, etc. We also recommend that you alias the parcel layer names for your particular business rules/needs. Just keep in mind that the parcel types "mean" something if you are going to take advantage for the automated parcel workflows. For example, with the automated workflows, "Tax Parcels" cut into "Tax Parcels"for new metes and bounds descriptions. In addition to the PID, does your jurisdiction also maintain lots as part of platted subdivisions? You can think of lots as the legal framework for tax parcels, meaning you can have multiple lots making up one tax parcel. If two lots are merged for tax purposes, there will be a single new tax parcel overlaying the original lots (not disturbing the original geometries and related records). You will also want to take a look at the 'Plans' table in the Parcel Fabric, this is used to store the original recorded information. In your case, you'll want to take advantage of this table for storing the registry information about the transaction. Chris
... View more
01-02-2014
12:00 PM
|
0
|
0
|
3943
|
|
POST
|
Hello Katy, I'll try to respond the best I can. 1. Tax Parcels are parcels that have been identified for the purpose of sending a Tax bill for a specific unit of land. In your example, it sounds like the assessment information (situs address, owner name) has been tethered to the unit of land, but these could still be considered tax parcels. The major difference that you should be concerned about is legal-lot parcel vs. tax parcel, many times 2 or more lots (or portion of the original lots) are reconfigured to create tax parcels. Imagine a legal description of "A portion of land being described as Lot 1 and 2 of Green Acres Subdivision", or the "East 15 ft. of Lot 1 combined with Lot 2 of Green Acres Subdivision". The screenshot below is a good example. The dashed-lines represent the originally conveyed lots vs. the solid lines representing the taxable unit of land. [ATTACH=CONFIG]30121[/ATTACH] 2. Condos can be modeled and edited in such a way that you enter each Unit (Lot), Tax Parcel, Limited and General Common Element, etc. as individual geometries. To accomplish this, use the Lots and Units Parcel types as part of the Local Government Information Model. [ATTACH=CONFIG]30122[/ATTACH] 3. Managing the PLSS as part of your parcel maintenance workflow can be an important decision. Before doing this, we recommend that you "vertically" align parcel types that should share a common boundary before loading them to your parcel fabric (this goes for any parcel type and not limited to PLSS) If you don't choose to include the PLSS into your Parcel Fabric, you will most likely still need it to create new parcels as they are recorded. As an example, if new description references a section corner, 1/4 corner, etc. you'll need to "snap" the origin connection lines to this point in order to find the POB (point of beginning). In this example, if the section corner is not aligned, or non-existent, it will make your job difficult. For this reason, many local jurisdictions maintain their own version of the PLSS that align with their Parcel Fabric (that may or not be more spatially accurate).
... View more
12-26-2013
11:24 AM
|
0
|
3
|
1993
|
|
POST
|
Fabric Rookie here. When I ran my topology it forced me to split up all of the lines along the back of lots. Now as expected I have lots of little short lines along the backs of lots . [ATTACH=CONFIG]19150[/ATTACH] How do I resolve this issue so I maintain the lot dimensions for both parcels as single lines? Hello Jeff, To resolve this, please use the "merge courses" tool added with the ArcGIS 10.1 release. http://resources.arcgis.com/en/help/main/10.1/index.html#//00wp00000051000000 This tool will use the recorded measurements (COGO values) if you have them. Chris
... View more
11-21-2012
07:09 AM
|
0
|
0
|
786
|
|
POST
|
I need to find a way to copy/paste joined parcels from one Parcel Fabric to another. When I right-click on a selected parcel, there is a Copy and Paste option, but they don't seem to do anything. Does anyone know what they are intended to do? Does anyone have a workflow that can do this? Thanks. Hello John, the 'Copy Parcels' tool is what you need. This tool will work on an entire Parcel Fabric, or only a selected set of parcels. [ATTACH=CONFIG]19244[/ATTACH] You can also simply select the parcels that you need to copy, and choose to 'Save as XML' from the Parcel Editor dropdown on the toolbar. You can then append this file to another Parcel Fabric. [ATTACH=CONFIG]19245[/ATTACH] Chris
... View more
11-12-2012
12:51 PM
|
0
|
0
|
845
|
|
POST
|
Here is a link to more detailed information about connection lines. http://resources.arcgis.com/en/help/main/10.1/index.html#/Adding_connection_lines_to_improve_connectivity_in_the_parcel_fabric/00wp00000008000000/ http://resources.arcgis.com/en/help/main/10.1/index.html#//00wp00000043000000 The documentation talks about connectivity and adjustments but there are other reasons to maintain connection lines. Origin Connection (Line category 6) Used for lines that connect a point of beginning to the starting point of a parcel. When creating a new parcel, an origin connection line is always entered first, then the remaining traverse lines of the parcel are entered. For example, origin connection lines (or tie-lines) are designed to traverse the bearings and distances needed to get from the origin (commencement) point to the point of beginning of the description. This is important metadata and map display information to trace your path back to the original tie position. Hope this helps Chris
... View more
11-06-2012
11:18 AM
|
0
|
0
|
1072
|
|
POST
|
Hello Betty, To delete connection lines, you can simply open the parcel and delete them but they are an important part of the Parcel Fabric. At 10.1 using the Tax Parcel editing map included on the resource center, lines are turned off by default. Anytime you open a parcel, create a new parcel or parcel(s) lines are automatically toggled on temporarily during those edits. You could also just simply remove the symbology class all together from the layer, but then you would lose the ability to create them via feature templates.
... View more
11-05-2012
08:27 AM
|
0
|
1
|
1072
|
|
POST
|
I am having the exact same problem. I am trying to edit a parcel in parcel fabric. The plan I am working off of gives the following values: Delta: 70°39'45" Radius: -45 Tangent Length: 31.90 Arc Length: 55.50 Using the "Curve Calculator", I also have calculated the Chord Distance (52.049') and the Chord Height (8.289'). All of this information is great, but I do not have values for either the Chord, Radial, or Tangent Bearing. Is it possible to calculate a bearing from the given values? I realize I could find the end points by saving the curve as the final piece of the parcel, but some parcels have two or three curves in them, making that a flawed approach. I have attached a copy of the plan I am working with for reference. Danny - Have you figured out a way to deal with the issue? Tim - Any advice given the values presented? I do not mean to hijack this post, and if this would be better off as it's own post, let me know and I will create one. Thanks, Jay Jay, from that plat it looks like all the curves are assumed tangent. You can either set the plan properties to reflect this or use the * symbol in the bearing field to set it to tangent (type the radius and arclength). Maybe I'm missing something, please let me know if I'm not understanding.
... View more
10-10-2012
11:37 AM
|
0
|
0
|
4341
|
|
POST
|
Hello Laura, there is a workflow for that. http://resources.arcgis.com/en/help/main/10.1/index.html#/Parcel_merge/00wp0000005p000000/ Hope this helps Chris
... View more
10-09-2012
10:40 AM
|
0
|
0
|
5744
|
|
POST
|
We're currently working on building a parcel fabric layer from high quality CAD data. Our workflow seems to be as automated as possible (i.e. everything but topology and COGO attribution) but we're running into a sneaky problem. If we calculate topology before calculating COGO, some of the distance and bearing values are altered, even if a vertex is only moved a few thousanths of an inch in some cases. Before the cracking and clustering, the COGO values are in almost every case identical to the surveyed values so we're trying to preserve them through to the fabric. My current idea is to calculate COGO values first, create a unique ID and placeholder fields to store the initial values, then validate the topology, split lines at intersections, and finally using some simple logic, backwards calculate the COGO for the lines that have been altered by the topology back to their original values, while leaving other changed values as they are once recalculated. Since we're already going through the process of rebuilding the parcel layer we figure we might as well try to have accurate COGO values while we're at it. Does anyone have any ideas, experience, or comments? Has anyone else done this or something similar? Hello Aaron, I have experience with CAD data. You are defininietly on the right path with calculating the COGO before you run it through the topology, but there are some things that you need to take into account. Is the CAD data projected, scaled, rotated or rubbersheeted? If so, the COGO value inversed will most likely NOT match the original recorded measurement. If this is the case, you'll have to reverse any scale/rotation/rubbersheeting before you inverse the data, this is not an easy task. You're better off focusing on loading the annotation from the CAD and then taking the day-forward approach of maintaining feature-linked annotation for all new parcels added to the parcel fabric. The feature-linked annotation class included with the Local Governement Information model is a great start. There is even a way to load your CAD annotation and then make it feature-linked by adding a relationship class (retroactively). Let me know if you need help setting this up. If the data is not projected, scaled, rotated or rubbersheeted, then inversing before running topology is the way to go. One thing that you mention is interesting though, why would you have to split lines at intersections if the CAD data is high-quality? That would introduce additional lines that may or may not exist on the original records, this may be difficult and time-consuming to figure out. Let me know if this is helpful and we can keep the conversation going. Chris
... View more
10-09-2012
09:06 AM
|
0
|
0
|
798
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 02-11-2026 02:06 PM | |
| 2 | 08-27-2025 09:57 AM | |
| 3 | 08-27-2025 09:55 AM | |
| 1 | 03-11-2025 07:06 AM | |
| 4 | 02-06-2025 07:56 AM |
| Online Status |
Offline
|
| Date Last Visited |
04-01-2026
01:38 PM
|