I remember back to a VB.NET course I took quite some time ago, the instructor made a comment in the first class to the effect that “all real applications use a database”. That wasn’t a surprising comment and it actually reflects most of the projects we take on, although I’ll have to stick with a classic definition of database to mean more than just relational.
With a few years under our belts using Python for scheduling “things that go bump in the night” type processes we’ve seen our fair share of weirdness on the back-end setups of client shops and (this may come as no surprise) an oddly high amount of downtime from data providers (sans outages notices might I add).
Most of our hard core data manipulation programs utilize some type of read or write from a proprietary or public data model (implemented in a pure form or with extensions). In any case, we end up using the Python DB-API modules that are made available online, a variety are available and depend upon the underlying database engine. If you read through the Python DB-API specification you’ll see what is indeed mandatory and what other syntax sugar can be added. There are some modules out there that have a plethora of additional capabilities (most of which works!) and I’ll give them credit for not stomping to hard on the DB-API.
We spend much of our time working with ESRI specific databases and data formats and with their commitment to Python over the next few major releases of ArcGIS we’d sure like to see them become more standardized in their Python approaches, for example, up until 9.3 it was tough to consider anything Pythonic in their implementation. Now with 9.3 we see that they are taking it serious and working to improve their use of POPOs. One step further (and this should be relatively straight forward for the development team at ESRI) would be to implement a proper DB-API that at a minimum implements the required components of the DB-API and then adds spatial capability as well.
For those that are interested we’ve already been working on a Python module to allow such “expected” capability. Most of the individual components are written and next steps are to collate the components into the expected DB-API form.
Filed under: General
If it weren’t for plane rides I ‘d probably cancel most of my magazine subscriptions, no shortage of time spent in the air these days and the solitude of air travel, as odd as that it may sound, certainly does give me the opportunity to read.
This month in Alberta Venture they had an interesting article “Taxes and Duties”, the topic of taxes is never that exciting but the stance of this article covered definitely spanned some interesting ground. Janet Keeping’s comments are brilliant and refreshing, so good to see that there are people in the tax world that are above-board and actually understand the value of taxes.
My opinion on the topic is simple and ideal — looking for loopholes to avoid taxes is a poor substitute for contributions to the community either directly or via taxes. Greed is not the same as ambition.
In decision support for linear assets the most familiar result is the optimal alignment but this is far from the only useful output from a rather rigorous process. In many respects, the optimal alignment is more misleading than useful since it only provides a glimpse of what is without painting a full picture of the situation – like reading an executive summary without regard for the underlying body of knowledge. What then in the decision making process can provide us with additional insights? Cost corridors!
Before we plow into talking about cost corridors let’s remind ourselves that least cost analysis is merely a numerical technique for solving a complex system. With this now fresh in our minds we can talk a little more abstractly, numerical techniques used in solving systems operate in the realm of a solution space. Solution space is not constrained to two, three, or four dimensions but rather the dimensions are as numerous as the number of variables, constraints, and interaction rules that comprise the system.
As mentioned, the most common or expected result of a least cost analysis is the optimal path, this represents just the minimum solution, and, for those who have studied approaches for solving systems, we know that this is just one solution found within the solution set. Observing the solution set is where cost corridors come into play. The unfortunate thing is that even though solution space can handle multi-dimensions we mere mortals (okay, more to do with technical limitations) need to determine the projection of the solution set onto the practical plane of a GIS graphical display. The cost corridor is the intersection of the solution set with combined cost surface.
In earlier posts we detailed how the least cost analysis process works when all that is needed is the optimal route, quite simply:
- establish a start point
- accumulate cost weighted distance from the start
- establish an end point, and
- trace the steepest path from the end point to the start point.
The process for creating cost corridors capitalizes on the optimal route process quite heavily and is implemented as:
- establish a start point
- accumulate cost weighted distance from the start
- establish an end point
- accumulate cost weighted distance from the end
- combine start and end accumulated cost weighted distance
- find the minimum value within the combined accumulated cost weighted distance, and
- using a cutoff percentage query the combined accumulated cost weighted distance for values between the cutoff and the minimum.
Check out this for some more information on this process and its usefulness.
