Latest Contributions by KimOllivier

The replace layer option in the ArcGISPro share dialog needs exclusive access. It crashes if I also have the layer open in AGOL. That might also be a problem if the layer is being used in Survey123 or FieldMaps. It is also not dynamic. New records will need to be processed. I thought of a virtual field, but that might not be possible. ... View more

A hosted featurelayer of half a million records? I assume it is on your own server, not ArcGISOnline? The storage charges are per 10MB, not per Gigabyte! Have you tried a virtual field(s) in the WebMap? Then you can use Arcade to generate the new fields dynamically.   ... View more

I have just upgraded to 3.4.0 which is no better. It has been a problem ever since 3.3.1. Maybe due to BigInteger introduction? ... View more

Why are you using shapefiles and excel tables? You would be much better off using a proper database format with tables. Then you can validate the data and control the data schema. It will be faster and more robust. It will handle the difference between blanks and null values. You can use the Microsoft schema.ini file to properly define the schema for the excel spreadsheet before you import it to a database table. Once in a database the keys you are going to use for the table join can be indexed for speed, set to NOT NULL to make sure they are always populated and generally document the schema. The codes with dashes have to be strings, but that may need to be explicitly set. ... View more

It anything takes longer than a cup of coffee, interrupt the process and find a better way! It is likely that it will crash with no results if it has to run for days. To update an online table from ArcGISPro it only works for a few records. If you need a bulk update the best way is to export the table to a local filegeodatabase, do the process on a local machine and then replace the online layer. The replace layer function actually does a Staging Update. This zips up the file and metadata for the layers, uploads and then unpacks in the cloud. This all takes a few seconds or at the most minutes.   ... View more

Use FME. That will work forever, they never deprecate earlier readers. It is also called Data Interop for the Esri addon if you want to pretend that it is an Esri extension. ... View more

Have you considered the GroupBy function in Arcade? This seems to be very useful to group multiple names and get a count. ... View more

But there is another  problem not covered by my workaround. OBJECTID can be 32 or 64 bit as well. This is much harder to change and even detect. The type is "ÓID" for both (not helpful) but you can find out the length is 4 or 8. If the table is empty you can edit the field schema by hand to fix it, but I don't know how to do it in a script. ... View more

You may need to fix a bug(?) that adds a blank field to the end of the arcpy.ListFields(fc) command. fields = arcpy.ListFields(input_fc) print(f"L42 {[f.name for f in fields]}") for field in fields: if field.type not in ('OID', 'Geometry'): # not allowed in fieldmappings if field.name: # very strange blank name added to list by Esri field_map = arcpy.FieldMap() # new for each field print(f"L46 {input_fc},<{field.name}>") ... View more

We handle this by having a point layer of labels that relate back to the polygons. There is only one point for each property, but some properties are multipart. That doesn't matter because they still have a total area. You only get one label so it is placed in the largest part. You add labels when they have been exploded and then choose the largest one. Run a summary by max area and then select the largest, discarding the others. If you want to get rid of the non-boundaries there is an aggregate tool. ... View more

There are two obvious tools to create a set of index sheets based on the centroids. Do you have a sheet size in mind? Thanks for the sample that makes it much easier to experiment. The first thing I did was to project the data to a filegeodatabase so that I have feet units. My first attempt was to just create Thiessen polygons around the points. This works well for even spacing. There are a few long bits around the edges. You could trim them up and straighten the fuzzy bits by snapping to the larger index.   I then tried a Graphic Buffer with a size of 290 metres. This also gave a good start, a bit of integration would snap the overlaps to a tidy grid.   ... View more

