Allow Field Precision and Scale to be Defined in Feature Class Wizard

Happy to help everyone find a shared understanding, and happier that we can have this conversation in the context of this implemented Idea!

I'm the community manager for the geodatabase team, so feel free to @ me directly anytime you have geodatabase related ideas and I'll do my best to share the context I have.

ArcGIS field data types—ArcMap | Documentation

Thanks for the clarification @SSWoodward ! Never knew FLOAT was intended to be limited in the Enterprise GDB as the stated in the documentation. ArcGIS field data types—ArcGIS Pro | Documentation

For some reason ArcMap always created float as 38,8 numeric in SQL Server and was surprised to see Pro was different scale/precision but see it now aligns with the legacy desktop documentation.

Since shapefile, fileGDB, and mobileGDB don't support custom precision or scale, float / double are kind of like the short / long equivalents for floating point numbers. In those workspaces, if you want a smaller floating point numeric you use a float, if you want a bigger one use a double. Since we need to be able to map these types between geodatabases, we still have float and double in enterprise even though in the underlying database, the field types are often the same database field type with differing precision and scale.

For reference, we can examine what types of database field types these geodatabase types map to in the different supported databases here.

Well - that is interesting! I never knew that was the definition. I'll admit I've always been a bit vague on the usefulness of float. That's why I've never really used it.

Thanks @Michele_Hosking, and @RonnieRichards for your comments. @RonnieRichards can you share with me why you consider float "broken"? A float field type is intended to only store numbers with 6 digits or less. If users are looking for more than this, they would need to use a double.

What would you consider the expected behavior of a "working" float field to be?

Thanks for this @RonnieRichards. I can't check as we won't be updating until June-ish. Yay for me as we don't use float very often. It's a pity for those that do though....

@Michele_Hosking It looks like numeric/double is fixed and now defaulted to 38,8.

Float seems to still be broken with default still at 6,1 but can be changed but the resulting type in SQL Server is still showing numeric in our environment.

Lovely - thank you. What about the defaults though? Has this been changed from 7/1 for double?

Thank you everyone for your contributions to this thread!

In ArcGIS Pro 3.7, Enterprise Geodatabase users are able to define the precision and scale of floating point number columns directly within the Feature Class and Table Wizards. In the Wizard's field tab, importing an existing table now also sets the precision and scale values of the resulting fields to match the template fields.

PeterMilenkovic

Yea this is a big let down.

My scenario is that i want to import a table from one sde to another. The field i wanted to modify was at position 10 of 42 so there is no way i was going to do this manually....

I asked co-pilot to generate some arcpy (notebook) that

Copies the schema of the source to a dictionary
Allows user input to modify field length, scale, precision for the specific field
Creates new fc
Systematically runs the add field tool using the schema dictionary

import arcpy, os

# Path to your feature class
source_name =<fc name to copy schema>
out_workspace = <path to sde connection>
out_name = <fc name>
spatial_ref_wkid = 7856  

# Initialize dictionary
schema_dict = {}

system_fields = ['OBJECTID','Shape','Shape.STLength()','Shape.STArea()']

source_fc = os.path.join(out_workspace, source_name)

# Loop through fields
for field in arcpy.ListFields(source_fc ):
    if field.name not in system_fields:
        schema_dict[field.name] = {
            "type": field.type,
            "length": field.length,
            "precision": field.precision,
            "scale": field.scale
        }

## hard coding the new precision/scale/length for the specific field
schema_dict['Estimated_Cost']['precision']=20
schema_dict['Estimated_Cost']['scale']=2
schema_dict['Estimated_Cost']['length']=22

SYSTEM_FIELD_NAMES = {"OBJECTID", "FID", "Shape", "SHAPE", "GLOBALID", "Shape_Length", "Shape_Area"}

