Latest Contributions by DanPatterson

Making text fields in Pro or any many other tabular formats requires that you specify the field width to accommodate the larges width.  If you specify a size too small, data gets truncated, if it gets accepted at all. For example, lets make a small data set which we might want to add to a table. vals = 'abcdefgh' # -- an iterable to extract the values from # -- generate the values fld = [vals[i - 1] * i for i in range(1, len(vals) + 1)] fld ['a', 'bb', 'ccc', 'dddd', 'eeeee', 'ffffff', 'ggggggg', 'hhhhhhhh'] Now we cleverly create an array specifying a "field width"... I will use an array dtype in the following example. z0 = np.array(fld, dtype='U3') z0 array(['a', 'bb', 'ccc', 'ddd', 'eee', 'fff', 'ggg', 'hhh'], dtype='<U3') # --- notice that the array isn't correct !!!!! # --- there is truncation of the input values to a length of 3 (unicode text) Now add a field in a table in Pro and mis-specify the field width and see if the following holds the same as in the NumPy example (it does btw). Soooo, what did NumPy do?  They implemented https://numpy.org/neps/nep-0055-string_dtype.html  Here is how it works. z0 = np.array(fld, dtype='U3') # -- again with the input data z0 array(['a', 'bb', 'ccc', 'ddd', 'eee', 'fff', 'ggg', 'hhh'], dtype='<U3') z1 = np.array(fld, dtype=StringDType()) # -- notice that unicode and size not specified z1 array(['a', 'bb', 'ccc', 'dddd', 'eeeee', 'ffffff', 'ggggggg', 'hhhhhhhh'], dtype=StringDType()) # -- data size retained!!! This is one of the small obstacles that the arcpy people will have to deal with should they continue to move forward with supporting NumPy > 2.0. A few of the affected... ExtendTable—ArcGIS Pro | Documentation  FeatureClassToNumPyArray—ArcGIS Pro | Documentation NumPyArrayToFeatureClass—ArcGIS Pro | Documentation NumPyArrayToTable—ArcGIS Pro | Documentation ... View more