Latest Contributions by martinschaefer1

Point cloud data is becoming more used in the geosciences, with laser scanners and drones being more accessible. Point Cloud display in Pro remains problematic, even at 2.7.1. I would hope that ESRI either improve, or rewrite the point cloud display engine, as it is functionally less than useful. We normally resort to using a different point cloud display package, e.g. open source CloudCompare. In both maps and scenes Pro displays just the extent when zoomed out, not allowing an overview of the data. I have to zoom in to 1:128 to see the points in this drone derived LASD. Compare this to CloudCompare When zoomed in the point display needs a lot of tweaking to get a good quality rendering of the data and at high resolutions display is slow. In a dedicated point cloud package this is managed much better. I would hope that ESRI can improve on this performance. In the screenshot below you can see the points slowly being rendered on zoom. It doesn't even cache the views, this happens on every zoom level change.   My idea for improvements: Allow point display at all zoom levels Improve automatic point rendering settings for each zoom level Improve point display performance on zoom level changes/pan Thanks       ... View more

Pandas are a great asset for any data scientist. Data manipulation using pandas dataframes is powerful and easy. At the moment they only way to read feature class data into pandas for manipulation is using structured numpy arrays using arcpy.da.FeatureClassToNumPyArray, and then convert that to a dataframe. That is quite straightforward, but the reverse is more difficult due to the data types dataframes use. Strings are usually stored as objects, which arcpy.da.NumPyArrayToFeatureClass doesn't support. So each column's dtype has to be checked and converted if necessary. It'd be great to have a arcpy.da.FeatureClassToDataFrame and arcpy.da.DataFrameToFeatureClass. ... View more

Hi,  I've found in a couple of examples that using gdb as output in python toolboxes is much slower than standard files or shapefiles. Running in ArcPro 2.0.1 Toolbox that has a function that needs arcpy.sa.sample output for further processing. output sample results to .dbf, read back into a dataframe, delete dbf - 6.5s output sample results to scratch gdb, which is cleaner, read back into df - 25s toolbox that outputs new feature classes outputs to shp - 5.19s outputs to gdb - 18.8s In both cases the only difference in code is the storage in a gdb. Is anyone else seeing this performance issue using gdb storage?  Cheers M. Code snippet example for 1.1: out_table = (os.path.join(dir, 'zzz_{}.dbf'.format(os.path.basename(in_fc)[:-4]))) Sample(in_dem, in_fc, out_table, 'NEAREST') #read sample output into df fields = [f.name for f in arcpy.ListFields(out_table)] df_sample = pd.DataFrame(arcpy.da.TableToNumPyArray (                            in_table = out_table,                            field_names = fields,                            skip_nulls = True                            )) #remove sample output for _ in os.listdir(dir): if _.startswith('zzz_'):    os.remove(os.path.join(dir, _)) Code snippet example for 1.1: out_table = arcpy.CreateScratchName(workspace=arcpy.env.scratchGDB) Sample(in_dem, in_fc, out_table, 'NEAREST') #read sample output into df fields = [f.name for f in arcpy.ListFields(out_table)] df_sample = pd.DataFrame(arcpy.da.TableToNumPyArray(                         in_table = out_table,                         field_names = fields,                         skip_nulls = True                         )) ... View more