|
POST
|
Thanks for the explanation @SamMontoia1 I think everybody in the community encounters problematic legal descriptions from time to time. 'Quality' is not 'black and white' and users apply their experience and judgement to decide what to do. In some cases, like the one you show, things don't fit and require additional research. A metes and bounds description that doesn't close might contain an error, but those that close and appear to be wrong have a different intention. @FrankConkling presented on reading legal descriptions and their intent. My recommendations: Use a field in the records table and/or the parcels to denote there is an issue with the feature Use 'Symbolize by Unique Values' to symbolize those parcels/records differently. This will perform better than creating a separate layer using a definition query. ArcGIS Pro 3.4 will have a new option to turn on/off the visibility of categories in the layer. It is beneficial to see the problematic parcels when you edit the data. There are other quality indicators on parcels, like the misclose ratio. One could also get creative and use a custom symbology 'by unique values' that relies on a custom Arcade expression that takes into account multiple fields. I hope this makes sense and hope other community members can contribute to this discussion from their experience.
... View more
08-21-2024
02:11 AM
|
1
|
0
|
1455
|
|
POST
|
@SamMontoia1 This seems more like a question than an idea. Is it possible to move this to the Question board? Your idea to track suspicious parcels and associate them with their invalid record is great. Instead of adding a parcel type, wouldn't it be easier and more performant, to add a 'status' field on the parcels and records? You could easily symbolize them differently and even create a separate layer for these parcels and records.
... View more
08-19-2024
01:32 AM
|
2
|
0
|
1509
|
|
IDEA
|
@ChristalHigdon_USFS Thanks for your input. That makes sense. If we implement this, we are likely to expose all of the parcel fabric properties, not only the parcel names.
... View more
07-19-2024
10:11 AM
|
0
|
0
|
2396
|
|
IDEA
|
@ChristalHigdon_USFS By design we allow these properties to be independent of each other: Feature class name Feature class alias Feature layer name Parcel type name This means that you can modify each one independently of each other. Why? here are common reasons: The feature class name is a table name and must abide by DBMS standards (e.g. no spaces). We also append an underscore and a number to guarantee that it has a unique name within a workspace. That table name might also be used in database views and SQL queries, so some organizations keep it short. Feature class alias name can contain spaces and be long as needed. It is used as the default feature layer name when added to a map. You can have multiple feature layers point to the same table, so each can have a meaningful name. For example: current parcels versus historic parcels. The parcel type name is the logical name for a parcel. Some countries only have one. We use that as the default name for the feature classes when you create a parcel type. The geoprocessing tool mentioned above, Append Parcels, is smart enough to ignore any changes that have been made to the table name and rely on the parcel type name. So you can ignore any underscores in the table name if you have multiple tables in the same workspace. If they were coupled, we would have to add an underscore and a number to the parcel type name if there was a collision in the table name. I hope this makes sense Amir
... View more
07-12-2024
04:00 PM
|
0
|
0
|
2486
|
|
IDEA
|
If I understand correctly (please confirm) you have: A base geodatabase that you use as a template You use Python to copy it to the different areas in Alaska You would like then to stitch those pieces together Questions: Is the description above correct? Did you try to use the XML workspace schema to create an empty geodatabase for each region? Did you consider using the geoprocessing tool Append Parcels to stitch the regions back together? In that case, you want the parcel type names to be identical.
... View more
07-12-2024
01:44 PM
|
0
|
0
|
2496
|
|
POST
|
Aloha @ElisseDeleissegues1 I understand that you will be attending the UC this year. Please bring your data to the parcel fabric island (next to entrance B) so the team can review the process and the data. Thanks, Amir
... View more
07-11-2024
01:55 AM
|
0
|
0
|
941
|
|
POST
|
Here are links to a few resources related to parcel lineage: https://pro.arcgis.com/en/pro-app/latest/help/data/parcel-editing/whatisaparcel.htm https://pro.arcgis.com/en/pro-app/latest/help/data/parcel-editing/viewparcellineage.htm https://cloudpointgeo.com/blog/2024/1/16/two-ways-to-display-parcel-lineage-with-your-parcel-fabric-data I hope this helps
... View more
07-03-2024
12:22 AM
|
0
|
0
|
1829
|
|
POST
|
Legal directions and distances (AKA COGO) are based on survey observations. Every survey observation contains an error. The size of the error is related to many factors, including the type of survey instrument that was used. When creating a closed traverse, we can calculate the misclose that is caused by those errors and distribute it using a variety of methods. I would make sure that you are using the correct 'Ground to grid' correction (aka 'combined scale factor') if it is mentioned on your legal document. If you create a geometry that is slightly short (aka 'undershoot') or slightly too long (aka 'overshoot') , you should keep the legal measurement as it and adjust the geometry. You can use the 'Extend/Trim' tool, or the Edit vertices tool. That way you captured the legal dimensions as well as the correct geometry. I hope this makes sense
... View more
07-03-2024
12:19 AM
|
1
|
0
|
1750
|
|
POST
|
It looks like the parcel you are trying to align is: The parcel polygon does not coincide with the parcel lines and points The parcel is placed very far from where it should be It is not clear what kind of transaction/workflow is behind it If you think you've found a bug, please contact technical support. I would try to: Use the move tool to move and rotate the parcel to where it should be. You can also try to use 'Shring to seed' and then ' Reconstruct from Seed' to fix it. Make sure the parcel is correct = The polygon has lines and points defining it
... View more
07-03-2024
12:09 AM
|
1
|
0
|
1593
|
|
POST
|
@DevakalaiselvanS Did you mean to write 'Parcel Lineage' instead of 'Package Lineage'? Are you asking a question or making a statement? Currently, parcel lineage is used for analysis but we have heard interesting ideas from customers on using the chart to fix and establish relationships, about integrating relationships from other systems to depict the full 'chain of title', and more.
... View more
07-03-2024
12:03 AM
|
0
|
0
|
1833
|
|
POST
|
@MarkByers As always, we recommend submitting a technical support case so we can look at your specific data. You can also try the following steps: Delete the seeds Save edits Recalculate the spatial index on your Condominiums_Common_Elements table Create Seeds Save Edits Build Please let us know if this works
... View more
06-07-2024
12:05 AM
|
0
|
0
|
1703
|
|
IDEA
|
@AlanStearns1 I've switched this idea to 'Under Consideration' and we can explore it again.
... View more
06-06-2024
05:50 AM
|
0
|
0
|
2375
|
|
IDEA
|
06-06-2024
05:47 AM
|
0
|
0
|
2378
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | Friday | |
| 1 | a week ago | |
| 3 | a week ago | |
| 2 | a week ago | |
| 1 | 06-12-2023 01:26 AM |
| Online Status |
Offline
|
| Date Last Visited |
Monday
|