Latest Contributions by AmirBar-Maor

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

@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

Scheduled for the ArcGIS Pro 3.4 release ... View more

@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

@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

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

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

@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

@AlanStearns1  I've switched this idea to 'Under Consideration' and we can explore it again.    ... View more