ArcGIS Pro Object Model Diagrams (OMD)

RobChasan

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.

KirkKuykendall1 · ‎03-13-2021

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).

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.

TracyThorleifson · ‎03-19-2021

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 skills. Skills 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 · ‎03-26-2021

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

TracyThorleifson · ‎03-26-2021

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

KirkKuykendall1 · ‎03-26-2021

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

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

ThomasCrossman · ‎10-22-2021

@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 · ‎10-22-2021

@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)

Aashis · ‎01-11-2024

Currently, we are publishing OMDs for the Geodatabase, UtilityNetwork, and NetworkDiagram APIs. Please refer to our wiki pages.

AliciaMSoto · ‎05-03-2024

@Aashis Are there any plans to make more OMDs? for example geometry?

Allen · ‎07-10-2024

Agree with all these comments. There are a lot of us who have been using ArcMap and VBA for 20 years; we started out by converting from Avenue to VBA; OMD in pdf was my way of moving forward. I also printed it out on a plotter and hung it on my office wall. I did not convert my vba to .Net add ins for ArcMap because there was no gain in functionality, just an exercise in re-writing code. Glad I did not waste my time as ArcMap is being retired and my "Add Ins" would be useless anyway. I still do a lot of VBA in MS Access (I do not think VBA for applications is going away anytime soon, unless Office is going away, which I doubt); not sure why Esri thinks they don't need to support it. IMO, Avenue was the wrong start in the first place; I think VBA was already in place. Why support python & C# only? It may be to Esri's gain to spend less time developing for multiple platforms, but to their customers expense. I want to say this: My customers demand, and therefore my output, has not changed in 20 years; I have nothing to gain by being forced to "upgrade". A map is still a map. How to get from A to B is still the same. 2 + 2 is still 4. After all the dust has settled and I have wasted countless hours and dollars, my output will be the same, my time to do it will likely be more. By the way, we had multiple layouts in ArcView; 20 years later after Esri took it away, we get it back. is it 1999 again?

Back to OMDs: release a diagram of everything! Not just the most popular. You built it, you force us to use it, give us the facts, just as in the past; (Pretend it is 1999 again; you will feel younger!)

Thanks!