What determines feature layer order when publishing service from GDB upload?

[GB_MattPanunto_GISS]

When publishing a service via GDB upload, I assumed feature layer order was determined by the alphanumeric sorting of GDB feature class names, but this does not seem to be the case. My GDB has 3 feature classes, a Point, and two Polygon feature classes. They are named:

"A" (Point)

"B" (Polygon)

"C" (Polygon)

When I upload the GDB to publish the service, the resulting layers are in  B-C-A order. I want them to be in A-B-C order. How do I do that?

[MatthewBrown8]

Hi GB_MattPanunto_GISS

Thank you for your question. Can you please provide an image of the described issue?

It is expected that feature classes participating in a file geodatabase should be ordered alphanumerically. Have you double checked the names of each feature class to rule out the presence of any influencing factors (e.g. unexpected characters)?

Regards,

[GB_MattPanunto_GISS]

Here you go. The first image shows the GDB from within the Catalog Pane. While the second image shows the resulting service that is published by uploading this GDB to ArcGIS Online. There are no unexpected characters in the names of the GDB, or the feature classes.

1)

2)

[MatthewBrown8 · Accepted solution]

Thanks for providing further detail GB_MattPanunto_GISS.

I performed a number of tests and was able to reproduce the described behavior. The results suggest that while feature layers stored within a file geodatabase adhere to alphanumeric ordering, when published to ArcGIS Online as a hosted feature layer, the layers are listed according to the order they were created in. This is further highlighted in the attached images, where layer 'F' was created before layer 'E'. 

Regards,

[GB_MattPanunto_GISS]

Ahhh good sleuthing! Glad there is a way to resolve this issue. Can't help but wonder, is this working as intended?

[SerjStol]

@MatthewBrown8 Could you please clarify on what you mean by "the order they were created in". Is it when they were created in FGDB itself or when they were being published? Regardless of the order I create the layers in FGDB, when I publish to ArcGIS Enterprise via Pro or my GP tool, the ordering changes and is really frustrating as I want one specific layer to be at the bottom for specific use case.

[DavidTillberg_community]

The order they are created in the FGDB.  You can check the order by listing featureclasses/tables/relates.  The order of the service indices is the same as returned by arcpy.ListFeatureClasses() for Feature Layers, continued by arcpy.ListTables() for tables, and that finally tables that define M -> M relationships are listed in order they were created.

[SerjStol]

@DavidTillberg_community thanks for a prompt response. I have just checked arcpy.ListFeatureClasses() on the FGDB and the layer that I want to be at the bottom is correctly listed at the end as I specifically wrote my code to create that layer last.  But when I publish that FGDB to ArcGIS Enterprise (11.3) then the ordering is not honored, its totally different. Seems like a bug, or a different behavior to AGOL, which I havent tried.

[SerjStol]

@DavidTillberg_community @MatthewBrown8 Ok I just tested uploading the same FGDB to AGOL and it DOES honor the layer creation order. So it seems that ArcGIS Enterprise (11.3 in my case) does not honor the same logic. We will raise this as a bug via my esri.

[DavidTillberg_community]

I only tested for ArcGIS online, not ArcGIS Enterprise.  I also only tested by publishing the FGDB directly to AGOL, not publishing using ArcGIS Pro.  I ended up deciding the only thing that could be trusted to be consistent was that you couldn't trust the layer index order publishing from an FGDB.  For me, I cared about the layer index because on a republish, I would have to repoint all those layers in a WebMap to the new layer index (+ path if a new service).  Instead of relying on layer indexes not changing, I wrote a process to take the layers of a Web Map, read the underlying service layers.  You can then tie this back to the layers of the GDB that was published because the feature service layer aliases match the aliases in the FGDB.  Then read the new feature service to get the matching between it and the FDGB using the same methods. (If my updated data changed the alias, I made it so I could provide a custom dict of aliases mappings to translate/account for this.)  Once you can have both of those, you can reliably know what mappings from old layer url -> new layer url you need, because they should use the same featureclass or table.  Then you can use the arcgis python API to update the layers the WebMap is pointing to.  It was a lot of work, but now on republish I can quickly and accurately repoint all my layers when I create a new service, or update it, using an FGDB.  It doesn't work if change say a table to a featureclass, or visa versa though.  This stuff is still relatively new.  I am hopeful for the day when ESRI makes it so you can replace a service or layer, and it is smart enough to update all the references downstream as well.  All the properties are there for all a users items to do this I feel.