def map_type_to_addfield(field_type):
    """
    Map Describe/ListFields types to AddField types.
    ArcPy expects AddField type keywords (TEXT, SHORT, LONG, FLOAT, DOUBLE, DATE, GUID, BLOB, RASTER).
    """
    mapping = {
        "String": "TEXT",
        "SmallInteger": "SHORT",
        "Integer": "LONG",
        "Single": "FLOAT",
        "Double": "DOUBLE",
        "Date": "DATE",
        "GlobalID": "GUID",
        "GUID": "GUID",
        "Blob": "BLOB",
        "Raster": "RASTER",
        # Types we won't add: 'OID', 'Geometry' (system-managed)
        "OID": "OID",
        "Geometry": "GEOMETRY",
    }
    return mapping.get(field_type, field_type)

def make_spatial_reference(wkid):
    if wkid is None:
        return None
    sr = arcpy.SpatialReference(int(wkid))
    return sr

# --------------------------
# Create feature class (Polygon, no Z, no M)
# --------------------------
if not arcpy.Exists(out_workspace):
    raise RuntimeError(f"Workspace does not exist: {out_workspace}")

sr = make_spatial_reference(spatial_ref_wkid)
arcpy.management.CreateFeatureclass(
    out_path=out_workspace,
    out_name=out_name,
    geometry_type="POLYGON",
    template="",
    has_m="DISABLED",
    has_z="DISABLED",
    spatial_reference=sr
)

out_fc = os.path.join(out_workspace, out_name)

# --------------------------
# Add fields by looping schema_dict
# --------------------------
for fname, props in schema_dict.items():
    # Skip known system fields if they were captured in your dict by accident
    if fname in SYSTEM_FIELD_NAMES:
        continue

    ftype = map_type_to_addfield(props.get("type"))
    if ftype in ("OID", "GEOMETRY"):
        # Do not add system-managed types
        continue

    length = props.get("length")
    precision = props.get("precision")
    scale = props.get("scale")

    # ArcPy expects "" (empty string) for unspecified numeric props
    # and uses 'length' only for TEXT/BLOB; precision/scale for numeric
    arcpy.management.AddField(
        in_table=out_fc,
        field_name=fname,
        field_type=ftype,
        field_precision=precision if (precision is not None) else "",
        field_scale=scale if (scale is not None) else "",
        field_length=length if (length is not None) else "",
        field_alias=fname,  # keep alias same as name; change if you have it
        field_is_nullable="NULLABLE",
        field_is_required="NON_REQUIRED",
        field_domain=""
    )

print(f"Created feature class and added {len(schema_dict)} fields at: {out_fc}")

PhilippeChesselVdG

Hello,

Yes , i am totally in line also with @Michele_Hosking , the problem is the change in 3.2 for Double and Float that has no logic and no justification for it. (Or ESRI should give us any good reason or that , i can hardly find any ?)

And it is complicating a lot the life of end users.

The best option would be to allow scale and precision definition into the Add Table/Class wizard.

@Michele_Hosking you are absolutely correct with that!!

This appeared to happen in the 3.2 release when the other GDB changes were introduced. Pro 3.2+ double data types are created as 7/1. This release also seems to break the FLOAT datatype.

Tables created prior to 3.2 release double data types were defined as 38/8.

And you know what - it's not all about the Create Feature Class/Table wizards in Pro. It's the fact that somewhere along the line (and this did happen during the ArcPro days) the default for a double field in an enterprise geodatabase has changed from 38/8 to 7/1. Now 38/8 is a little ridiculous I grant you but at least it's useful. It allows you to put whatever you like in the field so if someone forgets to change the precision it's still going to work. 7/1 is just a pain in the proverbial. As part of this can we please have this default changed to something sensible otherwise we will still be having the issue of finding out that a field doesn't have enough decimal places after a feature class /table has been created due to over-looking the 7/1 precision default and be back in the stupid position of having to recreate a table just to fix this issue.

@SSWoodward

@mpboyle is correct I don't think the option to specify precision in the Create Feature Class/Table wizards have ever been present in a Pro release.

The right click within an Enterprise Geodatabase in Catalog is one of the quickest navigations for new tables in Catalog. Right click create a new table and import from a template.

As an educator students are going to gravitate to the context tools before searching for geoprocessing tools so please make them behave consistently. Your future ArcGIS Desktop users will appreciate consistency and really enjoy creating GIS data models in the Enterprise GDB especially considering this requires Professional Plus licensing to "create" in an EGDB.

This was a solid workflow in ArcMap

