Latest Contributions by EricEagle

import arcpy import os gpkg = r"C:\Data\georgia.gpkg" desc = arcpy.Describe(gpkg) print(desc.dataType) print(desc.workspaceType) Result: Workspace LocalDatabase‍‍ walk = arcpy.da.Walk(gpkg) for path, names, filenames in walk: for fname in filenames: d = arcpy.Describe(os.path.join(path, fname)) print(fname, d.dataType) Result: main.ga_admin FeatureClass main.ga_highway FeatureClass main.ga_natural FeatureClass main.ga_poi FeatureClass main.ga_water FeatureClass‍‍‍‍‍ But if I add... for path, names, filenames in walk: for fname in filenames: d = arcpy.Describe(os.path.join(path, fname)) print(fname, d.dataType) print(f"Extent of feature class: {d.extent.XMin}, {d.extent.YMin}, {d.extent.XMax}, {d.extent.YMax}") print(d.extent) # sanity check Result: main.ga_admin FeatureClass Extent of feature class: nan, nan, nan, nan nan nan nan nan NaN NaN NaN NaN main.ga_highway FeatureClass Extent of feature class: nan, nan, nan, nan nan nan nan nan NaN NaN NaN NaN main.ga_natural FeatureClass Extent of feature class: nan, nan, nan, nan nan nan nan nan NaN NaN NaN NaN main.ga_poi FeatureClass Extent of feature class: nan, nan, nan, nan nan nan nan nan NaN NaN NaN NaN main.ga_water FeatureClass Extent of feature class: nan, nan, nan, nan nan nan nan nan NaN NaN NaN NaN‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ No extent.  However, if I load this content in ArcGIS Pro, it calculates the extent correctly. How do I get the extent of layers in a geopackage? ... View more

Sorry for the vague title but not sure how else to put this.  I'm on ArcGIS Pro 2.5. I've been moving mountains to get our org to adopt ArcGIS Pro and for the most part it's been great. However I have experienced nothing but tears of frustration and ashes and wasted lies in dealing with the temporal filtering functionality in ArcGIS Pro.  It is really... not good.  But I am not the sharpest lightbulb so it could be something I'm doing wrong.  I figured I'd ask here before I file a bug. I've got a single feature class (polylines); that feature class has a field called "temporal".  The values of that field are date-time stamps. I go to the feature class properties and enable Time.  Each feature has a single time field.  I set the time notation (Time Format) to YYYY-MM-DDThh:mm:ss and the Time Extent then populates automatically.  All is good!  The data is not a live feed, set to UTC, no offset, hit OK. This is where it gets crazy confusing.  And I'm sorry but the whole Time tab UI needs to be torn down and reimagined because it's kind of a mess. Anyway. I have the Time filtering button (enabled).  Then I have the "Current Time" block.  It is set to start time enabled, with the start time locked (as I want to view the data cumulatively as I drag the time slider end widget).  According to the documentation this is the overall "map" time.  So I set it to the same thing as my one feature layer. There is a Span field there that seems populated with some random value that has no relationship with my feature class (which is the only layer loaded). Under Full Extent I set it to my feature class with the time.  It automatically populates the Start and the End.  Set the time zone to UTC. Aaaaaand.... nothing shows up.  I drag the slider to cover periods where I know there is data, and nothing shows up (on the map or in attribute table).  I have tried every single combination of options in the Current Time window (which is already bad from a UI/UX perspective).  I've tried Use Time Span, manually set Step Intervals, or a fixed Number of Steps.  I've tried Time Snapping and no Time Snapping.  In fact at the end I just open up the slider all the way, to the full extent, and nothing draws. I've tried manually modifying the Span field under Current Time.  Still nothing.  The features do not draw when filtered by time even though the layer properties recognize the temporal value without issue. I've checked all time fields, there are no erroneous or malformed values or geometry. I tried creating a new feature class of points, and that didn't work either, so I am thinking there is a bug with 2.5's time manager.  Thoughts? ... View more

The LocateXT documentation says this:   When custom locations are turned on, content in the documents that are being scanned is compared against the place names specified in the custom locations file. By default, the content has to exactly match one of the specified place names to create a location in the output feature class.   This approach is deeply, deeply flawed.  The entire point of using something like LocateXT is to crawl information for explicit and implicit locations so that a human doesn't have to read them in the first place.  Under this, a person would have to read all the content, and enter a place name-coordinate pair for each non-coordinate location in a "custom locations file."  This is insane!   This is exactly what gazetteers exist for.  This is precisely what Geonames and OSM Nominatim exist for.  So this idea is for LocateXT to support gazetteer sources out of the box, including an OSM Nominatim service so that plain text names can be checked (completely or fuzzily) against Nominatim or other custom gazetteer sources.   I just bought 12 of these things so I'll have more ideas as we go along but for now, this is baseline type stuff that is required for the extension to be useful. ... View more

