Select to view content in your preferred language

Store geoprocessing outputs in a format accessible to ArcGIS Pro and Excel

346
2
08-29-2024 04:59 PM
Labels (2)
Bud
by
Esteemed Contributor

ArcGIS Pro 2.9.5; Oracle 18c 10.7.1 EGDB; ST_GEOMETRY

Our master GIS data is stored in our enterprise geodatabase. The data can be easily accessed in Excel via ODBC for the purpose of tabular analysis and visualization by non-GIS people. That works well.

However, when it comes to one-off geoprocessing outputs, I haven’t found a good place to store the resulting data. For example, I used the Spatial Join GP tool on EGDB data to bring the attributes of a polygon FC into a point FC (intersect).

The question is: Where to store the output? The data needs to remain accessible in ArcGIS Pro. And it should also be accessible in Excel for the purpose of tabular analysis and visualization by non-GIS people.

  1. I don’t want to clutter the EGDB with a FC like PERMITS_spatial_join_SUBDIVISION_20240829.
  2. The data won’t be used regularly, but we do need to keep it for approximately one year.
  3. I could ask I.T. to create a data owner in the EGDB called GP_OUTPUTS and store this kind of data there. But it seems backwards to store ad hoc data in a production enterprise database.
  4. The source FCs have tens of thousands of features, so a ST_GEOMETRY spatial SQL query would be far too slow. Additionally, the query would be dynamic. In this case, a static, unchanging snapshot is preferred.
  5. A file geodatabase won’t work because it wouldn’t be accessible from Excel.
  6. Storing the data within an .XLSX file would strip out the spatial component. I’d prefer not to do that; I still want to access the data spatially in ArcGIS Pro. Storing point coordinates in X & Y columns in the Excel data would only work in select cases, not for non-point data.
  7. Concurrent users aren’t a concern. And read-only access is fine.
  8. A file type that supports full-blown SQL queries would be preferred. Such as running a SQL GROUP BY query using Excel’s “Microsoft Query” window and ODBC. Excel Power Query would be an alternative option, but it is pretty clunky compared to SQL.

Any ideas?

0 Kudos
2 Replies
MobiusSnake
MVP Regular Contributor

Seems like a good case for a Mobile GDB.  Accessible from Pro, supports all GDB functionality, apparently readable from Excel since a Mobile GDB is built on Sqlite (although I haven't connected to MGDBs using Excel, apparently Excel can read Sqlite, and I have read MGDBs using other Sqlite clients).

Bud
by
Esteemed Contributor
0 Kudos