Labels using Python (not interested in Arcade)
Issue 1: Ok... times change so the field... !OBJECTID! is now [OBJECTID] when using python and migrating from ArcMap to ArcGIS Pro. Being a 'whatever' kind of guy when it comes to software changes, I can live with this (sort of). That was an esri decision on how they want to delimit 'fields'.
Issue 2: I do draw the at changing how the chosen label language is treated.
Python 3.6/7 has some very useful format options, that enable you to produce output as string(text) without have to do type conversion. For example... notice, an integer was automagically formatted to a string and you can do 'math' with the integer
# ---- python ----
objectid = 1
"id {} -> {}".format(objectid, objectid-1)
'id 1 -> 0'
# ---- as expected ----
However... Things are not as expected when using label formatting, as above, with python.
Must have made a mistake....
ok... ! ! is now [ ]
spelling correct
format string is fine
error message makes no sense
Now... what you have to do is
int the string, that is actually an int so you can string it
With me?
The whole utility of allowing for format language options is good. However, I expect the language rules to be respected.
So the question
Is this a bug?
If it isn't a bug, can someone explain the logic?
I am not interested in the other language options, or a different labelling engine.
Just plain simple labels, that would be great, respecting the way that this should work.
Solved! Go to Solution.
Hi all,
This is how labeling has always worked. The value is cast to a string so you need to convert it to a numeric data type for comparisons or math equations. Both Standard and Maplex label engines work this way. Three parsers - VBScript, Python and JScript - work this way. Arcade in Pro works differently and field values maintain their data types.
you can see the doc here
Pro: Specify text for labels—ArcGIS Pro | ArcGIS Desktop
ArcMap: Building label expressions—Help | ArcGIS Desktop
Field values are automatically cast to text strings. Therefore, if you want to use a numeric value in an arithmetic operation or when making a comparison, you will need to cast it back to a numeric data type.
When using Arcade, the field values maintain their data type.
The following examples add two integer fields:
Arcade
$feature.FIELD1 + $feature.FIELD2
Python
int([FIELD1]) + int([FIELD2])
VBScript
cint([FIELD1]) + cint([FIELD2])
JScript
parseInt([FIELD1]) + parseInt([FIELD2])
Kory Kramer … is this related to 2.2.2?
https://community.esri.com/docs/DOC-11254-holistic-testing-schedule-for-2017
2.3 scheduled to be tested this week... can someone check on that version
Dan:
Is the Holistic Testing Schedule that you show, testing of the Beta software that can be done by ESRI customers if they sign up some where?
It hasn't been announced, or I am not on the 'beta list' anymore. It is in-house for esri staff in Redlands. Just thought Kory might see this
Dan Patterson and Michael Volz. Public holistic sessions are periodically organized and if you're interested in getting an invite I'll let the holistic lab manager know. I can also make sure that you're both on the invite list to participate in the ArcGIS Pro beta testing. If interested, confirm by emailing me at kkramer@esri.com with your preferred email address and contact info.
Thanks to both!
Wendy Harrison can you take a look at this one please?
Thank you.
Hi all,
This is how labeling has always worked. The value is cast to a string so you need to convert it to a numeric data type for comparisons or math equations. Both Standard and Maplex label engines work this way. Three parsers - VBScript, Python and JScript - work this way. Arcade in Pro works differently and field values maintain their data types.
you can see the doc here
Pro: Specify text for labels—ArcGIS Pro | ArcGIS Desktop
ArcMap: Building label expressions—Help | ArcGIS Desktop
Field values are automatically cast to text strings. Therefore, if you want to use a numeric value in an arithmetic operation or when making a comparison, you will need to cast it back to a numeric data type.
When using Arcade, the field values maintain their data type.
The following examples add two integer fields:
Arcade
$feature.FIELD1 + $feature.FIELD2
Python
int([FIELD1]) + int([FIELD2])
VBScript
cint([FIELD1]) + cint([FIELD2])
JScript
parseInt([FIELD1]) + parseInt([FIELD2])
Wendy... first time I had to label a map (believe it or not), hence, when I saw 'Python' I expected python not python-ish.
That makes for some unnecessary conversions when you need to do anything other than a simple label (my example was a simplified version of what I needed, and it required 4 type conversions)
This is too small for an idea, but it would be nice if the object conversion to text be removed or provide more documentation on the labeling tool itself.
Arcade = Avenue (sorry... no more proprietary 'languages' for me
Thanks for looking into this, I will just stick to not making maps.
this is more elegant
"{} {} {}".format('a', 1, [1,2,3])
It would make more sense (IMHO) if the parsing to a string would happen at the end as with Arcade. And not to the parameters passed to the labeling function.
Dan Patterson, you can fight it but eventually you may end up using Arcade for some things...