Latest Contributions by AmirBar-Maor

@MARIUSGLOVACI  We have improved the performance of the merge points tool. Hopefully, it is no longer annoying. Because the tool has a near preview, we could not suspend the operation of reading the point. Instead we cache them once when the tool loads a selection. ... View more

@BinhLe  The record geometry is the 'footprint' of the transaction. We don't update the record geometry as a result of any update that occurs to the parcel because of a potential performance hit. If you want the footprint to match the parcels exactly you can run Build (either Active record or extent).   ... View more

@anna_garrett  When you use the standard Append tool you have the option to map any fields that do not match, but if you have fields in the source data that are not present on the target - the feature will be appended but their attributes will be lost: When you use the Append Parcels Tool we assume the source and the target schemas match. This is documented in the help documentation for the tool - https://pro.arcgis.com/en/pro-app/latest/tool-reference/parcel/append-parcels.htm   We do not recommend using multiple parcel fabrics for the same location as you run into the issue of misalignment between them. If you must edit the school districts in another geodatabase (for example - you give it to a contractor that edits it offsite), make sure the schemas match. If you feel you have encountered a bug, or you suspect you have encountered a bug, please contact technical support.    ... View more

@SamMontoia1  Please think of GlobalID as 'very unique' objectIDs. We are transitioning to using them because they are unique across databases, which means data can be more easily disconnected, updated and synced back to the production system. The relationship classes between the parcel feature class and line features class use a relationship class to the records table. A relationship class cannot rely on a string field that is entered by a human being. It is not reliable to be unique. ObjectIDs, GlobalIDs and GUIDs are meaningless and not fun to look at - the best thing is to hide them in the layer. Joins can be used by they also have an overhead (performance hit). Another reason for using relationship classes over joins is that relationships are exposed in the Attribute Pane and popups and let you navigate the relationship. If it is very important for you to see the record name all the time you can also consider adding it to the parcel label expression. Of course - at any time you can turn on the records layer to see their footprints. We will have more cool and useful depictions of parcel lineage in future releases.   ... View more

To see the record name in the attribute table instead if the GlobalID you will need to: 1. In the fields design view hide any field you don't want to see like ObjectID, GlobalID and any GUID field. 2. Add a field CreatedByRecordName (string) and RetiredByRecordName (string). The string size should be the same size as the name field on the records table. 3. Add an attribute Rule that gets triggered on Create and Update of the feature to calculate those fields using the same Arcade expression you use in the Popups. The advantage of using a popup or a display expression is that it displays the value 'on the fly' without performing any edit operation and taking more space. If you like to see it in the attribute table you will have to populate it using attribute rules.   ... View more

Thanks @Anonymous User  for the information. Are you aware that attempting to load a traverse from a polygon will: 1. Use the Grid (projection) dimensions and not the original ground dimensions? 2. Any misclose that was adjusted between all the traverse courses will be reflected in the inverse dimensions? 3. Any densified curves you might have in your data will appear as many small courses?   About the parcel fabric. If yo are the only one editing it you can also use a file Geodatbase (single user deployment) and not have to wait for other departments to upgrade the enterprise environment. Some additional benefits for you to consider: 1. If you enter a lot of old deeds you will be able to associate each parcel you enter and each boundary to the deeds it came from (regardless if it is now historic or current). 2. You will be able to isolate and see only the features that pertain to that deed/plat (using the Show Only Active Record) 3. Better quality control: easily find topological issues, lines with wrong COGO values, parcels with wrong area etc. 4. All the reasons above to use 'COGO enabled lines' + we also track if the COGO dimension was 'entered', inversed 'from geometry' or 'computed'. 5. Efficiency  6. ...         ... View more

@SamMontoia1  I assume you already know you can navigate the relationship in the attribute pane to see the records name for parcels: And for lines:   Question 1: Where would you like to see the record name? In the display expression for the parcel? in the Popup? both? There is a post that shows how you can add the record name to the parcel popup here using an Arcade expression: https://community.esri.com/t5/arcgis-parcel-fabric-blog/how-to-show-the-record-name-in-the-parcels-popup/ba-p/884977 Since lines don't have a relationship class with the records table, another approach, that would work for both parcel and lines is to use the records's GlobalID in a SQL expression with the 'Filter' arcade method. Question 2: Should we ship the parcel fabric with those popup expressions? Question3: Should we also show the name of the retired record for historic parcels?     ... View more

Hello @Anonymous User , The traverse tool is part of the editing Modify tools and it allows you to traverse both polygons and lines. The reason you are pointed in the documentation to enable the COGO on your lines feature class is that a COGO enabled feature class has the ability to capture the measurements as attributes as well as predefined symbology, labeling and display expression that works well for metes and bounds legal descriptions. What are the advantages of entering features over a sketch? Every line you enter is its own feature which means can save your edits halfway through entering a traverse. It also means you can pick it up from where you have left simply by tracing those lines. Having labels can help you identify any entry mistakes early on - another reason to not use a sketch. If you choose to not use the new parcel fabric, you can use those lines to create a polygon using the 'Construct Polygon' tool (also found in the editing modify tools). Another option if you want to preserve using polygons: select the polgyon, Copy and paste special into a COGO enabled line feature class, Use the traverse trace to modify it, then Construct from polygon, delete the lines (as you can see - this is not efficient). Any reason you are not using the new parcel fabric? How long have you been editing in ArcGIS Pro?     ... View more

@anna_garrett  COuld you please provide the case # so we can follow up with technical support? ... View more

@JonathanMcDowell1  Sometimes the error message is correct and sometimes it's wrong. Sometimes it's a software issue (bug) and sometimes a data issue. The only way we can determine it is if you submit a technical support case with the data and steps to reproduce it. Could you please submit it? ... View more

Hi Pascal, The main issue with the old  ArcMap methodology was that only features within the organization that are in the same workspace could be adjusted.  The new approach lets any consumer of the data adjust their data in their own extent and time window. Where would you write when each feature class was last adjusted? On the feature class or the feature level? (you could adjust a subset of features...) Either way, it shouldn't be too hard to implement as a geoprocessing Python script tool. it will be good to discuss your use cases to make sure and make sure they also align with other organizations before taking another step. Maybe a meeting is needed?   ... View more