@mpboyle yes that's correct. The feature class and table wizards have never had the ability to set scale or precision in ArcGIS Pro.

There are lots of clever users who make use of the software in unexpected ways, so I was hoping to get more information about the workflow to make sure I was on the same page as everyone with what was being shared.

mpboyle

@SSWoodward

To the best of my knowledge, having the ability to define precision and scale, specifically on the Create New Feature Class/Table interface has NEVER been available in Pro.

This IS available in ArcMap/Catalog, and as many commentors have mentioned, having this ability seems rather simple given that it's available in ArcMap/Catalog and for certain Pro tools (ex: Add Field tool), and its omission is frustrating, especially going on 10 years of having Pro.

Pro Create New Feature Class Interface --- this is an enterprise geodatabase --- no ability to define precision and scale in the field properties

ArcCatalog Create New Feature Class Interface --- same enterprise geodatabase as above --- ability to define precision and scale

Pro Add Field tool --- Precision and Scale ARE available

Thanks everyone for continuing to share your feedback.

@Michele_Hosking At ArcGIS Pro 3.5 the maximum field name length has been increased to 128 or the maximum allowed by the underlying databased platform, whichever is less. This should address the naming issue you have shared. What's new in 3.5

@RonnieRichards is correct, there is no concept of user defined scale or precision in geodatabases other than enterprise geodatabases.

@RonnieRichards you also shared that;

"Creating data models using templates used to be a very productive workflow, now it no longer works due to this 7.1 madness"

Can you share the version of ArcGIS Pro where this workflow changed for you? Or was this a workflow in ArcMap that is now disrupted on a migration to ArcGIS Pro?

@RonnieRichards - thanks for the suggestion. I might try RDBMS tools as well. The world is a funny place. Things that work get broken and things that are broken are never fixed. Entropy I guess.....

@Michele_Hosking Agreed this is frustrating! To provide a little more background to some of what you encountered:

File, Mobile Geodatabases and GeoPackages do not technically have decimal data types with precision, they are all considered float which is why you get the 38,8 definition.

However the experience of designing data models in the Enterprise geodatabase has been completely destroyed. Creating data models using templates used to be a very productive workflow, now it no longer works due to this 7.1 madness. At our organization we now create all of our data models in unregistered tables using the RDBMS tools and then register them with the geodatabase when confirmed.

Any changes to these then encounter all of the issues you and others shared on this thread. We use backend rdbms tools to modify column definitions in non-versioned environments due to all of the hoops required using Pro management tools.

Educating new users and staff with the work arounds and other approaches make very little sense, please just fix this tool to work like it used to allowing users to alter decimal precision where applicable.

This is so frustrating - who thought 7/1 was a good default? I even tried copying my feature class from enterprise to a fgdb to change the precision - precision doesn't even show then. You can't even use the Create Feature Class wizard and use a template to pull in the fields because it just uses the same as the template without the opportunity to change anything. I'm trying to fix one field out of 44 in a feature class. What - I have to create it with no fields and put in 44 fields again manually in order to sort this? Why was this functionality ever removed? Why was the default for double made 7/1? Does anyone who makes these decisions actually do any real work? It so frustrating.

Oh and P.S - you can't use the Export Feature Class to Feature Class either....

And while we are on the subject - why has the max length of a field name dropped from 30 to 29 characters? 'Cos I'm currently re-making my feature class from scratch and I can't even copy in a field name that already exists in a current feature class as it has 30 characters - now I have to change the name of a field because it won't fit!!! OMG - it just gets worse - 'cos this feature class is everywhere. You know the hoops I have to jump through if a field name changes? And don't quote me on this but I'm pretty sure a few years ago (maybe ArcMap??) the max field name length used to be 31.

Ok - because of the field length issue above this is what I have to do to get around everything...

Export fc to fc and remove offending field in the process (in enterprise 'cos you can't even see the precision of a new double field in a fgdb let alone change it)
Add the field into the fc copy - but now - you know - the field is at the end of the list of fields and not where it's supposed to be so...
Export the fc copy to fc copy 2 and move the field in the process
Truncate and append the data from the original fc to copy 2 as you've lost all the data in the offending field
delete the original and copy 1
rename copy 2