Even if the policy is correctly set for casting the ambiguous Integer type I still need a solution that works for me. I can see that computing has evolved from 16 to 32 to 64 bit integers and some are defined as signed and unsigned. I have seen LONG, MEDINT, INTEGER and SHORT as well as the new BigInteger to try to extend the meaning of 'LONG' which in 32 bit days meant only 32 bits. To keep backward compatibility the temptation is to reuse 'Long' for 64 bit when using a 64 bit compiler. I was interested to see that MEDINT was interpreted as Long and INTEGER as BigInteger going from a gpkg to a filegeodatabase. So redefining the gpkg field type might be a good workaround that avoids having to explicitly cast the fieldtype using a fieldmappings parameter with ExportFeatures_conversion() replacing CopyFeatures(). [note that sqlite does not care what you call it in the DDL, they are always 64 bit integers internally] The small print in the help also explains why the option setting in Options in ArcGISPro does not work for me. Because if running a script outside ArcGISPro in the command line you have to set the options in the arcpy environment. arcpy.env. But Double is useless for me. I want to use the field as an indexed key so it has to be some sort of integer. Insert below: useCompatibleFieldTypes (Read and Write) Specifies whether field types that are compatible with ArcGIS Pro 3.1 will be used. This setting relates to the use of the Date Only, Time Only, Timestamp Offset, and Big Integer field types in CSV tables and unregistered database tables with tools that create layers or table views. When set to True, a layer or table view created from these sources will use field types compatible with ArcGIS Pro 3.1. Date Only, Time Only, and Timestamp Offset fields will be displayed as Date fields, and Big Integer fields will be displayed as Double fields. When set to False, all original data source field types will be used.   Note: This property is applicable when used from stand-alone Python or for a geoprocessing service. When used in ArcGIS Pro, this property will always match the Use field types that are compatible with ArcGIS Pro 3.1 and earlier releases when adding query layers and text files option.   A better option I have implemented is to replace CopyFeatures_management() with my own function CopyFeaturesLong() that looks for any BigInteger arcpy interpretations and keeps them as a compatible Integer, not a Double. Here it is if you want to use it. There will need to be a similar function to replace CopyRows().       def CopyFeaturesLong(input_fc, output_fc): """CopyFeatures replacement to ensure every BigInteger is mapped to Long with a fieldmappings parameter using arcpy.conversion.ExportFeatures() with a bit of help from copilot! full paths to featureclasses assumed """ # Create FieldMappings and FieldMap objects field_mappings = arcpy.FieldMappings() # List of fields to process # it would be nice if objectid and shape could be excluded easily fields = arcpy.ListFields(input_fc) for field in fields: if field.type not in ('OID', 'Geometry'): # not allowed in fieldmappings field_map = arcpy.FieldMap() # new for each field field_map.addInputField(input_fc, field.name) # Check if the field type is BigInteger and change to Long field_name = field_map.outputField if field_name.type == 'BigInteger': field_name.type = 'Long' field_map.outputField = field_name # Add the FieldMap to the FieldMappings object field_mappings.addFieldMap(field_map) # Use ExportFeatures to apply the field mappings and create the output feature class arcpy.conversion.ExportFeatures(input_fc, output_fc, field_mapping=field_mappings) if debug: for fld in arcpy.ListFields(output_fc): print(fld.name,fld.type) print(f"{output_fc} Feature class successfully exported with updated field types!") return True def CopyRowsLong(input_tab, output_tab): """CopyRows replacement to ensure every BigInteger is mapped to Long with a fieldmappings parameter using arcpy.conversion.ExportTable() with a bit of help from copilot! full paths to featureclasses assumed """ # Create FieldMappings and FieldMap objects field_mappings = arcpy.FieldMappings() # List of fields to process # it would be nice if objectid and shape could be excluded easily fields = arcpy.ListFields(input_tab) for field in fields: if field.type not in ('OID', 'Geometry'): # not allowed in fieldmappings field_map = arcpy.FieldMap() # new for each field field_map.addInputField(input_tab, field.name) # Check if the field type is BigInteger and change to Long field_name = field_map.outputField if field_name.type == 'BigInteger': field_name.type = 'Long' field_map.outputField = field_name # Add the FieldMap to the FieldMappings object field_mappings.addFieldMap(field_map) # Use ExportFeatures to apply the field mappings and create the output feature class arcpy.conversion.ExportTable(input_tab, output_tab, field_mapping=field_mappings) if debug: for fld in arcpy.ListFields(output_tab): print(fld.name,fld.type) print(f"{output_tab} Table class successfully exported with updated field types!") return True       ... View more

Correction: you cannot hide fields in Pro, they all have to be visible. ... View more