Latest Contributions by VinceAngelo

For reference, the empty array trick works for Polygon, Polyline, and Multipoint classes, but PointGeometry won't accept a None point parameter. - V ... View more

You can use the Well-Known Text keyword "EMPTY" to generate a NIL geometry:     import arcpy sr = arcpy.SpatialReference(4326) np = arcpy.FromWKT("POLYGON EMPTY",sr) print("np - pointCount: {:d} JSON: {:s}".format(np.pointCount,np.JSON)) nl = arcpy.FromWKT("LINESTRING EMPTY",sr) print("nl - pointCount: {:d} JSON: {:s}".format(nl.pointCount,nl.JSON)) nm = arcpy.FromWKT("MULTIPOINT EMPTY",sr) print("nm - pointCount: {:d} JSON: {:s}".format(nm.pointCount,nm.JSON)) nx = arcpy.FromWKT("POINT EMPTY",sr) print("nx - pointCount: {:d} JSON: {:s}".format(nx.pointCount,nx.JSON)) print("nx - firstPoint: {:s}".format(str(nx.firstPoint)))     which results in:     np - pointCount: 0 JSON: {"rings":[],"spatialReference":{"wkid":4326,"latestWkid":4326}} nl - pointCount: 0 JSON: {"paths":[],"spatialReference":{"wkid":4326,"latestWkid":4326}} nm - pointCount: 0 JSON: {"points":[],"spatialReference":{"wkid":4326,"latestWkid":4326}} nx - pointCount: 1 JSON: {"x":"NaN","y":"NaN","spatialReference":{"wkid":4326,"latestWkid":4326}} nx - firstPoint: None     Curiously, the PointGeometry type always returns a pointCount of one, but the firstPoint is None.   WKT can also be used at the SQL prompt in Oracle:   SQL> SELECT 'POLYGON' as type,SDE.ST_ASTEXT(SDE.ST_PolyFromText('POLYGON EMPTY',4326)) as geom FROM DUAL; TYPE ------- GEOM -------------------------------------------------------------------------------- POLYGON POLYGON EMPTY SQL> SELECT 'LINE ' as type,SDE.ST_ASTEXT(SDE.ST_LineFromText('LINESTRING EMPTY',4326)) as geom FROM DUAL; TYPE ------- GEOM -------------------------------------------------------------------------------- LINE LINESTRING EMPTY SQL> SELECT 'MPOINT ' as type,SDE.ST_ASTEXT(SDE.ST_MPointFromText('MULTIPOINT EMPTY',4326)) as geom FROM DUAL; TYPE -------- GEOM -------------------------------------------------------------------------------- MPOINT MULTIPOINT EMPTY SQL> SELECT 'POINT ' as type,SDE.ST_ASTEXT(SDE.ST_PointFromText('POINT EMPTY',4326)) as geom FROM DUAL; TYPE ------- GEOM -------------------------------------------------------------------------------- POINT POINT EMPTY SQL>   - V ... View more

A NIL (zero vertex) geometry is a valid shape type. It is required for some operations (e.g., the result of the intersection of two disjoint features).   The shapefile specification permits Nil paired with any other one geometry type as the supported types in shapefiles. How would it be an "enhancement" to remove this capability? - V ... View more

I've seen this behavior in Python often enough. I just assumed it was quirk of how Python operates -- if you don't fill all the values, it uses the value with which the object was initialized (the current time). So I usually combine strptime with a replace: to clear the microseconds property (and to either clear or force a UTC timezone)   import datetime test_str = '2023-10-16T07:50:00' new_dt = datetime.datetime.strptime( test_str,'%Y-%m-%dT%H:%M:%S').replace( microsecond=0,tzinfo=None) print(new_dt.strftime('%Y-%m-%d %H:%M:%S.%f %Z'))   The funny thing is, I can't reproduce the problem in the Python in my Pro 3.1.1 or ArcMap 10.8.2 installs, so maybe that Python "feature" has been cleared. What version of ArcGIS are you using for the ConvertTimeField utility? - V ... View more

Which Python are you using?  I've ingested tens of millions of rows in 64-bit Python 2.7 (64-bit Geoprocessing for ArcMap), and processed 40-60 million rows in 64-bit Python 3 (ArcGIS Pro). Both of those VMs had less than 32GiB RAM available. - V ... View more

Be careful. The polygon area or line length can be in the list of fields. You only need to query one table's columns, so sorting shouldn't be necessary, but you can cross-check to make sure they're all present (again, as a safety thing). - V ... View more

If the data is small enough*, I prefer to cache the array and not use nested cursors. This is especially true with EGDB feature classes, which do not like with nesting. - V *Nowadays, "small enough" is "less than 10-20 million rows". ... View more

Best practice would be to capture the source column names (arcpy.ListFields), replacing the 'Geometry' column with 'Shape@', then using explicit column names for both cursors. Using a wildcard is likely to cause trouble if the tables are altered with a new column. - V ... View more

You can create a field that contains whatever you want to populate, but polygons don't have length, just (2D) perimeter. - V ... View more

For statistical purposes, you should use the same set of points in each environment.  This could be done by initializing the random class with same initialization seed. - V ... View more

This sounds like there could be corrupt metadata. Check the table and layer metadata and the database itself for table existence. You might need to delete rows or recreate the table with CREATE TABLE to delete it cleanly (though this should be done with close cooperation with Tech Support). - V ... View more

Best practice is to use str.format() (or f"") to layout your expression (and avoid error-prone string math). If you're having difficulty, you should always print the resulting parameters. And test the resulting statement from the UI. Without seeing the contents of the table or the resulting expression, there isn't much we can do to help. - V  ... View more

You need to include the meat of your execute() function in order to get help on this. The code should include an arcpy.da.Editor "with" block. - V ... View more

Shapefiles use 8-byte (64-bit) IEEE storage for all coordinate values.  The "32-bit" issue was in how what is now called BASIC spatial references handled coordinate processing.  While geodatabases store floating-point coordinates in a compressed bytestream which uses integers, the coordinates can be expressed as 8-byte (double precision) floats at any time. "Fuzzy creep" wasn't really a thing back in ArcInfo days (you'd have to misuse the software, changing the tolerance with each processing step to make it happen), and is less of a thing now (because tolerances are fixed by invariant spatial references). - V ... View more

There's a bunch of issues in the referenced post, wrongly conflated, or just plain wrong. IEEE floating-point storage is not "inaccurate" -- Floating-point operations are way more accurate than geodata It's not the accuracy (or precision) of floating-point representation which makes the fuzzy tolerance necessary, but the inherent accuracy of freely collected vertices ArcMap (and all of ArcGIS Desktop and Server products) has always had access to tolerances in coincident coordinate calculation The shapefile format was independent of ArcView, and the shapefile format does not have any of the quirks of the how ArcView (which is ancient, and retired) calculated coordinate values. While there may be gaps between geometries in shapefiles (or file or enterprise geodatabase), there are tools to detect them, and repair them (if they are significant enough to bother) The title of this thread is misleading, and refers not to coordinates, but dBase values; while dBase does have both binary and textual storage options for floating-point values, the scientific notation used in the text values is either at, or exceeds the stated precision of the field (and often of the IEEE format itself) So, basically, the entire article was wrong then, and hasn't gotten any better in the decades since. Since understanding how coordinate values are maintained is important, I refer you to the Understanding Coordinate Management in the Geodatabase whitepaper. - V ... View more