After all that when I changed the precision to 10/2 it's actually changed it to 38/8. Oh well - small wins I guess....

What a palaver.

PhilippeChesselVdG

Same comment again, with ArcGIS Pro 2.9 to 3.3 migration, with this behavior of default Double as (7.1) and FLoat as (6.1) numerics.

The default is so useless when a user think of creating Double or Float (latitude, longitude, X, Y fields, ...)

And having to tell the end users that they have to use "Add Field" wizard for every field of the new class or table is not comfortable.

The Field Designer does not allow to modifiy the precision/scale of existing fields.

Is there eventually other ways ?

Thanks

PhilippeChesselVdG

Same issue with a Enterprise Géodatabase (ORacle 19.x, géodatabase sde 10.9.1 ou 11.3_3.3.4)

And ArcGIS Pro 3.3.4

The default of the Float data type in the database is created as 6.1

The default of the Double data type in the database is created as 7.1

This is problematic as soon as you want to create décimal fields like coordinates 😞

The 6.1 and 7.1 defaults are not visible on screen when creating the feature class

Please, we need then to be able to modify while creating Double end Float fields the scale/precision

mthompson_WellesleyMA

Thank you for the workaround, I tried using a file GDB feature class as a template to import into an enterprise GDB and it defaulted Double fields to 38/8 which will at least be able to accommodate my longer values.

https://support.esri.com/en-us/knowledge-base/how-to-customize-numeric-data-precision-and-scale-in-ar-000029280

Thanks for sharing your frustration @mthompson. I totally get it, and this Idea is being examined by the team.

In the mean time, passing the class as a template to the Create Feature Class GP tool, and not the wizard, will bring along existing precision and scale values from the template class in to the newly created feature class in an enterprise geodatabase. It is accurate that the wizard does not provide functionality to set precision and scale in the current version of ArcGIS Pro. The wizard will set precision and scale to their default settings based on the datatype.

mthompson_WellesleyMA

This is absolutely insane that you can't change the settings of all the fields when you create a new feature class or table. I'm constantly baffled and disappointed with ArcGIS Pro.

The only tool I can find that even acknowledges scale/precision exists is the Add Field tool. Alter Field and Add Fields (plural) don't let you pick scale or precision, importing a full feature class changes them from whatever they were to 7/1, using Create Feature Class wizard and importing fields defaults to 7/1, using Create Feature Class wizard and adding a double field from scratch defaults to 7/1.

I have 20 fields I need to import and I'm going to have to create the feature class and then use the Add Field tool 20 times which is ridiculous when I could have just imported the fields in ArcMap in 5 seconds.

GIS_Spellblade

Yeah I came to see if this was an idea already or not. Currently the only way to define numeric precision is through the Alter Field GP Tool or the Data Design GUI. I would argue that most users create feature classes utilizing the Create Feature Class / Create Table wizard. Based on @RonnieRichards comment above, it looks like this functionality was present in ArcGIS Desktop and just was not ported over to ArcGIS Pro.

The current state of affairs is pretty burdensome as a field as to be newly added, properly defined, and then the old field tossed out. My organization has had to do a lot of re-work in terms of data clean-ups as our Analysts were unaware of the default values that were being created through the use of the Create [...] wizards.

I submitted this because ran into a bug in Pro 3.2.2 with all numerics fields from import being created as numeric(7,1)

Template Table used to import fields and precision and scale are not respected for any of them, resulting in all 7,1 values including a float data type! Please fix this stuff!!

In past releases of ArcGIS it was possible to modify the precision and scale for numeric fields when importing fields from another class during New Feature Class or New Table create screens.

In the latest versions of Pro 3.2.2 it appears the numeric precision and scale are not shown and the result seems to have issues maintaining the precision/scale from the import. It would be nice we could fix these issues before the tables get created incorrectly...

Please restore the ability to edit the numeric precision and scale, we can still edit text field lengths on the fields screen.

Thanks
Ronnie

Bud

Agreed. I want to create DOUBLE fields in the Create Table wizard where the precision is 15 and the scale is 2.

ArcGIS Pro 3.2.2