When exporting data to a particular format, provide methods that enable users to check what potential limitations may be imposed by that format, in order to identify and address potential data loss. This would be for classes like, arcgis.features.GeoSeriesAccessor.to_featureclass(), arcgis.gis.Item.export, arcgis.features.FeatureSet.to_geojson, etc.
This will assist users – both new and experienced – with quality assurance when managing the export of data to a more limited format, such as from a feature set or hosted feature layer to a shapefile. Issues can arise later on, particular with automations, where changes in the data may trigger unexpected results not caught during initial testing. To enable users to produce more robust code for dealing with such circumstances, provide methods for evaluating limitations imposed by an export format on the original data source.
Some quality assurance testing for these situations is already provided by methods like arcgis.features.GeoAccessor.sanitize_column_names.
I’m sure many folks regularly find themselves writing code to check original data sources against potential limitations of an export format, with logic to decide on a predictable way to address those shortcomings, or to log a helpful error message for manual intervention. It would be helpful to have standardized methods in the API for the former part, identifying those export limitations in the context of a specific data source and the chosen format (e.g., shapefile, csv, kml, geojson.)
For example, if exporting from a hosted feature layer to a shapefile, then warn a user about field names that will get truncated (and what the autogenerated new field names will be in a shapefile, in case they want to capture a field mapping to metadata), datetime fields (which will have their time component truncated, which they may want to address before the export by splitting into two fields), attachments that will not be included (which they may decide to export separately to a zip file with a link table), etc.
