Latest Contributions by SamMontoia1

Greetings, The reader seems to miss common arc description patterns: This is the way it kind of read it down, (I made some text corrections to help it read better): This is what I corrected it to: and it closes within 0.01 feet.    ... View more

I have found that adding "from the point of beginning" and reversing the bearing direction N W becomes S E in this case, helps the Cogoreader identify the Connection Line information.  In this one for me, the last Curved segment Delta Angle of 02°54'42" and radius of 1329.76 to the left; it calculates it having a distance about 4' longer than what is stated in the text which is 67.57'.  The measurement it came up with was 71.41 or something.  ... View more

That worked for me too.  Removing the Word "Bears" empowered the CogoReader to pick up the bearing and dimension and put it into the Connection Line.  In this instance, the keyword "whence" usually gives me the clue that the Bearing in the description is a 'Backwards' looking direction, Thus SouthEast becomes NorthWest; and I always imagine it as if I were standing at the starting point and looking back at the PLSS Section Corner; and that's how it is written; but the traverse tool needs to have the forward direction from the starting point of the section corner; and then moving around the traverse.  This inverted pattern of getting from the section corner to the point of beginning is very common.   Ideas of how to add to the training/testing data to the CogoReader's understanding may belong in a different place on this community.  I guess I wish I knew how I could contribute; or if and how the system is building its understanding. Noting that discussion of incorporating the PLSS may belong in a different or separate idea or spot on this community; Our area of Colorado references the New Mexico Principal Meridian;  Other areas of Colorado, seemingly reference the 6th Prinicipal Meridian. ... View more

@AmirBar-Maor Fundamentally yes, my idea is about pointing out when the cogoreader misses a bearing and or distance.  So in this case it was unclear to me how I might get the reader to detect that the bearing from the section corner is apart of the connection line. My experience was that the reader did not detect this bearing and distance.  And yes I added s90°e for the bearings that were south. And for North I did the similar thing.  After adding this to the text, the reader used these bearings to get the rectangular polygon.   Including the document is definitely an aspect that I initially failed to do.  So for others reading this and posting here: adding the document is a good practice. It definitely helps that you seemingly had a similar experience as I did with this legal description with the Cogoreader It is really exciting that it worked so well.  And interesting that the PLSS reference is well a tough problem.  I am in Colorado and so the most common legal description pattern is just like this one.  The bearing from the section corner is inverted in the traverse tool to get to the starting point.  ... View more

@AmirBar-Maor  Question or Idea; this post seems like it has elements of both. And I would be happy to move it to questions; though I might also ask if I should just start a new post over there at questions or transfer this thread somehow?  I added the previously described parcel type to our parcel fabric ecosystem.  But a reconfigure could be in order.    A field or attribute tracking validity or acceptance or something along this line is perhaps a better idea than a separate parcel type.  Would you recommend a definition query filter for parcels and parcel lines like the method used for historic parcels?  Or maybe a definition query and a symbology distinction in the Historic Parcels feature could be an efficient methodology.  I was presented with a legal description recorded 20ish years ago, and until I COGO-ed it in: I didn't know why it wasn't a part of our parcel dataset.  Then I found that it did not close; seemingly intersected some buildings on the property; its starting point did not match previous boundaries; and overall it did not match up with the road that was referenced in the description very well.  I thought that a future person or myself might be aided if they could see the way I mapped this document; and reasons why it was excluded.  Thus I had the idea of a new parcel type that I could dump all of this work in and save it for the future.  I also have a more current legal description that has errors; that I am also likely to exclude and I am in the process of asking the record-instrument filers (aka Grantors/Grantees) to re-do the lengthy legal description.  The records-driven workflow, along with the principle of "fix it later" for the ArcGIS Pro parcel fabric when it comes to the over all quality of the entirety of our parcel dataset has really helped us move forward with parcel management.  Though, if you told me that my mindset had a type of "Records-Driven hammer-like quality" and it locked me into thinking of documents as narrow "nails"...  I think the bottom line here is that this invalid parcels layer is a type of purgatory for documents that are excluded from our Parcel Fabric; These certainly don't belong in our Current Parcels, but also lack a document that retires them.  Invalid Parcels are shown in Pink; Lighter Pink are Invalid Parcel Lines.   ... View more

I often find Delta Angles, and Central Angles to be a more precise way of entering in these measurements; with a type of double check built in because the subsequent label shows the Arc Length.  ... View more

