Latest Contributions by SamMontoia1

Here is the behavior that I would like to limit, I click and it zooms; and if the area of search is larger it zooms to that; but I would like to have no zoom on the click and just find the near  features.  ... View more

I have this same issue; the setting or behavior I would like to limit or eliminate is that the widget zooms to the location that you click or specify; with the size of the spatial query being a deterministic qualifier for the zoom. How can I just have the widget show the clicked or selected location; and not zoom?    ... View more

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