michalisavraam.org blog

With the new version of ArcGIS coming out soon (9.4, now 10, tomorrow maybe X), it is nice to revisit the things I would love to see change in the geoprocessor. This is by no means a study on what is missing or what ESRI is doing wrong, but rather what I would like to see in the future. If you have any suggestions, please do write a comment and I will gladly add them to the post (and attribute the addition to you).

Wish	Likely	In v.10?
Free gp	No
Path traversal	Maybe
Expose numpy	No
Faster startup	Maybe
Desktop exposure	Yes	Hopefully
Multi-core	Yes	Hopefully
List returns	No

1. A free geoprocessor: While this is unlikely to happen in the foreseeable future, there are elements of the geoprocessor that can be made freely available, either as a separate Python module or through a license check for parts of the objects. Specifically, I am referring to some of the List* methods (ListRasters(), ListFeatureClasses(), etc.) that do not require deep access to data (this would include ProductInfo(), validators, and hopefully even the Describe object). Why would ESRI want to do this? To ensure that limited functionality is available to everyone independent of cost. Why restrict people from seeing the power of the geoprocessor? Let them join the fun, and perhaps become customers too.
2. Path traversal options: The List*() methods come in the list again, with a slight change. Since many users use directory structures to store data that are deep (subfolder within a subfolder within a folder), it would be nice if the geoprocessor could read through them all and return refernces to them based on the current folder. Before one jumps in to say that the Python os module can help, please remember that most users are not aware of os.walk, and trying to deal with ERI GRIDS (which are a folder themselves) presents a challenge even for experienced Python programmers. Why would ESRI want to do this? To make life easier for the majority of users out there with data in directory trees.
3. Expose numpy in the geoprocessor: The geoprocessor as is right now (9.3.1) uses the excellent numpy module to perform matrix algebra (think of raster manipulation). Yet, when one wishes to run numpy commands, one needs to manually read raster files with GDAL, import them as numpy arrays (default), perform operations, and translate back to raster. ESRI must have modules for dealing with this, and we want them. Why would ESRI want to do this? Right now, raster manipulation through Python is done outside the geoprocessor. Most people turn to open source tools to manipulate data, which leads to less and less users relying on ESRI for this. Why pay when free software will do it? The capability is there, and we need to access it too.
4. A faster starting geoprocessor: Right now, on my dual-core, 4GB RAM machine, creating the geoprocessing object takes a noticeably long time (in the orders of a few seconds). Why is that the case today? If the geoprocessor is written as C module, the bottleneck is somewhere else. Regardless, this needs to be address, especially for using an interactive shell or multiple parallel processes involving the geoprocessor. Why would ESRI want to do this? Simply because a faster startup time is time-saving and psychologically makes people feel better about the tools at hand.
5. Multi-core aware geoprocessor: Right now, ESRI operates on one core per command (on the desktop). Similarly, the geoprocessor is a one-core operation. Yet many operations can run in parallel, and indeed, many people on the ESRI forums try endlessly to achieve multi-core operations. This is not easy of course, and not many people know how to do it. Why would ESRI want to do this? Increase in speed for one, but most importantly, to introduce a way to achieve this for everyone that wants it. Right now, there are as many solutions to this as there are people needing it. One simple and good way to achieve this would allow for unification of effort, and some good documentation be written.
6. Exposure to the desktop application when run through it: If you remember the good old VBA days (which will not be included on any version after 10, beware), you could manipulate the application via scripting. You could add data to a map, reference the 3rd item on the table of contents, etc. We want a return to this regime, but this time with Python. Why would ESRI want to do this? Something will need to replace VBA, and what better language than the chosen one for geoprocessing scripting? Also, access to such functionality opens up development to a larger audience, which can help bolster the industry by itself.
7. Make every method return a Python list for multiple data: The cursor methods in ArcGIS right now return an enumeration object. While this is understandable (ESRI doesn’t want people manipulating the order of items or inserting items in the middle of the list), it is not to the best interest of the geoprocessing model to return both enumeration objects and Python lists. At the very least, the enumeration object should have more Pythonic methods, like append() to add an element in the end or pop() to remove the last item. Why would ESRI want to do this? Consistency. There was an attempt to become more Pythonic in 9.3, so why not keep up with the theme and be more consistent at the same time?

Do you have any suggestions to include in this list? Please leave a comment. Or if you think I am off my head and don’t know what I am talking about.

(No Ratings Yet)
 Loading ...

Related posts:

1. Understanding the Geoprocessor Programming Model part 1
2. Understanding the Geoprocessor Programming Model part 3
3. Loading the Geoprocessor Safely
4. Geoprocessing Iteration with Python
5. Python Geoprocessing in ArcGIS 9.2 vs. 9.3