It would be really helpful to return to a ground to grid correction value from a feature or set of features.  Maybe also having a ground to grid correction value for a 'record' feature would be awesome.  Maybe when you switch to the active record this ground to grid value could also be applied.  ... View more

  var records_features = FeatureSetByName($datastore, "<insert records feature class here>", ["Name", "GlobalID"], false); var ret_guid = $feature.RetiredByRecord var match = Filter(records_features, "GlobalID = @ret_guid"); var matchfeature = first(match); if (matchfeature != null){ return matchfeature.Name } return null   Here is an attempt at making an Arcade Expression for the looking up the  Retired By GUID and pushing the Retired By name into an additional field. It might be a little more generic and more easily adapted to other ParcelTypes.  ... View more

@AmirBar-Maorthanks for the idea "GUID a very unique FeatureID."  That's helpful in understanding their use.  And I also understand why the model uses them and their favored status.  I reckon the trade-off is that as they are designed as much for computers and the software to understand, and their autogeneration is both a blessing and a curse.  My argument/point is that the GUID for a record does not appear in the Active Record box; instead it's the Name field value for the active record; and that's likely because it's more understandable to the human users. Also the Record information is what is being displayed there; vs. Parcel Table that is the subject of this thread;  It seems like I am not the only one, but most often I am looking at the Table of selected parcel features.  And it would be more meaningful to have a list of names/document numbers than Record GUIDs in the each parcel's retired by and created by fields in the table.  It's a combination of it matching the documents I am working from and that the number is simpler than a GUID.  Your answers certainly help me understand the structure of the parcel fabric and GUIDs, so again thank you.  @jcarlsonI would be interested in some sample code/attribute rules depicting how you accomplish Amir's suggestion.  Thank you.      ... View more

Maybe a more appropriate title/caption for the check box-switch would be "use selectable layers only", and it should be above Target and Source drop downs or even below all of this would be ok to me, but it is just a check box and its only function would be to reduce the above Target and Source Drop downs in this menu to match the selectable layers when it is checked.  And in my mind it would be so transient as to really only affect those two drop downs.  As it stands I have 20+ layers that are reference layers in this particular project and I don't transfer attributes from them.  But I find myself constantly having to ensure that the layers I do want to transfer attributes between, I just have to re-map them early and often because I am never quite sure that the transferring is happening as I am expecting/wanting.  Plus the names of my fields are different between the target and the source layers. I find that controlling the selectable layers in a Pro Project is a nice way of mapping my reference layers without having them clutter auxiliary menus.    ... View more

@RichardFairhurstIt isn't a huge help; and I guess I was thinking of ways of limiting a very long list of layers in the Source/Target drop downs.  And this toggle switch would just limited the drop downs to Selectable layers.  Something like this:  ... View more

Thanks for the suggestions @AmirBar-Maor .  And yes, I could hide the Created by Record; and Retired by Record GUIDs on my Parcels attribute table.  Though, I do hope it's clear that I am suggesting to have Created by and Retired by Name/Number instead of the Record GUID appear in the Parcels Table. Just like the Name/Number appears in the Active record Box (not the GUID).  Sorry I can't think of the term used to describe this Active Record Box:     Regarding your suggestions 2. and 3. and in context to the Record GUID as it appears in the Attribute Table;  Is this understanding correct:  ArcGIS Pro is assigning the Record GUID to the parcel and parcel lines features as they are created and updated.  Based on the Active Record and the actions taken.  Retiring a parcel assigns the Active Record's GUID to the Retired by field in the Parcel layer, and of course creating features pushes the active record's GUID to the Created_by field in the parcels layer.  And the phrase "among other things" seems apt for both retiring and creating features.  What about making a pair of joins to the record table based on Created by and Retired by and Record GUIDs?  At the very least one join to the Records Table based on the Parcels Created by: to the Record GUID seems to work.  (and then I have hidden all the other fields except Record Name).  Multiple joins probably isn't a great approach, and also multiple joins to the same table doesn't seem to be allowed.  Seems to cause a 'glitch in the matrix'.  But one join is allowed. I do like the idea of "on the fly" displays, and creating attribute fields and rules <- I will try that too.     ... View more

Yes, Exactly.  My idea is to limit the drop-down lists of layers for Target and Source within the field mapping dialog with a check box that would confine these lists to either the selectable layers or the editable layers. Toggled on the Target/Source layer lists would only show editable or selectable layers, toggled off it would show all layers.  Also I didn't know that the copy/paste is controlled by the field mapping.  So thanks for that bit.  I also noticed that selectable layers are the only ones that allow attribute transfers too, which is fine behavior; but all the more reason to limit the layers in the drop-down when doing the field-mapping dialogue.  Or at least have an option to limit the list.      ... View more