eCog Developer 10.3 -- Python Notes and Feedback
Wanted to provide some feedback after initial testing of the eCog 10.3 Python capabilities.
Please let me know if I can clarify any of my feedback. Thank you.
1. Using the argument/parameter name within a function causes the function to fail (for some functions).
# Error when using argument names in function, succeeds without # Succeeds ecog.set_array('array_test', ['One', 'Two']) ecog.set_variable('variable_test', 2) # Fails ecog.set_array(name='array_test', values=['One', 'Two']) ecog.set_variable(name='variable_test', value=2)
# Print message - works with and without parameter names
# Both succeed
ecog.write_message('This is a message. Without parameter names.', True)
ecog.write_message(message='This is a message. With parameter names.', show_message_box=True)
2. It looks like
set_array() functions can only be of type
float. If you set up an an array with a different type (e.g., class array), and then use the
set_array() function, it will overwrite the type to
float. This is not an issue, as the functionality matches the documentation. That said, I'm wondering if there is there any way to extend the types for these functions to also include other eCog types (e.g., imagery layer, thematic, layer, class, etc.)? Not sure if that's possible.
3. Code appears to only be created dynamically a single time when using the Edit Process window for the "python script" algorithm. Once you initially set the layers within the Edit Process window and then look at the auto-generated Python code, the code will not auto-update if you change (add or remove) layers, variables, arrays, etc., from the Edit Process window again. Having the code remain dynamic after the initial configuration (but also keeping any code you added outside what was auto-generated) could increase efficiency while working with this algorithm.
4. Can the Python functionality be extended to the image object level? I recall this was mentioned as a question during the 10.3 webinar/demo.
Was this article helpful?
Thank you for your feedback!
1. Our team will look into this issue and we will find a fix !
2. The support of eCognition types can be definitely added.
3. This is intentional. After a user edits the code, we do not know the structure of the code anymore, therefore we do not insert any new entries to not destroy the script. However, we have a couple of ideas on how to auto generate input data definition after manual editing.
4. Absolutely, we are considering this improvement.
If you would like us to get in touch with you regarding the Python Integration topic and discuss the details, please let us know!
We have been able to fix the issue where using parameter names in functions will cause them to fail.
This fix will be applied in the 10.3.1 maintenance. We hope you can try it out, and thanks again for your valuable feedback!
Thanks, Mike. I will definitely test this in 10.3.1.