ArcGIS Pro Object Model Diagrams (OMD)

1404
7
08-10-2020 02:49 PM
Status: Open
Labels (1)
RobChasan
New Contributor III

We need Object Model Diagrams (OMDs) for developing in Pro.  Before you scoff, please read the following:

When ArcMap came out we found the OMDs essential.  ArcObjects was something completely different from Avenue and during the process of converting programs from Avenue to ArcObjects the OMDs were an invaluable reference.  Yes, they were difficult to navigate at first, but once figured out they allowed one to view objects and their properties, methods, events, and inheritances at a glance.  We printed them out on E-size sheets and kept them handy for a few years.  As familiarity with ArcObjects grew and the number of examples on the web increased, the need for them receded. 

The switch from ArcObjects to Pro .Net SDK is similar.  The new model is in many ways quite different from the old one.  Yes, the online documentation has hyperlinks but those are not a substitute for information-rich, consolidated diagrams that present the information in an easily digestible form.  And lets be honest, the on-line documentation still leaves a lot to be desired. 

I spend most of my days developing in the ArcObjects world and on those less frequent occasions when I get to work in Pro it is maddeningly difficult to understand the object relationships when there is no clear example from which to work.  The community samples are often helpful, but when your issue is not directly referenced and you just can't figure out how "a" relates to "b" they are not as helpful as having the OMDs.

  

To be honest, I don't have much expectation that ESRI will create new OMDs.  But a person can hope.  Thanks for taking the time to read this.

7 Comments
KirkKuykendall1

The ArcObjects OMD pdfs were often not easy to search, pan and zoom around in. 

Esri should not only provide good OMD navigation, but should also showcase how map tile caches can be used for other purposes - like documentation.  

Take a look at how the Texas Digital Newspaper Project uses GIS technology for a HUGE archive of scanned newspapers.  Notice how the "lat" and "lon" in this url is used by openlayers to zoom you into the place on the newspaper page with a vector outline of the search term (geographer).

KirkKuykendall1_1-1615667975730.png

Machine Learning is advancing fast.  The spatial relationships between words matters.  Perhaps spatial operators could be useful at the visual content recognition phase? See article here.

KirkKuykendall1_2-1615668725682.png

 

 

 

 

 

 

TracyThorleifson

I would like to second Rob's call for Pro OMDs (for the SDK, ArcPy and ArcGIS Python modules). An understanding of Esri's class hierarchies is crucial for effective development, yet nowhere are these documented in the modern Esri platform. Old greybeards like myself grok this stuff intuitively, based on a very particular set of skillsSkills I have acquired over a very long career. Skills that make me a nightmare for... but I digress. ;)

At any rate, how are young padawan learners to know? How are youngsters going to learn that the feature class class inherits from the table class, or that feature classes are not the same as feature layers; how are we to expect them to learn the nuances of the geometry classes? All of this stuff is crucial to effective development, and the best way to document it concisely and compactly is via OMDs. I still refer my young developers to the ArcObjects OMDs, because, even though they are obsolete, the basics are still the same, and they are better than nothing. Also, even though QI is a thing of the past, understanding how the ArcObjects class interfaces were implemented on the underlying class structure provides students of the programming arts valuable insights into how apparently disparate classes interrelate. It's past time to update this type of documentation.

KirkKuykendall1

Maybe just start with the CIM classes, and highlight which classes are supported in which SDKs.

TracyThorleifson

@KirkKuykendall1, agree 100% on the CIM OMD idea. :smiling_face_with_smiling_eyes:

KirkKuykendall1

@dotMorten has some good ideas too, like this one.

When I do API reviews, I often like to look at an Object Model Diagram

 

ThomasCrossman

