Latest Contributions by AmirBar-Maor

@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

@Kathleen_Crombez  Thanks for your correction: subtypes can be used to optimize performance and apply different topology rules within a table. But subtypes require a field (type: long interger ) - which field would you use to differentiate between historic and current parcels? Early on, before releasing the software in 2019, we were on the same path. We thought to create an attribute rule to set a long integer field (e.g. IsHistoric). However, attribute rules cannot be used to calculate field values that control a subtype. So that didn't work. Do you currently use subtypes for current and historic parcels? If yes - do you set historic fields manually? ... View more

@JayHanson  This is the correct place for your question! @anna_garrett  is correct - such capability does not currently exist. Can you elaborate: Where/how the table is generated? What format (CSV, Excel...)? Could you attach an example?  Does it also specify the POB or commencement point? You are also welcome to submit an idea on the parcel fabric ideas board. @TimHodson - FYI   ... View more

@RobertChaney  Why don't you use the StatedArea field ( type: Double) and the 'Stated Area Unit' field? ... View more