Your subtype field is numeric, but your description will be a string. The only way I can see this working is doing painful operations once the data has been exported to create a subtype_description field, and then run selections on the data and calculate on each selection to populate it with your subtype description. That could be a lot of ugly.
I'd consider putting subtypes and descriptions in a list for each feature class, and then looping through the lists... to keep all the values in one place and make the code more readable...
prioh_lst = [[1,'Single Phase Primary Overhead], [2,'Two Phase Primary Overhead'], ...]
arcpy.AddField_management(in_table = reference_to_prioh_fc, field_name = 'subtype_txt', field_type = TEXT)
for rec in prioh_lst:
arcpy.MakeTableView_management(in_table = yada, out_view = somethingfunandunique, where_clause = rec)
arcpy.CalculateField_management(in_table = somethingfunandunique , field = , expression = rec)
# you might need to arcpy.delete_management(somethingfunandunique)
Thanks for the feedback and insight, Mr. Francis.
I understand that the subtype code field is numeric and the description is a string.
The operation I'm trying to perform is very rudimentary:
1. Extract all features that participate in the geometric network from ***.sde to a file geodatabase
2. Include the FeederID fields (which are managed by Feeder Manager)
3. Include the subtype descriptions
ESRI's vanilla Feature Class to Feature Class tool will copy over the subytpe codes along with the descriptions from the source to the destination gdb.
Am I to understand that the Export by Feeder tool completely ignores subtype descriptions?
I didn't mean to be overly simple--stating the obvious was my brain trying to cope with the problem. The ExportByFeeder tool takes five arguments, the first three being the inputs and output location, the fourth being text prepended to each table/feature class (that I have to go back and scrub from the output) and the fifth argument indicates whether you want to import geometry (default) or tables without geometry. My suggestion was to manipulate the output afterward, because I can't see a way to make the tool function differently.
There is a feeder sync option available for software versions 10.2.1a and later. Perhaps that could work for you and you could have all your feeder ID's populated, AND use all the ESRI native tools
I full understand your thought process I didn't take it to be anything more than you just processing the information.
The Feeder Sync tool is on our roadmap, but sadly hasn't been implemented yet...so I'm titling at windmills here...
Thank you kindly!
For those interested - this is the official response from Schneider. They are logging a bug.Hello Joshua,
This is Sam with Schneider Electric Support. How's your week going so far? I'll be helping you out with this issue.
I do see the same thing that you do - subtype information (names / descriptions of subtypes) don't seem to be exported at all by the Export by Feeder tool. It exports the field that the subtype was based off of, and the subtype codes are obviously there, but the actual subtype configuration is completely lost.
I've submitted bug CLS-62854. I'm not sure if this will be considered a bug or not, as I'm not sure if we intended the tool to properly export subtypes, but I have a hard time thinking of a reason why we wouldn't want to do that here.
As a workaround, you could look into the Feeder Sync tool. This tool can be set up to write the actual FeederIDs to an actual field, so you still have the fast editing of Feeder Manager 2, but you can have the FeederIDs on an actual field after the sync runs. This way you could use the ESRI native tools and get the FeederIDs.
More info on this tool is here:
Let me know if you have any questions.
Sam Tregillus| Technical Support Engineer | Schneider Electric | firstname.lastname@example.org |