Latest Contributions by AZendel

It looks like this has been implemented in Pro 3.x when using the cut tool. Thank you, ESRI. But it seems like this has NOT been implemented when using the reshape tool. Please add that, ESRI! ... View more

Yes please. Maybe allow the user to specify the transparency as well.  ... View more

Yes, please! It sounds like this hasn't been implemented yet? Somebody tell me that I'm wrong. Has anyone built a custom widget that they can share? ... View more

I'm seeing this on an Oracle EGDB as well. I'm still using Pro 3.0.3, but 3.1.0 is available. But based on the bug report, I don't think this this has been fixed. @Robert_LeClair, it may not hurt to let the staff that are addressing the bug know that I've run into the issue on an Oracle SDE instance as well. It's happening on the SHAPE.Area field and a separate double precision field that has nothing to do with the geometry.  I'm glad that the statistics that it was reporting were so out of the park that something was blatantly wrong. Otherwise, I could have reported some bad numbers and that should never be considered acceptable. I think this bug warrants faster action than it appears to have received so far.  ... View more

Thanks for the excellent explanation, Shannon. And for confirming that the SQL Server documentation that I quoted applies to Oracle and the other Enterprise GDBs (though I imagine each DBMS may have some of its own particular details/idiosyncrasies regarding area and length calculations). I can stop scratching my head now......  Thanks again.   While we're on the topic of SHAPE.AREA, it be really nice to be able to specify the units that are displayed in these fields. As you saw above, I almost exclusively use TN State Plan HARN NAD83. The X/Y units are in feet so the SHAPE.AREA fields display square feet. Square feet is a easy to digest when you're at the building or lot level, but once you get up into dozens of acres, it's almost meaningless, like 4,535,588.22548 sq ft. I'd much rather see acres in feature classes with larger polygons. You mentioned attribute rules, but it sounds like you'd need to create a new field to store the calculate area? That could get inefficient on larger datasets. I also realize that Query Layers allow you to specify SQL that can handle this conversion, but then you can't edit the FC. It'd also be nice to have dynamic field that makes calculations beyond geometry (summing several columns of different races reported in census data). QGIS has 'virtual fields' that do just that.  ... View more

After coming across this post, I think the discrepancy comes down to how Oracle and ArcGIS are handling curves when calculating area. That post is for SQL Server, but I imagine that something similar is happening with Oracle.  ... View more

Thanks for the quick response. I believe I ran across that page in the documentation, but it's hard to remember all that I read before I decided to post here. That page starts with "The Esri ST_Geometry spatial data type.....", which implies that ESRI created it. That makes me think that ST_Geometry is used in File GDB's, but I could not confirm that after extensive web searches . Good suggestion on looking for curves in the source geometry. There are some (below). But shouldn't those transfer from Oracle to FGDB the same?     ... View more

Yes, please! I would love to be able to specify 'overwrite outputs' at the individual model level. Can this be added to a model's 'environment' settings? I also execute a number of geoprocessing models via ArcPy stand alone scripts. So the setting in the Pro interface as shown here is not effective in these situations because the scripts are executed 100% outside of the Pro environment.  ... View more

If I'm interpreting these posts correctly, there is no way to specify that a particular/individual geoprocessing model should overwrite its outputs. The only option is to set this in the Pro options tab as shown in the first post. Is this still the case? I'm calling a lot of geoprocessing models from ArcPy and I want to allow some of the models to overwrite existing outputs. This setting in the Pro user interface is likely ignored when running a completely standalone ArcPy script.  Please confirm when you can. And ESRI, if you're reading this, please allow this option to be set within individual models.  ... View more

Is this still the case with ArcGIS Pro 3.0? I have a stand alone vb.net exe that executes geoprocessing models using libraries/assemblies from ArcMap 10.8.1. Windows Task Scheduler wakes it up every hour and it also performs a lot of SQL tasks via native SQL Server client libraries.  It also calls a geoprocessing model that geocode addresses and later calls another geoprocessing model that appends those features to a feature class. Since ArcMap will not exist in the future, I'm trying to migrate it to rely on libraries from Pro. Here's the VB.net / ArcObjects code: Dim parameters As ESRI.ArcGIS.esriSystem.IVariantArray = New ESRI.ArcGIS.esriSystem.VarArray Dim GP As esri.ArcGIS.Geoprocessing.IGeoProcessor2 = New esri.arcgis.Geoprocessing.Geoprocessor() 'Add the BestPath toolbox. GP.AddToolbox("C:\path\to\my\toolbox.tbx") parameters.Add(sGDBPath & "\databasename.DBO.myfeatureclass") 'Execute the model tool by name. GP.Execute("DeleteCountyStatusPermits", parameters, Nothing)   There's no way to do this on machines that have Pro and not ArcMap? It would be nice to not have to 'wrap' these models in python scripts - that adds too much complexity to maintaining my project.  Thanks for your time,   Alex ... View more

Thank you for the update, Jared. And thanks for listening, ESRI.  ... View more

It looks like the 64-bit compatible accdb MS Access format allows 'OLE Object' data types, which is the same field data type that the .mdb formatted Personal Geodatabases used to store the shape/geometry fields. So in theory, ESRI could have migrated the Personal Geodatabases to this new format. ESRI, if you're not keen on porting the PGDB to accdb, please start treating "Personal ArcSDE" geodatabases (based on SQL Express and one step down from the 'Workgroup Geodatabases') as first class citizens in Pro: 1) Allow the creation of these (and Workgroup GDBs) in Pro. We still have to do this in ArcMap or ArcCatalog 2) Make the user restrictions similar to the file geodatabase and personal geodatabase: a substantial number of read connections, only one editor. I myself hit the 5 read connection limit when I have a few geoprocessing models running while also reviewing the data in a maps. My coworker should also be able to read the data to help me QC output. You allow this in File Geodatabases and Personal Geodatabases, so why not in 'Personal ArcSDE' databases? This will still allow us to access our data via SQL tools: MS SQL Server Mgmt Studio, Azure Data Studio, ODBC links into numerous applications.  I was excited for the SQLite/Mobile geodatabases when they were announced, but as Steven noted above, they aren't very compatible with ODBC and third party tools: 1) you cannot do joins against text fields when connected via ODBC since the drivers consider all text fields to be 'memo' or long text fields. This is a problem in read-only (SELECT) queries and update queries.  2) you cannot update a non-spatial field in any type of feature class because the drivers don't have the libraries to maintain the spatial indexes. I believe that an update in SQLite is more akin to deleting the original record (feature) and then creating a new record (feature) -- this can't be done without the libraries needed to maintain the spatial index.  We need reliable SQL access to our data. If you won't give us ACCDB database, please loosen the reins the 'Personal ArcSDE' databases to allow more read connections. Please also allow the creation and management of these database types in Pro.  ... View more

Yes, please! This is so handy in other graphics programs. In addition to 0, 45, 90 degrees, it's be nice to have 30 and 60 degrees too.  ... View more