KML/KMZ is a common format for sharing geopositioned 3D models.  My office publishes a large amount of this content.  Some of it we create; some we receive from partners - so simply removing KML/KMZ from the business process is not a possibility. The problem is that importing and publishing KML/KMZ 3D models is tedious, but I know it could be made much easier with only a few simple changes on Esri's part! Currently, when a KMZ model is loaded into a 3D scene in ArcGIS Pro (imported into a 3D multipatch), the analyst must go through a process of determining the objective elevation of the multipatch, and then perform a manual move by editing the Z-value.  If this is not done prior to publication as a 3D web scene in Portal, the service will render the model at a 0/MSL altitude, causing it to draw "under" the elevation source in the web scene. So the current, bad workflow is: Analyst imports 3D KMZ model into ArcGIS Pro local/global 3D scene as multipatch. Analyst asks, huh, where's my model? Analyst turns off the elevation source and sees, there's my model. Analyst gets center coord of model. Analyst turns back on the elevation layer. Analyst selects a location to gather the elevation measurement. Analyst edits the multipatch. Analyst moves the multipatch to an absolute z-value. Analyst types in the value gathered 3 steps previously. Analyst saves the multipatch. Analyst sees, now the model correctly renders on the loaded elevation source. Analyst shares content as a web scene. This process could be made so much better.  I would like to see the following functionality: if a model is loaded in Pro and its elevation setting is set to "on the Ground"; then publishing that model as a web scene should cause the multipatch to inherit whatever that elevation value is. So the better workflow, broken down, would look like this: Analyst imports 3D KMZ model into ArcGIS Pro local/global 3D scene as a multipatch. (currently works) Analyst sets properties of multipatch to clamp to loaded elevation source (Ground). (currently works, tho it needs a refresh) Analyst shares workspace as 3D web scene, which automatically sets the model's elevation value upon publication. (currently not available). ... View more

KML/KMZ is a common format for sharing geopositioned 3D models.  My office publishes a large amount of this content.  Some of it we create; some we receive from partners - so simply removing KML/KMZ from the business process is not a possibility. The problem is that importing and publishing KML/KMZ 3D models is tedious, but I know it could be made much easier with only a few simple changes on Esri's part! Currently, when a KMZ model is loaded into a 3D scene in ArcGIS Pro (imported into a 3D multipatch), the analyst must go through a process of determining the objective elevation of the multipatch, and then perform a manual move by editing the Z-value.  If this is not done prior to publication as a 3D web scene in Portal, the service will render the model at a 0/MSL altitude, causing it to draw "under" the elevation source in the web scene. So the current, bad workflow is: Analyst imports 3D KMZ model into ArcGIS Pro local/global 3D scene as multipatch. Analyst asks, huh, where's my model? Analyst turns off the elevation source and sees, there's my model. Analyst gets center coord of model. Analyst turns back on the elevation layer. Analyst selects a location to gather the elevation measurement. Analyst edits the multipatch. Analyst moves the multipatch to an absolute z-value. Analyst types in the value gathered 3 steps previously. Analyst saves the multipatch. Analyst sees, now the model correctly renders on the loaded elevation source. Analyst shares content as a web scene. This process could be made so much better.  I would like to see the following functionality: if a model is loaded in Pro and its elevation setting is set to "on the Ground"; then publishing that model as a web scene should cause the multipatch to inherit whatever that elevation value is. So the better workflow, broken down, would look like this: Analyst imports 3D KMZ model into ArcGIS Pro local/global 3D scene as a multipatch. (currently works) Analyst sets properties of multipatch to clamp to loaded elevation source (Ground). (currently works, tho it needs a refresh) Analyst shares workspace as 3D web scene, which automatically sets the model's elevation value upon publication. (currently not available). ... View more

The Extent geoprocessing environment setting documentation here: https://pro.arcgis.com/en/pro-app/tool-reference/environment-settings/output-extent.htm lists "Same as Display" under the dialog syntax, but not under the scripting syntax.  I am building a script tool that requires "Same as Display" to be set as a default. Could someone share a snippet of code that demonstrates how I would set arcpy.env.extent to get the same effect as setting "Same as Display" in the dialog window? ... View more