|
IDEA
|
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
09-18-2023
08:38 AM
|
0
|
0
|
549
|
|
IDEA
|
Yes please. Maybe allow the user to specify the transparency as well.
... View more
09-18-2023
08:35 AM
|
0
|
0
|
1312
|
|
IDEA
|
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
05-23-2023
05:35 PM
|
0
|
0
|
5104
|
|
POST
|
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
04-03-2023
10:39 AM
|
2
|
1
|
3572
|
|
POST
|
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
03-21-2023
05:38 AM
|
0
|
0
|
1939
|
|
POST
|
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
03-17-2023
08:28 AM
|
0
|
0
|
1988
|
|
POST
|
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
03-17-2023
07:55 AM
|
0
|
1
|
1993
|
|
POST
|
I exported some simple polygons stored in the ST_Geometry format from an Enterprise Oracle database to File GDB (FGDB) and the shape_area field for one polygon lost 76 sqft. That 'loss' is based on the Shape.Area field in Oracle and the SHAPE_Area field in the FGDB. This happens when I use the Copy Features tool in a geoprocessing model and using Data --> Export Features in Pro. I've looked at the feature class properties of both and they have the exact same: Coordinate system: SRID 2915 (TN State Plane NAD83 HARN). The "Geographic Coordinate System" that the layer properties dialog box that Pro displays lists the same WKID: 4152 Spatial resolution: 0.000328083333333333 US Survey Feet No Z value storage, no M Value storage Simple Feature type Vertical units (Foot_US) -- this is probably moot since neither store Z values No Errors or Warnings are shown in the geoprocessing history for the copy features More notes/questions Does the FGDB use also ST_Geometry? Or something slightly different? If the latter, I suppose this could account for the difference I ran the Check Geometry tool on the FGDB feature class and none were reported. It is not possible to run the tool on Oracle feature classes because, as the tool document states, the geometry is reportedly validate when inserted Does the shape_area or Shape.Area sometimes fail to update? This discrepancy was only detected in 2 of 190 exported polygons (one discrepancy was ~76 sqft, the other 18 sqft) This is fairly concerning because we often list polygon areas on documents that have legal ramifications The calculate geometry tool doesn't match the SHAPE_Area field of the output FGDB feature class, which is shown below (calculated area with us survey feet as the input). The Shape.Area field of the Oracle feature is 651063.678772 Thanks in advance for any insight you can provide.
... View more
03-17-2023
06:52 AM
|
0
|
6
|
2060
|
|
IDEA
|
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
03-02-2023
10:40 AM
|
0
|
0
|
1310
|
|
POST
|
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
03-02-2023
06:12 AM
|
1
|
3
|
5915
|
|
POST
|
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
01-05-2023
07:26 AM
|
0
|
0
|
3440
|
|
POST
|
Thank you for the update, Jared. And thanks for listening, ESRI.
... View more
12-13-2022
12:01 PM
|
0
|
0
|
8557
|
|
IDEA
|
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
11-18-2022
01:32 PM
|
0
|
0
|
2193
|
|
IDEA
|
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
08-31-2022
01:04 PM
|
0
|
0
|
2043
|
|
IDEA
|
@KoryKramer , thanks for the reminder on the kudos. Done. It'd be ideal to keep the PDF as a vector format (if the PDF contains vector layers). So ideally, it would be like a georeferenced PDF or a "GeoPDF" once you complete the georeferencing process.
... View more
08-25-2022
09:44 AM
|
0
|
0
|
4735
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-02-2023 06:12 AM | |
| 1 | 12-23-2024 09:27 AM | |
| 1 | 11-19-2024 12:32 PM | |
| 1 | 08-16-2024 08:01 AM | |
| 1 | 10-24-2024 12:02 PM |
| Online Status |
Offline
|
| Date Last Visited |
3 weeks ago
|