Joshua,

Thanks for your interest in MGET. Here are three ways to get the source:

1.    Install 32-bit Python 2.7, the pywin32 package, and then MGET. You do not need to have ArcGIS; MGET will warn you if you don’t but can be installed fine without it.

2.    If you have a colleague who has it running on his/her ArcGIS machine, you can find MGET in C:\Python27\ArcGISX.Y\lib\site-packages\GeoEco. Replace X.Y with the version number of ArcGIS that they have, e.g. 10.3.

3.    You can browse the source at our Trac/svn site here. Sorry it is kind of antiquated; eventually we will move to git but there are other higher priorities right now. (Sorry also for the crazy link; Duke now uses malware protection that mangles all URLs we send out).

Figure 1 of the MGET paper (attached) shows MGET’s internal architecture. In brief: most of MGET is written in Python. Python is used to orchestrate calls to functions other programming environments such as C/C++, R, and MATLAB. We had to develop custom mechanisms to handle all of these:

·         C/C++: Python itself already supports calling C/C++ through various mechanisms, such as creating Python extension modules. (And if you’re heavily into C, you could use something like Cython.)

·         MATLAB: We wrote a Python extension module to host the MATLAB Component Runtime (MCR) inside Python and translate numpy arrays to/from MATLAB arrays through the MCR C++ interface. I will forward a separate email to you giving some of these details.

·         R: We used the Python rpy module, originally developed by someone else. rpy loads the R interpreter inside the Python process through R’s C APIs. We forked our own copy of rpy, made some changes, and wrapped it with additional Python code to make it better for our use. Note: rpy2 This has since been superseded in the Python community by the rpy2 module. MGET does not use rpy2—there was no Windows version available at the time—but you should probably look at rpy2 instead of rpy.

·         ArcGIS: ArcGIS already provides first-class support to Python users for calling ArcGIS geoprocessing tools. So work was needed on our part here, aside from writing something to manage the lifetime of the geoprocessor in a way that provides compatibility between ArcGIS releases. There was a lot of churn in how the geoprocessor worked in the ArcGIS 9.1-9.3 timeframe. Since ArcGIS 9.3.1, this has become much more stable, so it is probably fairly safe to take a dependency on the ESRI arcpy module directly.

·         Windows COM Automation components: We had to develop support for this in the very first releases of MGET which supported ArcGIS 9.1. We did it generally to allow us to call other COM Automation components. But we ended up using this very sparingly in the rest of MGET. I imagine you would not have a scenario that required it.

Hope that helps,

Jason

From: Joshua Smith [mailto:]
Sent: Friday, October 21, 2016 2:14 PM
To:
Subject: MGET Source Code