@RobChasan - Another vote here for ArcGIS Pro OMDs ....... Back in the before times (i.e. pre-.NET, at least in the ESRI world) I used to do a lot of ArcObjects automation and custom extensions (mostly simple, special-purpose editing ones in VB6 (cringe!) ), and I found the Esri OMD's to be a godsend.  Yes, they were tough to navigate at times, but they were still brilliant.  My old, two-mega-volume set of Extending ArcGIS (or whatever it was called) is also dogeared and falling apart from use--a great body of work, that.  If I am not mistaken, Esri ("ESRI" then) internally used an automation script of some kind that leveraged Visio to build those beautiful, UML-style OMDs.  Would it be possible--and worth it, I suppose--to do something similar for the ArcGIS Pro .NET assemblies?  Now, I am certainly not up to that task (nor was I ever), but it seems to me that the tools are there for those with access to them.  I have not done development for clients in many a year, but there are hints that I may be moved in that direction in my company, at least for a subset of projects.  I do not currently have Visual Studio, nor do I expect to have it; however, wouldn't the Python for .NET module (pythonnet) allow an automated solution to building OMDs similar to the automated Visio process of years ago?  Python.NET supports .NET Framework versions through 4.x -- direct access to both managed and unmanaged assemblies.  (As I have never developed for .NET, please excuse any terminology or the like that I may get wrong.)  For someone like me i.e. devoid of Visual Studio and with the skills (definitely NOT like me), I would think that such an effort would be totally possible.  Sure, it would be best if Esri did this itself, but what are the chances of that?

Python can enable a lot of cool things without having to invest in a professional development suite like Visual Studio.  I used to use the (non-canon, granted) comtypes module to wrap all the ArcObjects libraries and do automation applications/scripts.  Worked like a charm, and I really never encountered any part of ArcObjects that comtypes couldn't access.  I even used the somewhat buggy but extremely versatile WxPython GUI toolset to put a front end on some of the automation scripts.  Also worked like a charm.  So, now seems like an opportunity to build another body of OMD resources that has staying power, just like the ArcObjects ones of yore, before ArcGIS Pro moves on from .NET Framework.  (I have no doubt, though, that Python.NET will eventually be adding support for .NET 5/6 and beyond.)  Anyone up for this? :)  Pipe dream?  Sigh.   (This was an interesting, somewhat related blog post:  https://www.sharpgis.net/post/Creating-Object-Model-Diagrams-of-your-C-code)

ThomasCrossman

@RobChasan - [Sorry if this gets double-posted.  Didn't *seem* to work the first time.]       Another vote here for ArcGIS Pro OMDs ....... Back in the before times (i.e. pre-.NET, at least in the ESRI world) I used to do a lot of ArcObjects automation and custom extensions (mostly simple, special-purpose editing ones in VB6 (cringe!) ), and I found the Esri OMD's to be a godsend.  Yes, they were tough to navigate at times, but they were still brilliant.  My old, two-mega-volume set of Extending ArcGIS (or whatever it was called) is also dogeared and falling apart from use--a great body of work, that.  If I am not mistaken, Esri ("ESRI" then) internally used an automation script of some kind that leveraged Visio to build those beautiful, UML-style OMDs.  Would it be possible--and worth it, I suppose--to do something similar for the ArcGIS Pro .NET assemblies?  Now, I am certainly not up to that task (nor was I ever), but it seems to me that the tools are there for those with access to them.  I have not done development for clients in many a year, but there are hints that I may be moved in that direction in my company, at least for a subset of projects.  I do not currently have Visual Studio, nor do I expect to have it; however, wouldn't the Python for .NET module (pythonnet) allow an automated solution to building OMDs similar to the automated Visio process of years ago?  Python.NET supports .NET Framework versions through 4.x -- direct access to both managed and unmanaged assemblies.  (As I have never developed for .NET, please excuse any terminology or the like that I may get wrong.)  For someone like me i.e. devoid of Visual Studio and with the skills (definitely NOT like me), I would think that such an effort would be totally possible.  Sure, it would be best if Esri did this itself, but what are the chances of that?

Python can enable a lot of cool things without having to invest in a professional development suite like Visual Studio.  I used to use the (non-canon, granted) comtypes module to wrap all the ArcObjects libraries and do automation applications/scripts.  Worked like a charm, and I really never encountered any part of ArcObjects that comtypes couldn't access.  I even used the somewhat buggy but extremely versatile WxPython GUI toolset to put a front end on some of the automation scripts.  Also worked like a charm.  So, now seems like an opportunity to build another body of OMD resources that has staying power, just like the ArcObjects ones of yore, before ArcGIS Pro moves on from .NET Framework.  (I have no doubt, though, that Python.NET will eventually be adding support for .NET 5/6 and beyond.)  Anyone up for this? ‌‌  Pipe dream?  Sigh.   (This was an interesting, somewhat related blog post:  https://www.sharpgis.net/post/Creating-Object-Model-Diagrams-of-your-C-code)