Exocortex

For some work that I am doing outside my regular employment, I decided to check PostGIS out. This blog is supposed to be a journal of my experience. As you can understand, I am just now starting out with PostGIS (and also PostgreSQL), hence certain comments will change over time. I hope to provide enough cross-references to point out how my understanding evolves over time.

First, some background information on what led me to PostGIS. At this time, I am trying to establish a web-based GIS consulting business. (More on the business experiences in a separate blog, there is not much to write yet .) We (I have a partner) decided to have our own GIS setup in-house. However, most of the commercial packages that we are familiar with are too expensive and problematic to set up by a small establishment like ours. At about this time, a friend of mine who is also in this business (of GIS) suggested open source. We decided to give it a shot and hence we stumbled across PostGIS (actually, we came to know about it through GeoServer, uDIG, but again that is another story). [We looked at the spatial support of MySQL also, but from our research we found out that it is not very mature. We did not verify it ourselves, after reading that MySQL spatial support is immature and PostgreSQL + PostGIS is mature we decided to check out the latter first. Probably not very scientific, but in the interest of time....]

We are still in the evaluation stage. But before we go too far…how do you evaluate something like PostGIS? I am sure there are some “methodologies” for doing things like these and I am sure all these “methodologies” are fighting over each other on what the “correct methodology” is but again in the interest of time we established our own ground rules and boundaries. Those are:

1. The spatial database should have licensing requirements that are consistent with our financial and legal goals — essentially free to use without any licensing restrictions.
2. The database must be easy to install and use and should follow standards as much as possible.
3. The database project must have a good user base as established by active user forums etc.
4. The database must support common spatial operations like geometry relationships, geometry queries etc.
5. Performance metrics should match some numbers that we had established.

The above evaluation criteria, as listed, kind of gloss-over the actual numbers and parameters. It might not be too important about what our boundaries are as different people may have different thresholds. I believe that the criteria themselves are a good guide as to how to evaluate PostGIS (or any alternative along the same lines).

Criteria 1 was the easiest to find out. PostGIS is distributed with a GNU GPL as you can see right on the home page. Since we do not anticipate making changes in the PostGIS implementation itself this option works out for us. Criteria 2 is the topic of a different post, so I am not going into too many details here. Suffice to say, I did not face too many problems installing the database on my Mac. To satisfy criteria 3 we found that there is good documentation for PostGIS which goes over many things quite well. As the core of this database is based on standards, a lot of understanding can be obtained from the specifications themselves. Typical database related tasks can be found at the PostgreSQL documentation. The documentation has helped us figure out most of our problems although it must be made clear that the kinds of problems that we have faced so far are very “beginner-level” problems. There is an email list that seems to have a pretty good archive. A few companies also provide support to PostGIS related issues but it comes for a price.

As mentioned before, PostGIS implements the OGC Simple Feature Access specifications (and actually extends it). These standards define a standard feature definition and ways to interface with such features. OGC standards are adopted by all major players in the GIS space and so far there has been no major hiccups or break aways (at least publicly). This means that in the forseeable future this standards body will be supported by these players. This in turn means a certain level of stability of the standards. This satisfied our criteria 4. In some of our initial tests performance metrics were pretty good. However, there were some situations where the numbers went through the roof. Obviously this is not a very descriptive way of talking about metrics and I intend to cover that in a different post. For now, the numbers were not such that we had to abandon PostGIS. (Note to self: need to learn more optimization tricks.) This introductory post was more of a checklist that we had assembled for our evaluation and as we have seen it turns out that PostGIS scores pretty well. You might have caught a certain level of apprehensive tone in the way the post is written and that is intentional. Having worked in the software industry for a few years I have learnt to be cautious. This has no reflection on the product itself. Our decision is made. At this stage we are going with PostGIS. If we hit a road block in the future we will reevaluate things again.