Latest Contributions by DavidSolari

Haven't tried something like this myself, but combining the Extent, Polyline and NearestCoordinate functions might work. ... View more

There's a lot of "it depends" here but the RMS fields are the must have fields, there's virtually no reason to bother with GNSS metadata without them. ESRIGNSS_POSITIONSOURCETYPE is also a big one, this is what confirms that your users are using the equipment. The DOP data is less useful in my experience, but I'm sure someone who's spent more time with GNSS workflows can correct me here. ... View more

At first thought, the easiest solution is to pin the required Python versions to the supported versions of Pro when the Conda package for the esri channel is built. The Pypi and non-esri channel Conda packages can continue to list a wider range of Python versions as that's not what Pro's package manager will look for. ... View more

CSV files have an effectively unbound length per field which is why dumping them straight to your EGDB picks that data type. You'd be better off extracting the data to an intermediate table in a File or Mobile Geodatabase where you can clean up the data and schema before loading it into your EGDB. If you're genuinely concerned about database performance you'll want to prep your schemas by hand, then use Append to transform the CSVs into the new format. ... View more

Try flipping back to DEFAULT and changing the entry_note to a brand new value, does that prompt a conflict? ... View more

This should be possible with a bit of arcpy, look into Cursors and the Geometry objects. ... View more

Excellent, that's progress! If your relationship is working, it's possible you don't have any features. You should add a guard by checking if the Count of the relatedRecords is zero and returning early, but if your test data should return a related record then sort out your relationship query before you do that, otherwise you'll bury the true issue. Good luck! ... View more

Sadly no, and there's no news of a multi-choice domain type on the horizon. In this case you'd need a many-to-many relationship class between the easements and each of the choice tables, then do some stuff with calculating data or attribute rules into a redundant field to get the final table. ... View more

One-to-many relationship classes should work here, but something that works in ArcGIS Pro might fall apart once it gets into a server based workflow due to edit tool limitations. It looks like you just want to tag every easement polygon with an Owner and Type, with a set list of options for both. In that case you might want to use Coded Value Domains to lock those options in, then you can filter on those two fields instead of trying to do relationship-based selections. ... View more

From my testing, replica synchronization (i.e. what offline areas use to update the feature service) appears to attribute rules as series of individual features to C/U/D. If FeatureSetByName is reading the data outside of the current transaction, it'll just see the pre-sync snapshot which will not include new features or changes to those features. If it's reading data from within the current transaction, it might see the other operations but it might not, depending on the execution order, so you should always assume it can't. The safest option is to assume that this type of query could or could not contain the current feature; therefore, always read/modify the input feature in addition to what you get from the query, but also assume this could result in a duplicate action and guard accordingly. This will cover both standard and sync updates. If this'll bloat your scripts too much, test how the rules behave in your environment from a variety of clients, offline and online. ... View more